1 trinity college dublin n4c technical kick-off tcd slides stephen farrell [email protected]...

1Trinity College Dublin

N4C Technical Kick-Off TCD Slides

Stephen [email protected]

N4C Technical Kick-OffSlovenia

September 22-25, 2008

These slides (will be) at: http://dtn.dsg.cs.tcd.ie/n4c/tko.pdf


Acknowledgements

Most of this represents recent work done with Alex McMahon (TCD) and Kerry Hartnett (Intel)

Stefan Weber and Darragh O'Keefe (both TCD) also provided input

Some reflects discussion with Elwyn and Avri at a meeting in Dublin in June.

...and of course...all you N4C people too...


Contents

1. Naming for N4C2. DTN Router Outline Design3. DTN Security for N4C4. N4C Code Repository5. LTP-T – A DTN protocol that's not the BP6. Bootable USB sticks


DTN Naming Strawman


DTN Naming

All BP nodes require Endpoint Identifiers (EIDs) which are syntactically URIsOnly the “dtn:none” EID is well-defined right now (the “dtn:” URI scheme is provisionally registered with IANA)

We need to name things in N4CBut perhaps not everything will be a BP node...

Nonetheless suggestion is to allocate an EID for everything in N4C


Naming Strawman - Examples

E.g.#1: A numbered node: dtn://n4c.eu/n/1234E.g.#2: Same node with additional info: dtn://n4c.eu/n/1234?FN=sfnode&KID=78dfd4E.g.#3: Another node: dtn://n4c.eu/n/1234/4321E.g.#4: A CCR: dtn://n4c.eu/ccr/5678E.g.#5: A gateway: dtn://n4c.eu/ccr/gw/5678/1


Naming Strawman - ABNFN4C-EID = "dtn://" authority "/" hier-part [ query ]

Hier-val = ["n"|"ccr"|"ccr/gw" number] "/" number-part

query = ["FN="|"KID=""SRV="] qval [ "&" query ]

authority = usual thing host:portnumber-part = number [ / number ]number = decimal or ASCII-hexqval = a string


Naming Strawman – Notes (1)

Case insensitive. No I18N, BiDi or other silliness:-)No parts, e.g. dtn://n4c.eu/n/1234#part is invalid. Nodes, CCRs and gateways are numbered

Numbers can be long (e.g. hashes, CGA)Each gateway is tied a CCR,

But nodes are not Multiple number parts allow dynamic, in-the-field node (name) creation with unique names

• Creating a node may require more than giving it a name...but is a start.

CCRs can also have hierarchy



Use of the query to carry attributes of the node

Friendly name ("FN") could be DNS name, mail address..."SRV=www,mail,bp-cust" to represent the services that a node offers, in this case, web and mail relay and BP custody.Define new attributes as we go, e.g. a "LASTCCR" with a value of the EID of the last CCR where that node was seen.



The query part is not to be used when considering EID equality.Query string can only be used for routing where a specific query string value exists that the routing alg. knows about.

So the LASTCCR could be used in routing, but FN should not

• The SRV query string might be considered when selecting a next-hop, e.g. if the bp-cust value is present



These EIDs to be used for all sources and destinations for the BP in N4C. I think we should also allow mailto: URIs in report-to fields though.If we need logical domains or realms, then we do that via the authority part, e.g. dtn://realm1.n4c.eu/n/123Mapping to DNS might be useful?

Maybe: dtn://n4c.eu/gw/123/456 → n4c.eu.gw.123.456 and populate A & TXT

resource records there• What to do about non-BP nodes? (if any)


DTN Router Outline Design

n4c-tcd-003-router-design-02n4c-tcd-003-router-design-02


DTN Router Highlghts

Intel Atom based CPULinux 2.6 (probably Ubuntu)To be able to run all core DTN applicationsWiFi and WiMAX connections

And animal tags...?Various peripheral connections

USB, RS-232, ...Rugged enclosure

Cheap metal box:-)Mains/Battery/Solar power


Comms. & Power

Atom CPU

Board

Base-Board

(IO)

BatterySolar Panel

Solar Panel

Mains PowerCharger

Charger

PowerInjector

WiFiAP

WiMAX

SS

Enclosure

Power

Cat-5

Cat-5e


Peripherals

Atom CPU

Board

Base-Board

(IO)

USB Hub

Enclosure

Console (9-pin D)

RS-232

SDCard


DTN Router Services

Network

Interface

DTND

LTPD

SMTP

BIND

wwwoffle

Apache

Admin

Glue

Glue

Glue

SelectorContact-driven

communications

Always-on(when-on)

communications


Issues under consideration

AP/SS via PoE or USB? Power budget Board suppliers

• Will drive specific OS distro. Choice Other peripherals Services to include S/W architecture details ...


DTN Security for N4C

n4c-tcd-004-security-00n4c-tcd-004-security-00


Three bits of security

Threat analysisSystem securityDTN security


Threat Analysis

Identify relevant threats and countermeasuresIteratively classify things as High/Medium/Low

Newly minted PRIMUSE method:-)

• Threats: PRobability IMpact• Countermeasures: USability Effectiveness

Issues:• Adopt this?• Level of effort?• How often to iterate?• Separate analysis for each type of node?• How/what to test?


System Security

SSH to get login to nodes TLS certs for services, HTTP, IMAP, SMTP(?)...

• Implies we need some key management infrastructure for the project

• A list of SSH public keys installed on each node• A little PKI for certs

Node hardening• Need to figure out which services should be accessible on each (type of) node and to whom• Then build that into the node setup process (via scripts, root filesystems, ...)


DTN Security

More research than operational DTN AAA:

• Why should I take custody for your bundles?• Maybe capabillty scheme? Maybe PEP/PDP type approach?

DTN key management• Start with an assumption that initial keys are in place• Develop a key-update mechanism and implement as an extension to, or payload protocol using, the bundle protocol and LTP• Depending on staffing...Maybe try tackle a DTN key distribution/agreement scheme


N4C Code Repository


A Version Control System for N4C

A VCS is required to manage:A VCS is required to manage:

New N4C code New N4C code SNC codeSNC codeDTNRG code (BP & ProPHET)DTNRG code (BP & ProPHET)LTPlibLTPlibOS images, root file systems, etcOS images, root file systems, etcScripts, node configurationsScripts, node configurationsTest results ?? (If so what access control?)Test results ?? (If so what access control?)Test result analysis scripts/codeTest result analysis scripts/codeOther ?Other ?


What should the VCS provide?

A portal for collaboration on code development

Revision control & merge support Have a small storage footprint and

efficient compression scheme Import and export support to other VCS Compatable with DTNRG VCS


Mercurial

Mercurial, a distributed revision control system, is proposed as a suitable solution.

A Mercurial repository is simply a directory tree managed by Mercurial.

Repositories may be accessed via SSH, HTTP or HTTPS.

A pilot has been provided (master site TBD)

http://basil.dsg.cs.tcd.ie&&http://info.n4c.eu/code


Screen Shot


Proposed collaboration model

As a general rule a single source repository is As a general rule a single source repository is maintained and published by the librarian for maintained and published by the librarian for each N4C code tree that is the authoritative each N4C code tree that is the authoritative current tree for the project.current tree for the project.

Permission is requested (via email) from the Permission is requested (via email) from the repository librarian to become a maintainer and repository librarian to become a maintainer and gain access for checkins. gain access for checkins.

Permission to become a maintainer will almost Permission to become a maintainer will almost always be granted, it is the responsbility of each always be granted, it is the responsbility of each partner to determine which of their staff are partner to determine which of their staff are maintainers.maintainers.

N4C code trees are hosted and maintained at the N4C code trees are hosted and maintained at the agreed site.agreed site.


Collaboration model continued...

•Hosted repositories will initially include BP, LTP, PRoPHET and SNC related code (which?)•Anyone can clone the authoritative repositories, which are published via HTTP•The librarian allows whatever changes maintainers publish, without reviewing those changes

•Other than when e.g. pushing BP changes back to sourceforge

•The librarian will publish maintainer-contact information /


LTP-T: Another DTN Protocol


LTP-T

LTP is point-to-point, but exensible…hmm…

Could make a transport protocol out of a sequence of LTP links

So I did…its called LTP-T– https://www.cs.tcd.ie/publications/tech-reports/

reports.05/TCD-CS-2005-69.pdf

My code includes an LTP-T implementation


An LTP-T Session


LTP-T vs BP

BP is Overlay, LTP-T is what I call a “DTN Transport”

• LTP-T can only work where all “hops” are over LTP, so is less general (by design)

LTP-T • Has no multi-hop backwards signalling• Insists that all nodes are custodians• ...is basically simpler• Can outperform the BP in some cases


Bootable USB Sticks


Hikers, PDAs and Sticks

The hiker's PDA application is good, but involves powering up the PDAs when the hikers meet and they also need to install s/w on their PDAs before entering the area

Instead of that, why not distribute USB sticks that are bootable and can:

• Install the relevant s/w on the PDA or run without installing the s/w on the PDA• Act as a sneakernet transfer medium – hikers meeting simply exchange USB sticks


Thanks!

Questions


Backup Slides


Application Layer Gateways

One could construct a DTN based on a web services model

Don’t think its been done thoughEverthing in the Bundle Protocol could be replicated with SOAP

More on the Bundle Protocol in a bit... Basically this would be fine with so long as delays and disruptions don’t affect every use of TCP

If some TCP sessions succeed, even perhaps very occasionally, then you could get DTN functionsSo why not SOAP?


E-mail

(For completeness)

E-mail application is delay tolerant

But none of SMTP, IMAP or POP areAll sit on TCP

DNSBLS, Greylisting etc would muck things a bitEssentially, RFC 2821/2822 has too much legacy stuff going on

Same as SOAP but much worse (since mail is deployed)


wwwoffle

An offline browser/proxy– http://www.gedanken.demon.co.uk/wwwoffle/

Locally installed web proxy, continues to serve content even if network connection has gone awayDial-on-demand, cached outbound requests, pre-fetching based on inbound responses Can display date content cached

Generic DTN GUI issues

Problems:Pre-fetching needs rendering in proxy (i.e. peek into HTML, Javascript etc.)FTP etc not as easy and there’ll always be another protocol (e.g. BitTorrent)Cookies – how to consult privacy preferences with no user there?Captchas – hmm…

These are all generic problems with putting browser stuff into proxies and have been seen a number of times without being solved


Pre-amble: Causes of Delay/Disruption

Laws of physicsLight trip time

Conserving powerBatteries have a crappy Moore’s law

Intermittent availabilityLectures 12-1 Tues and 2-4 Thurs only!

Nothing happeningMost of the time, sensors must be really bored!

Bad things happeningDDoS an edge router and what happens?


DTN Research Group

DTNRG is an IRTF research group; The IRTF is the “research arm” of the IETF• IETF: http://www.ietf.org/• IRTF: http://www.irtf.org/• DTNRG: http://www.dtnrg.org/

Specs, Code, Papers, Project links…

DTNRG is an open group – just get on the mailing list (dtn-interest) and off you go...Two main protocols being developed:

Bundle Protocol (BP)Licklider Transmission Protocol (LTP)


Bundle Protocol - Quick history

~1998 Vint Cerf & a bunch of JPL folks started on Interplanetary Internet (IPN) workBecame clear (~2002) that its hard to do many experiments on the solar systemLuckily the generalisation of an IPN also has terrestrial applications – generalised to Delay Tolerant NetworkingDARPA (US DoD) started funding (~2005) Disruption Tolerant Networking projects (~US$20M)

DTN expanded whichever way you prefer


Bundle protocol

The bundle protocol (BP) is the main focus of the work in DTNRG

BP is a delay/disruption tolerant overlay network protocol

More on that in a moment

Multiple implementations exist, some interop. happened in Nov’06 and again (though more limited) in March ‘08


BP documents

Mature:• DTN Architecture: RFC 4838

• Note: not really the architecture for all of DTN, but actually fairly specific to the bundle protocol

• BP spec: RFC 5050Maturing...

draft-irtf-dtnrg-bundle-securitydraft-irtf-dtnrg-sec-overviewdraft-irtf-dtnrg-prophet

Co-authored by Anders Lindgren formerly of LTU

draft-irtf-dtnrg-tcp-clayer

Less mature...multicast, last-hop, header compression, retransmission

Missing...More on routing, only have one so far on PRoPHETKey Management, one expired draft:-)


DTN and layering

What layer is best to try tackle delay and/or disruption?

No single answer, as usual

BP chooses the overlay approach on the basis that highly challenged networks/nodes may have to use “strange” communications layers

Original IPN concept of “regions”

Late binding of names


BP is an Overlay Nework Protocol

Application

Bundle Endpoint

Transport (TCP)

Network (IP)

Bundle Endpoint

Transport (TCP)

Network (IP)

Application

Bundle Endpoint

Transport (SCTP)

Network (IP)

Bundle Endpoint

Transport (SCTP)

Network (IP)

Application

Bundle Endpoint

Transport (TCP)

Network (IP)

Bundle Endpoint

Transport (TCP)

Network (IP)

Application

Bundle Endpoint

Transport (SCTP)

Network (IP)

Bundle Endpoint

Transport (SCTP)

Network (IP)

Application

Bundle Endpoint

Transport (TCP)

Network (IP)

Application

Bundle Endpoint

Transport (TCP)

Network (IP)

Bundle Endpoint

Transport (TCP)

Network (IP)

Bundle Endpoint

Transport (TCP)

Network (IP)

Application

Bundle Endpoint

Transport (SCTP)

Network (IP)

Application

Bundle Endpoint

Transport (SCTP)

Network (IP)

Bundle Endpoint

Transport (SCTP)

Network (IP)

Bundle Endpoint

Transport (SCTP)

Network (IP)


Primary Bundle Block +----------------+----------------+----------------+----------------+ | Version | Proc. Flags (*) | +----------------+----------------+----------------+----------------+ | Block length (*) | +----------------+----------------+---------------------------------+ | Destination scheme offset (*) | Destination SSP offset (*) | +----------------+----------------+----------------+----------------+ | Source scheme offset (*) | Source SSP offset (*) | +----------------+----------------+----------------+----------------+ | Report-to scheme offset (*) | Report-to SSP offset (*) | +----------------+----------------+----------------+----------------+ | Custodian scheme offset (*) | Custodian SSP offset (*) | +----------------+----------------+----------------+----------------+ | Creation Timestamp time (*) | +---------------------------------+---------------------------------+ | Creation Timestamp sequence number (*) | +---------------------------------+---------------------------------+ | Lifetime (*) | +----------------+----------------+----------------+----------------+ | Dictionary length (*) | +----------------+----------------+----------------+----------------+ | Dictionary byte array (variable) | +----------------+----------------+---------------------------------+ | [Fragment offset (*)] | +----------------+----------------+---------------------------------+ | [Total application data unit length (*)] | +----------------+----------------+---------------------------------+ Bundle Payload Block +----------------+----------------+----------------+----------------+ | Block type | Proc. Flags (*)| Block length(*) | +----------------+----------------+----------------+----------------+ / Bundle Payload (variable) / +-------------------------------------------------------------------+

A bundle


BP Concepts (1)

Naming: URIs, including dtn: schemeEndpoint identifiers: EIDs

Late binding – routers each can lookup names/interface mappings

Or not…or whatever…

Open issues abound here (as always)

Contacts: duration with a positive channel capacity associated

Persistent, on-demand, scheduled, opportunistic, …

Uni-/bi-directional


BP Concepts (2)

Time: time is carried in-band in the BPMistake or not? Time will tell.

Requirement for clock synchronisation seems a bit odd in a DTN (though some work has been done there)

Used to expire bundles as part of congestion avoidance

Custody: intermediate routers re-transmit as bundle gets “closer” to desination (hopefully)

Good area for experimentation


BP Concepts (3)

• Signalling: reporting activities as the bundle transits the DTN

Potential expansion effects => potential DoSBut: was found to be v. helpful in interop

Is in-band signalling or an ICMP-like approach better?

Congestion: mostly reduces to storage congestion


BP Concepts (4)

Fragmentation: pro-active or reactiveReactive=difficult! Idea is to not waste bandwidth following a link disruption

But makes it v. hard to do security stuffToilet paper!

Expedited delivery: Like reactive fragmentation but for delivery to application

May risk data integrity violationsConvergenc layer: the layer below the bundle protocol

Could be: LTP, Proximity-1, UDP, TCP, ethernet, Irridum,…


DTN Security

What’s different in securing a DTN?Not all hosts that process a bundle are DTN nodes

Possibilities for hard-to-detect traffic manipulation multiplied

Resource consumption more seriousIngress control more importantSame as any ad-hoc network: every router has to be a firewall


BP Cryptographic Services

Lower layers are just fine too!IPSec, TLS, WPA, etc. all good

BP security primitives defined for bundle integrity and confidentiality

Have now been implemented so maybe not bad specs!

• But: no key management yet

BP security isn’t quite end-to-end:End-to-end-ish-ness and hop-by-hop-ish-ness


Future-ish BP Things

Extension blocks for handling:Multicast

Previous-hop

Bundle-in-bundle encapsulation

Retransmission block

Convergence layer specifics

Routing Although PRoPHET exists, other schemes will be needed as well


