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

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.

LTP Segment Bit ^ | | Version number | Segment Type Flags | | | | | | / Session ID \ | \ / Header | | Header Extension Cnt. | Trailer Extension Cnt.| | | | | | / Header Extensions \ | \ / V | | | Segment Content | / \ \ / | | ^ | | | Trailer / Trailer Extensions \ | \ / V

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

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

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.

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

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

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

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

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)

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

LTP status ● LTP specified in 3 drafts – draft-irtf-dtnrg-ltp-03.txtmain spec. – draft-irtf-dtnrg-ltp-motivation-01reasons for stuff – Draft-irtf-dtnrg-ltp-extensions-01extensions ● 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