Sorry for the spam Robin, I forgot to include the rrg-list. On Wed, 2010-02-03 at 10:46 +1100, Robin Whittle wrote: > Hi Javier, > > You wrote: > > >> However, I think such problem such as you suggested exists with Name > >> Based Sockets. I haven't yet recieved clarification from Christian, > >> but see my concerns about his model: > >> > >> Role Level Name Based Sockets? > >> > >> Text name <---] FQDN > >> Identifier <---] > >> Locator <---- IPv6 address > > > > As per my understanding > > > > Role Level > > > > Text name <---] FQDN > > Identifier <---] FQDN (used as a nonsensical text string) > > Locator <---- whatever address > > > > There are no DNS queries done after the initial connection. > > This is only true if the second host, which you refer to as the > "server", doesn't care whether the packet it sends goes to the host > with the Identifier which was in the first packet, or to some other host.
As I see it, this is the same model as we use today. The initiator resolves an FQDN to an IP and then chats with that IP. In NBS, the initiator resolves the FQDN and sends it's packets to that IP. The fact that it attaches its own name to the sent packets dosen't affect what you are commenting. I can see that it is desirable to be able to verify the link between the ID (FQDN) and the locator (IP). But I wouldn't claim that it is a _requirement_ in this case. > For many other applications, it is important that the respondent know > for sure that the packet it sends won't go to any other host than the > one with the same Identity as that contained in the packet it received. Yes, and the solutions to that are many. E.g. TLS (SSL). But I don't see why it _must_ be part of the network/transport implementation. > This is easy with today's naming structure, where the IP address > functions as both Identifier and Locator. The respondent gets a > packet with source address XYZ and can simply reply with a packet > addressed to XYZ. (In neither naming model can the respondent know > for sure that the initial packet was sent by the host with the > Identifier and Locator indicated by the source field(s) of that > packet, but that is a separate issue.) No, it cannot be certain that a packet comming form IP a.b.c and claims to be from FQDN "host_name" is actually from "host_name". Rather, "host_name" is used as a label for abstraction. Perhaps this _should_ be verifiable. If it is however, I would suggest a path where it does _not_ require an initial negotiation to happen, but rather where the verification happens during the connection. The trade-off is no first-packet-delay in exchange for no cool multi-homing/mobility features for the first few packets. The bottom line is: Yes, I believe you do loose verification of the source identity comparable to IP addresses and IP ranges. Perhaps this property is important, I for sure don't use it in my day to day life (other than filtering in my NAT box). Does any one else have any views on this? > CEE completely alters the naming model from the current one in which > Identifier and Locator roles are both played by the one IP address, > to one of several models in which these roles are played by different > objects in different namespaces. But, it is not "completly altering the naming model". To my knowlege, the majority of software on enduser devices resolve a FQDN to an IP. Unless you are programming against the socket-interface directly, you don't even perceive the resolution to IP. Yes, I do need to have "hard-coded" locators to be able to find a DNS service. But after that, I don't use IP's any more. > CES architectures retain the current model. CEE architectures change > it to the "Locator / Identifier Separation" model, which is what I am > arguing against. This model will forever burden hosts with extra > work, involve extra traffic, extra packets and longer delays and > greater sensitivity to packet loss. I disagree :) In particular if this is in comparison between CEE and CES (read 'client change' and 'network change'). * Assuming end-host always do FQDN -> IP resolutions, independent of the underlying architecture. * Assuming end-hosts _want_ to be mobile, and applications _will_ implement their own extensions to achieve that. CES dosen't solve those points. > > Please see: > > Today's "IP addr. = ID = Loc" naming model should be retained > http://www.ietf.org/mail-archive/web/rrg/current/msg05864.html > > I hope you will write about why you agree or disagree with this. I'll do so later, it's quite a mass of text :) I guess this whole reply can be condensed to: "We already live in an FQDN (id) => IP (loc) world." // Javier
signature.asc
Description: This is a digitally signed message part
_______________________________________________ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg
