Package net.i2p.router.crypto

Class TransientSessionKeyManager

java.lang.Object
net.i2p.crypto.SessionKeyManager
net.i2p.router.crypto.TransientSessionKeyManager
public class TransientSessionKeyManager
extends SessionKeyManager
Implement the session key management, but keep everything in memory (don't write to disk). However, this being java, we cannot guarantee that the keys aren't swapped out to disk so this should not be considered secure in that sense. The outbound and inbound sides are completely independent, each with their own keys and tags. For a new session, outbound tags are not considered delivered until an ack is received. Otherwise, the loss of the first message would render all subsequent messages undecryptable. True? For an existing session, outbound tags are immediately considered delivered, and are later revoked if the ack times out. This prevents massive stream slowdown caused by repeated tag delivery after the minimum tag threshold is reached. Included tags pushes messages above the ideal 1956 size by ~2KB and causes excessive fragmentation and padding. As the tags are not seen by the streaming lib, they aren't accounted for in the window size, and one or more of a series of large messages is likely to be dropped, either due to high fragmentation or drop priorites at the tunnel OBEP. For this to work, the minimum tag threshold and tag delivery quanitity defined in GarlicMessageBuilder must be chosen with streaming lib windows sizes in mind. If a single TagSet is not delivered, there will be no stall as long as the current window size is smaller than the minimum tag threshold. Additional TagSets will be sent before the acked tags completely run out. See below. all subsequent messages will fail to decrypt. See ConnectionOptions in streaming for more information. There are large inefficiencies caused by the repeated delivery of tags in a new session. With an initial streaming window size of 6 and 40 tags per delivery, a web server would deliver up to 240 tags (7680 bytes, not including bundled leaseset, etc.) in the first volley of the response. Could the two directions be linked somehow, such that the initial request could contain a key or tags for the response? Should the tag threshold and quantity be adaptive? Todo: Switch to ConcurrentHashMaps and ReadWriteLocks, only get write lock during cleanup

  • Field Details

    • _context

      protected final I2PAppContext _context

    • MAX_INBOUND_SESSION_TAGS

      public static final int MAX_INBOUND_SESSION_TAGS
      a few MB? how about 24 MB! This is the max size of _inboundTagSets.
      See Also:
      Constant Field Values

    • DEFAULT_TAGS

      public static final int DEFAULT_TAGS
      This was 100 since 0.6.1.10 (50 before that). It's important because: 
        - Tags are 32 bytes. So it previously added 3200 bytes to an initial message.
  - Too many tags adds a huge overhead to short-duration connections
    (like http, datagrams, etc.)
  - Large messages have a much higher chance of being dropped due to
    one of their 1KB fragments being discarded by a tunnel participant.
  - This reduces the effective maximum datagram size because the client
    doesn't know when tags will be bundled, so the tag size must be
    subtracted from the maximum I2NP size or transport limit.
      Issues with too small a value: 
        - When tags are sent, a reply leaseset (~1KB) is always bundled.
    Maybe don't need to bundle more than every minute or so
    rather than every time?
  - Does the number of tags (and the threshold of 20) limit the effective
    streaming lib window size? Should the threshold and the number of
    sent tags be variable based on the message rate?
      We have to be very careful if we implement an adaptive scheme, since the key manager is per-router, not per-local-dest. Or maybe that's a bad idea, and we need to move to a per-dest manager. This needs further investigation. So a value somewhat higher than the low threshold seems appropriate. Use care when adjusting these values. See ConnectionOptions in streaming, and TransientSessionKeyManager in crypto, for more information.
      Since:
      0.9.2 moved from GarlicMessageBuilder to per-SKM config
      See Also:
      Constant Field Values

    • LOW_THRESHOLD

      public static final int LOW_THRESHOLD
      ditto
      See Also:
      Constant Field Values

  • Constructor Details

    • TransientSessionKeyManager

      public TransientSessionKeyManager​(I2PAppContext context)
      The session key manager should only be constructed and accessed through the application context. This constructor should only be used by the appropriate application context itself.

    • TransientSessionKeyManager

      public TransientSessionKeyManager​(I2PAppContext context, int tagsToSend, int lowThreshold)
      Parameters:
      tagsToSend - how many to send at a time, may be lower or higher than lowThreshold. 1-128
      lowThreshold - below this, send more. 1-128
      Since:
      0.9.2

  • Method Details