Transcript SNA: Sourceless Network Architecture Jon Crowcroft, Marcelo Bagnulo ,

SNA: Sourceless Network Architecture
Jon Crowcroft, Marcelo Bagnulo
[email protected],
[email protected]
7-11.6.08
@Snagstuhl
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…
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
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-deeppkt-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…)
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 !!!
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 )
What are the problems with this?

Transports that do want to answer


ICMP


TCP, RPC (DNS/SNMP), SCTP, RTP/UDP
Mistakes, errors, bad stuff
Ingress Policing

Net to End signaling in general
What are the problems with this 1?

Transports that do want to answer

We argue they need to answer



Furthermore, we can implement lite with




a transport entity
A network identity, not a location
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)
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
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.
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
Security & Architectural
Considerations Considered Harmless

I think the security considerations are done in HIP
and Shim6 and other places


I’m a purist in the end-to-end race




Of course, someone (not me) better check the details are
right 
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/nattraversal/sixone folks is going to be exponentially harder
(but more for them then this )
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
The only good NAT & 21st century Vax