7-11.6.08@snagstuhl sna: sourceless network architecture jon crowcroft, marcelo bagnulo...

14
7-11.6.08 @Snagstuhl SNA: Sourceless Network Architecture Jon Crowcroft, Marcelo Bagnulo [email protected], [email protected]

Post on 22-Dec-2015

212 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: 7-11.6.08@Snagstuhl SNA: Sourceless Network Architecture Jon Crowcroft, Marcelo Bagnulo Jon.Crowcroft@cl.cam.ac.uk, marcelo@it.uc3m.es

7-11.6.08 @Snagstuhl

SNA: Sourceless Network Architecture

Jon Crowcroft, Marcelo Bagnulo [email protected],

[email protected]

Page 2: 7-11.6.08@Snagstuhl SNA: Sourceless Network Architecture Jon Crowcroft, Marcelo Bagnulo Jon.Crowcroft@cl.cam.ac.uk, marcelo@it.uc3m.es

Why are there src addrs in datagrams?

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| IHL |Type of Service| Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification |Flags| Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time to Live | Protocol | Header Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Example Internet Datagram Header

Remember this? (RFC 791 ) Let’s think about this red bit…

Page 3: 7-11.6.08@Snagstuhl SNA: Sourceless Network Architecture Jon Crowcroft, Marcelo Bagnulo Jon.Crowcroft@cl.cam.ac.uk, marcelo@it.uc3m.es

So why is there a src adr there?

It’s a Datagram, Stupid So Not all higher layers want to send

something back! Indeed, UDP doesn’t

(oh, ok RTP might but RTP has its own src id mechanism (including auth))

But by the time recipitient gets pkt… What makes you think src is still “where” it

“said” it was? Indeed, NATs mean it isn’t/wasn’t

Page 4: 7-11.6.08@Snagstuhl SNA: Sourceless Network Architecture Jon Crowcroft, Marcelo Bagnulo Jon.Crowcroft@cl.cam.ac.uk, marcelo@it.uc3m.es

Some people want to do x+x

IPv4 addresses conflate things in a number of horrible ways

Routing hints+Interface Specification Part of Transport Multiplex Id (aks flow, 5-tuple, pre-

deep-pkt-inspection god) Ingress Police Key

X+x addresses (8+8, 4+4) Before and After X: Locator+Identifier

Only one intepretation… Or real 1 addr + realm 2 addr

E.g. route to egress point in realm 1, then switch to route to realm 2 addr

(and poss. Rewrite source now to be source of inter-realm router…)

Page 5: 7-11.6.08@Snagstuhl SNA: Sourceless Network Architecture Jon Crowcroft, Marcelo Bagnulo Jon.Crowcroft@cl.cam.ac.uk, marcelo@it.uc3m.es

Why are there src addrs in datagrams?

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| IHL |Type of Service| Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification |Flags| Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time to Live | Protocol | Header Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Identifier or Next Realm Addr |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Locator or This Realm Addr | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Internet SNA Header

We have 2 32 bit fields – can be routeable IP addresses in different realms or could be ID+Loc (ID could be HIP or other), or actually anything you want.. … …

NOT MAP or ENCAP !!!

Page 6: 7-11.6.08@Snagstuhl SNA: Sourceless Network Architecture Jon Crowcroft, Marcelo Bagnulo Jon.Crowcroft@cl.cam.ac.uk, marcelo@it.uc3m.es

What’s good about this?

Get 2^32 Internets right now Packets still forwarded by all core routers

and around 60% of ingress routers Can do mobile right immediately Can do multihoming right immediately Can do multipath right immediately “articulation point” (inter-realm) is visible to

end system (unlike in map or encap) Don’t need IPv6 ever or

(modulo next slide )

Page 7: 7-11.6.08@Snagstuhl SNA: Sourceless Network Architecture Jon Crowcroft, Marcelo Bagnulo Jon.Crowcroft@cl.cam.ac.uk, marcelo@it.uc3m.es

What are the problems with this?

Transports that do want to answer TCP, RPC (DNS/SNMP), SCTP, RTP/UDP

ICMP Mistakes, errors, bad stuff

Ingress Policing Net to End signaling in general

Page 8: 7-11.6.08@Snagstuhl SNA: Sourceless Network Architecture Jon Crowcroft, Marcelo Bagnulo Jon.Crowcroft@cl.cam.ac.uk, marcelo@it.uc3m.es

What are the problems with this 1?

Transports that do want to answer We argue they need to answer

a transport entity A network identity, not a location

Furthermore, we can implement lite with Shim, proxy, or new transport noop. Fix to TCP is 4 lines of code Much of the shim6,sixone,hip work applies immediately

Transport Setup needs to send Handle used to lookup 4+4/SNA dst – FQDN

DNS or LISP or other new Server can return FQDN-SNA Mappings

Subsequent packets can do cookie thing (viz SCTP)

Page 9: 7-11.6.08@Snagstuhl SNA: Sourceless Network Architecture Jon Crowcroft, Marcelo Bagnulo Jon.Crowcroft@cl.cam.ac.uk, marcelo@it.uc3m.es

What are the problems with this 2?

ICMP 4 important(ish) cases: Redirect – is link local so triv. Echo – is an “application” so can mod (and not on fast path) Errors (unreachables) – were always a bad idea (except maybe

port unreachable, which is an application/transport MTU discovery- can do by sending fragsizeexceed to

destination In legacy case (if you must) source can always start with a few

IPv4 source addr (locator) packets intermingled just to elicit some of the required answers (e.g. MTU discovery, or traceroute legacy support)

Note, misdirected ICMP errors can be handled, because they include sufficient of the original packet that caused the problem, that an unintended receiver can (and will in most popular known end system Oss) discard

Page 10: 7-11.6.08@Snagstuhl SNA: Sourceless Network Architecture Jon Crowcroft, Marcelo Bagnulo Jon.Crowcroft@cl.cam.ac.uk, marcelo@it.uc3m.es

What are the problems with this 3?

Ingress Policing Can do at ingress link local (or there’s only

one host on xDSL line Or you have transport info…

Have source identifier in transport that matters (i.e. anyone you want to DOS attack will ignore you if you don’t have an identifier, in the new packet

so only if you put one there do you get to go towards source, but you need a source id to be TCP-SNA compliant so you give away your id…so game over.

Page 11: 7-11.6.08@Snagstuhl SNA: Sourceless Network Architecture Jon Crowcroft, Marcelo Bagnulo Jon.Crowcroft@cl.cam.ac.uk, marcelo@it.uc3m.es

Multi-* transport

So I now have a transport multiplex with 2 64 bit id+loc but can wildcard the loc part to do multi-*

(for now, can put it 1 hop away too –i.e. in access router, and proxy for the state – similar to tcp header compression)

M* (Mark-Handley, Mobile, Multihome, Multipath, Mom-n-Pop, Me This does mobile seamlessly This lets me do multi-home And multi-path And each end gets to see which part of the multi-path each packet

arrived over (or is lost or ECN marked)

Multicast currently uses source address as hook to build trees – so multicast routing would have to be SNA aware And map an id to a loc and build a loc based tree Or just stay with IPv4 source address which is fine because most multicast apps are RTP based, and RTP

isn’t broken the way TCP is w.r.t. what it thinks is the originator of data

So RTP/UDP multicast apps work ok if source changes or traffic is multipath so don’t need the SNA change to incentive fixing

Page 12: 7-11.6.08@Snagstuhl SNA: Sourceless Network Architecture Jon Crowcroft, Marcelo Bagnulo Jon.Crowcroft@cl.cam.ac.uk, marcelo@it.uc3m.es

Security & Architectural Considerations Considered Harmless

I think the security considerations are done in HIP and Shim6 and other places

Of course, someone (not me) better check the details are right

I’m a purist in the end-to-end race Source addresses shouldn’t be in the net layer because

not all ULPs want them Giving away your source IPv4 to any tom, dick or harry

(or alice, bob and carol) seems a bit careless Others have already argued source addresses

considered harmful for security – viz http://www.tml.tkk.fi/~pnr/publications/nordsec2001.ps

Debugging the Net just got a tad harder Interworking with all the other

v4/v6/lisp/nat-traversal/sixone folks is going to be exponentially harder (but more for them then this )

Page 13: 7-11.6.08@Snagstuhl SNA: Sourceless Network Architecture Jon Crowcroft, Marcelo Bagnulo Jon.Crowcroft@cl.cam.ac.uk, marcelo@it.uc3m.es

Questions?

What next? I can write this for bsd ‘n linux in about a day….Should I? Three things needed now, 1 later:

SNA-RK (Relay Kink – bit like NAT+Swap) SNA-P (Proxy, in or next to host to do legacy tcp) SNA-IL (Identifier Location mapping service ) SNA-TCHI (Transports Communicating with Host IDs)

Richard Black can probably do this in about 3 minutes (Microsoft) – should I ask him/them if they are interested in playing?

Acknowledgements: Mark Handley’s unpublished 4+4 draft, Trilogy Project and

IMDEA researchers input RFC2110

Page 14: 7-11.6.08@Snagstuhl SNA: Sourceless Network Architecture Jon Crowcroft, Marcelo Bagnulo Jon.Crowcroft@cl.cam.ac.uk, marcelo@it.uc3m.es

The only good NAT & 21st century Vax