Hi Christian, trying to come up with more arguments and here is an early simple idea, more or less a brain dump that you (all of you) should try to shoot down.
NAPT devices have to keep track of both IP addresses and ports, the binding can become quite complex. But if the connection also have host identifiers in the header of the datagrams the NAPT box doesn't need to keep track of the ports - the connection can be tracked with the help of the host identifier. Not so interesting but it gets better if the host identifier is added to the DNS record. By adding a host identifier to the DNS record the NAPT box could accept traffic from the Internet and redirect it to the correct host in the private network. This can be achieved by having the DNS entry as the IP address with the public IP address of the NAPT box and the host identifier with the global unique identifier of the internal server. Then you create a static binding at the middlebox - a host identifier is binded to the internal IP address of the server. Now the middlebox can handle both inbound and outbound connections, with one public PA IP address, and still provide end-to-end visibility in case you need to troubleshoot sessions. Also the meaning of DNS changes slightly, a DNS look up tells us today "what is the local IP address of the server". With the host identifier added the DNS look up would tell us "via this attachment point at the border of Internet the internal host can be reached". How then to achieve multi-homing? Well, add a second middlebox to the organization's network - the second middlebox should have a PA-address from another service provider and then two DNS records are needed, same host identifier record with two different A-records, each with weights so one of them is the preferred path (just as an example). If the primary path goes down the clients should after a while try to use the secondary path. And here is the session identifier needed - since the network path changes TCP connections needs to be restarted, this can be achieved if there is a session identifier coupled to the host identifier. But this will also open up for man-in-the-middle attacks - should we try to solve this on the network or transport layer? I don't think so, instead the transport layer should inform the application layer that the network parameters has changed (could be an attack) and then it is up to the application layer - should the credentials for this session be re-verified or not - it depends on the content of the application (the lower layers should not get involved with the content). If this is really doable the outcome is that PI-addresses are no longer attractive, you can publish services towards Internet with your internal addressing scheme - the routing architecture of an organization is an internal affair and Internet doesn't need to know about how it is constructed. But still external customers, partners etc. can reach your published services with the help of the host identifier. It seems that adding a host identifier to the Internet architecture will provide better visibility of end-to-end connectivity and at the same time hide more the routing architecture, interesting... Or do I miss something, this is an early idea and there might be some severe flaw in my thinking. -- patte On Tue, Jun 30, 2009 at 11:14 PM, Christian Vogt<[email protected]> wrote: > Hi Patte - > > You are absolutely right that decoupling services and sessions from > their location would be highly useful. The current conflation of > identification and location certainly has serious disadvantages. For > example, decoupling would mitigate the routing scalability problem. > > But are you saying that using a host identity as part of service or > session identification is necessary to achieve this decoupling? > > - Christian > > > > On Jun 30, 2009, at Patrick Frejborg wrote: > >> Hi Christian, >> >> I think service identification and session identification is belonging >> to the transport layer in the IP reference model - in the OS model >> they are on separate layers. So in the IP model I would collapse them >> under one identifier, I think that is what we have today. E.g a TCP >> connection is identified by the five tuples; source and destination >> addresses, source and destination ports and protocol. But here the >> problems starts, a connection/session/association is identified by >> elements from the network layer (source and destination addresses) - >> thus the border between the network and transport layer gets very >> blurred. I believe that this is the reason why we today need to have >> global unique IP addresses, with global addresses we can identify >> connections on hosts, security and NAT nodes - it is the only method >> at the moment, right? >> >> Adding a host identifier to the IP reference model wouldn't add much >> value - unless it can decouple the dependency between network and >> transport layer. If the host identifier could give an identity for a >> connection without deep dependency to the network layer an new world >> opens. I.e. a connection could be identified by some other mechanisms >> than the network tuples. Then we could migrate from a single-level >> address scheme to a multilevel address scheme and create a better >> routing architecture without the need to have global unique addresses. >> And mobility would be much easier to achieve, i.e. if connections are >> identified by something else it doesn't matter when the underlying >> network changes - the application will not be aware and doesn't care >> about the network parameters. >> >> SCTP goes in this direction but the current mainstream transport >> protocol is TCP. Guess people will not move their applications to use >> SCTP instead of TCP in order to improve the routing architecture of >> Internet, right? >> I think the only way is to fool TCP that underlying network is still >> the same though it isn't - something is needed between the network and >> transport layer that the applications aren't aware of. By having a new >> layer we could change the underlying addressing scheme with backwards >> compatibly to the current addressing scheme - not all stacks needs to >> be upgraded since it is backwards compatible. This will not improve >> mobility but mobility will be improved once people are starting to >> move their applications to use the host identifier to identify >> connections on the transport layer. Would people move their >> applications to support mobility? I think it is matter of time, there >> are so much mobile devices connected to Internet that enterprises will >> see business opportunities to move applications to an infrastructure >> that better supports mobility, this is long term vision but guess it >> will happen. >> >> So I think the identifier(s) should be designed to decouple the >> transport layer from the network layer. Opponents will say that all >> hosts must be upgraded, this is not true if the the new stack is made >> backwards compatible with fallback mechanisms to the current >> architecture. >> >> >> -- patte > > > > _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
