Robin Whittle allegedly wrote on 01/21/2010 20:52 EST: > Introduction of CEE would involve new host protocols and usually new > application code and APIs
These are much less of a problem than they used to be. However, in any case improvements to the routing system should not depend on changes to endpoints. A change to routing architecture that makes no difference in routing scalability until every endpoint in a domain is updated isn't a wise idea. > I believe the optimal arrangement for the Internet is not the CEE > approach of requiring *all* hosts to take on more responsibilities > for routing and addressing - which generally involves more state, > more computation, delays in initiating contact with other hosts and > the sending and receiving more and/or longer packets. It also > involves a lot of extra work, packets and therefore delays whenever > the host gets a different (physical, "locator") address. This can > happen frequently with wireless mobile devices, even when they are > stationary. Better to leave mobility out of your argument. For a mobile node, everything you mention is going to happen anyway, and during handoff, getting a new IP address is one of the smaller problems (compared to, e.g. authentication and authorization and the infrastructure to support it). Also there are mitigation mechanisms whereby a node often doesn't need a new address. But you have omitted the burden on the routing domains that serve those endpoints -- the burden on the edge networks' administration. As the network changes its upstream connectivity, it has to adjust its policies to handle changes in addresses given to endpoints. This is another example of why you want to decouple progress in the endpoints (multihoming, multipathing, mobility, identification, federated identity etc.) from routing and addressing architecture (scaling, robustness, churn, reachability, complexity, administrative overhead etc.). They may benefit each other, but neither should depend on the other, and each should be motivated on its own merits. Patrick Frejborg allegedly wrote on 01/22/2010 03:54 EST: > I agree here, do we really need to have cryptographic solution on the > network layer? Generally I agree. Validation of various sorts is between consenting parties, which may be routers, tunnel endpoints, session endpoints, applications, whatever. How much validation to have on which particular packets should be up to the communicating pairs. Validation will be done at a higher layer anyway if at all. Consider video distribution -- the main bandwidth consumer on mobile networks today -- which runs multiple connections with a unifying validation scheme. > We are trying to remove the IP address overload (identifier and > locator) but if we are not careful we could introduce some other > overload mechanism that somebody has to deal with in the future. The > transport layer can take care of things and also the application layer > can take care of things, such as cryptographic Right, and if the upper layers have to do something anyway, why should it be done in a lower layer? The end-to-end principle applies inside a stack as well as across a network. The good reasons for providing a function at a lower layer are if it cannot be done at a higher layer (access to certain information is needed), or if it is certain that all higher layer clients should use that function. > If the host mobility is solved on the network layer it could get > complicated as you describe above. I think the host mobility is an > issue for the transport protocol - if we are trying to solve that on > the network layer IMHO we are overloading the transport and network > layer. > > I think MPTCP, http://tools.ietf.org/html/draft-ford-mptcp-multiaddressed-02, > doesn't add that much overhead :-D but let's not forget that MPTCP is just one mechanism. We already have application-layer mechanisms in place that may never be abandoned in favor of multipath transport. Also let's get away from the idea that a whole node ("host") is what is mobile. The future is virtual. Individual sessions will change their apparent location independently of each other. They need to be able to do so arbitrarily, so simply adding session classes (e.g. "voice") to a whole node mobility protocol isn't enough. Xu Xiaohu allegedly wrote on 01/22/2010 04:58 EST: > In the current Internet architecture, the overlapping of IP address > semantics makes it possible to use uRPF to avoid IP (as the role of ID) > spoofing to some extent. However, in an ID/locator split architecture, ID > spoofing will be much harder to prevent provided there is no any mechanism > for ID authentication (uRPF is useless for ID checking). If cryptographic > identifiers are not used, ID authentication would have to be relied on a > third-party certification infrastructure. But that's the way it is today. Communication endpoints are at higher layers, and those that care will always check the validity of the other endpoints' identifiers. They do not depend on, or even expect, support from lower layers for that. End-to-end argument goes here. Patrick Frejborg allegedly wrote on 01/22/2010 05:40 EST: > The architectural question is - do the ID authentication issue belong > to the network or to the hosts (or the application they use), where > should the ID authentication be applied? See arguments above about when it is appropriate for a lower layer to provide a function for the use of a higher layer. Brian E Carpenter allegedly wrote on 01/22/2010 15:07 EST: > I think that authentication at the network ID level is important to > to ensure that the physical origin of unwanted traffic can be checked > and/or proved. The advantage of using a node ID is that a lower layer (network layer) can take care of housekeeping before delivering packets to the actual recipient (higher layer), and the higher layer can trust that everything is okay. Disregarding the end-to-end argument and the trust problems, you still have the issue of virtualization. When you're talking to me, you don't get to know what my physical origin is. Any of the sessions we have open can move individually from box to box, and even from virtual box to virtual box. The only constant identifiers are associated with the session or group of sessions. Those identifiers can be ad hoc and temporary once initial AAA is taken care of. Noel Chiappa allegedly wrote on 01/23/2010 11:26 EST: > > From: Patrick Frejborg <pfrejb...@gmail.com> > > > Yes, and I believe that the Trojan Horse is called MPTCP :-) > > Support for multiple PA addresses does certainly help with the multi-homing > aspects, but does it help with number (address) portability at all? Just for clarity: Multipath transport does not assume or rely on the endpoint receiving multiple PA addresses from a network. Scott _______________________________________________ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg