Here is a (500 word) alternative to Javier Ubillos' critique of Name Based Sockets:
http://tools.ietf.org/html/draft-irtf-rrg-recommendation-04#section-15.2 It has some things in common, but much of it is different. For instance, it is important to note that NBS is only practical for IPv6 and that like most or all other Core-Edge Elimination architectures, there must be extra data transferred between any two communicating hosts, and typically extra delays due to the need for lookups involving a global query server system: DNS. I have attached a Word file of the alternative critique. I am corresponding with Christian to clarify my understanding of some parts of NBS, in particular: Should the peer (page 7) do a lookup on the FQDN it gets from the host and verify that the source address in the initial packet is one of those returned by DNS, before sending the second packet back, with the host's FQDN and this peer's FQDN to complete the Initial Name Exchange? How is this exchange secured against the reply being spoofed by an attacker? (Maybe it doesn't have to be.) How are the Initial Address Exchange and subsequent Address Exchanges secured against spoofed packets? In these Address Exchanges, should one host accept IP addresses from the other host if these do not appear in the list of IP addresses returned by a DNS lookup of the other host's name? How does NBS perform the equivalent of "round-robin DNS" - where a FQDN DNS lookup returns multiple IP addresses, each one being for a separate host? Initially I thought that the FQDN played the role of both "Text name" and "Identifier", with the role of "Locator" being played by one or more IP addresses. However, to do this load-distributing "round-robin DNS", NBS hosts must distinguish between other hosts not just by their FQDN, but the combination of a single FQDN and one or more IP addresses. The following critique doesn't depend on the answers to these questions - except perhaps the last. I may update it in the next few days. I just want to get this alternative critique out to the list because Javier's critique doesn't include all the points which I think are important. - Robin The following is based on: (PDF file created 2009-12-15): Simplifying Internet Applications Development With A Name-Based Sockets Interface Christian Vogt preliminary paper version http://christianvogt.mailup.net/pub/vogt-2009-name-based-sockets.pdf (PDF file created 2009-12-15) Alternative critique -------------------- Named Based Sockets (NBS) is a Core-Edge Elimination (CEE) architecture intended to provide portability, multihoming, TE and mobility for end-user networks of all sizes in a highly scalable manner. With ubiquitous NBS adoption there would be little or no need for end users to use PI (edge) space. NBS cannot be introduced for IPv4. It could be introduced without disruption to IPv6, using a Destination Options extension header. An NBS-aware host - with an NBS stack and NBS-aware applications - does not need PI space to provide portability, multihoming with session continuity, TE or mobility for all communications with other NBS-aware hosts, because these hosts establish and maintain their communication sessions by way of their FQDNs. The NBS stack handles how these hosts use their one or more IP addresses - which may change at any time. As with all other CEE architectures, host stacks must be upgraded to implement NBS. As with most or all other CEE architectures, host applications must be modified to use the NBS API - which uses only FQDNs to specify the host with which communication sessions are initiating or accepted. For some applications, the changes would be relatively minor - if their protocols are easy to adapt to NBS. Other applications may only be able to adopt NBS by substantially changing the way they operate. As with other CEE architectures, the benefits of portability, multihoming, inbound TE and mobility only apply to communication sessions conducted with other hosts whose stacks and applications have been upgraded to be NBS-aware. This would make it difficult or more likely impossible to achieve the wide-enough adoption necessary for substantial routing scaling benefits - or substantial benefits to the adopters. Ubiquitous adoption of NBS would involve every host in greater routing and addressing responsibilities. These include DNS lookups before responding to a request to open a session, in order to check that source address of the request is one which is returned in a DNS lookup of the FQDN supplied in the request. Pairs of potentially long (<=253 character) FQDNs are typically sent for one or more initial packets in both directions. Following that - and at any time during the session - one or more IPv6 addresses are also exchanged. Arguments against requiring all hosts to do this concern delays due to the typically global nature of the DNS lookups, and the extra delays and reliability concerns which arise from hosts being on slow, long-latency and potentially unreliable wireless links. In NBS, the role of Locator is performed by IPv6 addresses. It is not clear how the roles of text name and Identifier are performed. If the FQDN performs both roles, then it will not be possible to do the equivalent of "round-robin DNS". If this is possible, then the text name role is performed by the FQDN, and the Identifier role must be performed by an as-yet unspecified combination of FQDN and one or more IP addresses - which is more complex than in other CEE architectures.
NBS-draft-critique-00-RW.doc
Description: MS-Word document
_______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