BP Summary

BP architecture and protocol are well-defined, stable and have been interop’dExperimental RFCs are a fine basis for subsequent experimentation

DTN-ish projects that previously rolled their own protocols should (and are starting to) use the BP

Will there be interest in developing standards-track versions?

Maybe, but this is not yet commercialFP7 ICT (N4C!) and NSF FIND programmes might engender more commercial interest


Licklider Transmission Protocol (LTP)

• LTP is a point-to-point protocol for DTNs– Designed as a BP convergence layer for deep space

(v. high latency) links– Think of it as somewhere from layer 2 up to maybe

layer 4!– Encoding is terse and binary– LTP is highly stateful

• Needed to avoid negotiation exchanges

• Can also (I claim!) be used for terrestrial DTN applications (e.g. SeNDT)


LTP Background

Named for J.C.R. Licklider

CCSDS have defined CFDP (CCSDS File Delivery Protocol) that is quite like LTP, but:

LTP spec. is much less OSI-like• “Internet” approach better for more open development

environments

CFDP security…hmm

• CCSDS: http://www.ccsds.org/

So LTP is sort-of another “go” at CFDP in a more open development environment


LTP Documents

draft-irtf-dtrng-ltp-motivationBackground and reasons for…

draft-irtf-dtnrg-ltpCore LTP protocol

draft-irtf-drnrg-ltp-extensionsExtensions (security)

Documents are currently with the RFC editorUsual IRSG/IESG/IANA/RFC-ed procedural wrangling on-going


An LTP Session

Source Destination

Light TripTime


LTP Layering

• LTP runs on top of some MAC layer or deep space lower layer

• LTP assumes lower layer “cues” are provided so that some infrastructure (e.g. ephemeris handler + scheduler or proximity detector) tells the stack when to expect to receive or transmit with a given peer


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 – Partial Reliability– 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 (Security) 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

• No confidentiality related extensions so far– Could be, but feeling is other layers will commonly do this so not yet

• And of course, we’ve no good ideas about key exchange either;-)


LTP Interop

• Same beer picture:-)– But only two LTP implementations (Ohio & TCD) in ‘06– And two (TCD & JPL) in ‘08

• Nominal operation in both directions– Both layered on top of UDP– 1st exchange took 30-45 mins of work– A few minor bugs on both sides (mostly mine, mostly htonl related)

• Features tested:– Red/Green mixtures– Lost segment handling– Extension skipping

• Not tested:– Corrupt segments– Extension specific handling (not in Java version)– Re-ordered segments


LTP Code

• DTNRG site has links: http://www.dtnrg.org/ • Mani’s code (Java)

– http://irg.cs.ohiou.edu/ocp/ltp.html

• My dodgy code (C++, sort-of:-)– https://down.dsg.cs.tcd.ie/ltplib/– CVS snapshot is currently “best”

• JPL ION code– Not released yet? Ohio Uiversity plan that. (I

think)


DTN Routing

There are lots of schemesInventing new ones is easy

None of them are provenAll (probably) have scaling issuesWhat to do?

Do experiments, let others simulate things (they will)This is hopefully the main technical focus of the DTNRG for the next while, so get onto the dtn-interest list as well

• Zhang, Z., “Routing in Intermittently Connected Mobile Ad Hoc Networks and Delay Tolerant Networks: Overview and Challenges,” IEEE Communications Surveys and Tutorials, 8(1), 2006.


Other DTN Open Issues

Key management

Congestion handling

Scalability

Policy stuff (ingress, egress, routes, …)

Traffic analysis


Next Steps in DTNRG

Progress routing as a priority in DTNRG once existing document queue processed

Maintain open source code for protocols and base experiments on those

Build a lasting testbed for DTN based on real application and user requirements...– http://www.n4c.eu/


Next Steps in DTN

Experiments

Establish lasting DTN testbed(s)

Determine (or create) commercial interest


Summary

There are some highly-challenged networking scenarios where current Internet protocols can’t be usedThere are a variety of reasons for thisThere are some applications that we may want to use in such environmentsDTN represents an approach to trying to provide some level of networking, approaching, but never equalling the current Internet experience


TCP Breaks!

Pretty certainly: after 5 mins LTT (User timeout)

Actually: after ~50ms LTT (100ms RTT) things get bad and generally fail after ~1.5s LTT

E.g. SSH fails between 1s and 10s LTT (higher layer timer – “LoginGraceTime”)