Licklider Transmission Protocol (LTP)

1. Licklider Transmission Protocol (LTP) • A point-to-point protocol for DTNs • Think of it as somewhere from layer 2 up to maybe layer 4! • LTP is highly stateful • Needed to avoid negotiation exchanges • Primarily aimed at deep space DTNs but can also (I claim!) be used for many terrestrial cases • Encoding is terse and binary

2. LTP layering • LTP runs on top of some MAC layer or deep space physical layer • LTP assumes lower layer “cues” are provided so that some infrastructure (e.g. ephemeris handler + scheduler) tells the stack when to expect to receive or transmit with a given peer.

3. LTP Segment Bit 0 1 2 3 4 5 6 7 ^ +-----+-----+-----+-----+-----+-----+-----+-----+ | | Version number | Segment Type Flags | | +-----------------------+-----------------------+ | | | | / Session ID \ | \ / Header +-----------------------+-----------------------+ | | Header Extension Cnt. | Trailer Extension Cnt.| | +-----------------------+-----------------------+ | | | | / Header Extensions \ | \ / V +-----------------------------------------------+ | | | | | | | Segment Content | / \ \ / | | | | | | ^ +-----------------------------------------------+ | | | Trailer / Trailer Extensions \ | \ / V +-----------------------------------------------+

4. LTP Encoding • Many fields use so-called Self-Delimiting Numeric Values (SDNV) • Also used in bundling protocol • Based on ASN.1 BER encoding of OID arcs • Might change in future • But so long as the same thing's used everywhere that's ok

5. LTP features • Sessions/Segments • A single “block” is sent per “session” using multiple “segments” • Segment size is limited by the underlying MTU • Session-ID is src-ID + number • Recommended to use a (P)RNG for the number • Red/green parts • Data is ACKed (red) or not (green) • Not ACKing is easier, but doesn't fulfill all appn. Requirements • Red part first (if any), then green (if any) • Each segment in a session is entirely red or entirely green

6. Red/Green motivation • Lots of science data formats (e.g. images) put important information (e.g. codec, timing, orientation) at the start, followed by lots of less important detail (pixels) • Loose the codec information and the rest is useless • Losing a pixel or two (hundred) isn't that bad • Want to have ACKs for the start of the block but not the entire block • Caller or config. determines which, if any, segments are red. Others are green.

7. LTP segment types • Data segment (tx->rx) • Can be Red or Green • Report segment (rx->tx) • Report ACK segment (tx->rx) • Cancel segments (tx/rx differ) • Required for loopback • Cancel ACK segments

8. Data segments • Subset of block's bytes (offset, length) • Flags can indicate: • End of Red Part • End of Block • EORP and EOB require report (ACK) • Unless zero red bytes

9. Reports • Each report contains a set of scopes, each of which informs the transmitter that some (red)bytes have arrived safely • Report segment has a serial number (RSN) • Report segments always ACKed using RSN • Wrinkle: reporting the “full” state might require >1 rx->tx MTU so a single “report” might need >1 RS • Spec. has some hyper-efficient ways to handle this for deep space reasons • Also allows for more “full” reporting where bandwidth less constrained

10. Retransmission • Re-txing based on timeouts and counters • If EORP/EOB sent but no ACK (RS) • If RS sent but no RA • If Cx sent but no CAx • Timers use “punctuated” time • Only decremented during periods when data could actually be arriving from the peer • E.g. Not decremented while peer is turned off

11. Denial of Service • LTP nodes can be very badly affected by DoS • Took a couple of weeks to reboot MER Spirit when OS had no file handles left • Anti-DoS features: • Random bits recommended in Session ID • Recommended random bits in report serial numbers • Initial version had both being guessable and so potential targets for off-path attacks • Like TCP SYN flooding • Replay detection algorithm (sample) • Cookies (next slide)

12. LTP extensions • Both header and trailer extensions allowed • LTP authentication extension • Header: ciphersuite • Trailer: MAC/Signature • LTP cookie extension • DoS would be very bad for a deep space host • Cookies aiming to protect against off-path attacks using a header extension, once turned on, only segments with cookie accepted

13. LTP status • LTP specified in 3 drafts • draft-irtf-dtnrg-ltp-03.txt main spec. • draft-irtf-dtnrg-ltp-motivation-01 reasons for stuff • Draft-irtf-dtnrg-ltp-extensions-01 extensions • Main spec and motivation are just about ready for last call • Extensions a little later (sync. security stuff) • At least two implementations I know of