[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Notes about identifier - locator separator

     a) perform the identifier -> locator translation at
        the end-host so that all packets leaving the end-host
        have a proper locator,

Is the singular "a proper locator" intentional or a mistake?
I think each packet need both a source locator and a destination locator
in order to enable ICMP errors and e.g. TCP SYN+ACK messages to be returned
without anybody having to perform a mapping - since doing such a mapping
in response to a single packet would be a field day for DoS attacks.

Well, I think the singular form was primarily a mistake, but it could
have been intentional.  If we go to the separated ID/locator world,
the semantics of the source address change more than the semantics
of the destination address.  The source address could either function
as the return address, as you describe, or it could be used by the
network to record the return route for traceback purposes, or it could
be both.  However, combining both functions into a single field has
a two edged result: in one hand it prevents reflection for DoS purpose,
in the other hand it makes it hard to ask replies to be sent to a
topologically different location, e.g., due to asymmetric routing
or traffic conditions.

I guess I already mentioned our half tongue-in-the-cheek NordSec paper
considering some of the aspects: "IPv6 Source Addresses Considered Harmful"
http://www.tml.hut.fi/~pnr/publications/nordsec2001.pdf

I have never thought that the source address field would carry a source
identifier.  From my point of view, such an arrangement would be
silly: you couldn't use the ID for routing, and you couldn't use
it for reliably identifying the source either, since anybody could
lie in the first packet they send.


   Apparently there must also be some way of finding the
   locators based on the identifier or a name.  Apparently
   there is a huge number of possible solutions to this.
   One of the most obvious ones is to store both identifiers
   and locators into the DNS, and make the name resolution
   library to fetch both.

That doesn't work e.g. for the passive side of a TCP conenction where
the transport protocol, and often not even the application, do a DNS lookup.
Unless you carry a source identifier plus a list of source locators in
e.g. the TCP SYN packet.

This has been discussed to an extend in the other messages, but one
additional comment:  It is sometimes enough to carry a single source
locator in the TCP SYN packet; the rest can be sent later.

What comes to the applications that use getpeername etc and send
the address in the protocol, personally I don't care too much
about the (apparently rare) cases where something gets broken.
In most cases the recipient will know the identifier already,
and is able to do the mapping.

On the other hand, ...
In addition to the constraint you list, presumaby we do not want to require that multi-party applications change significantly. Thus an application should
be able to take the address it got from getaddrinfo(), the local pr remote address of some existing connection (getsockname() and getpeername() type
stuff) and pass that address to another peer in the multi-party application.
Thus if you only expose the identifier to the application in these calls,
then you must be able to perform the identifier->locator mapping
in other hosts that have not done a DNS lookup of the hostname.
... I do imagine that something like Distributed Hash Tables (DHT)
could be used to implement identifier->locator mapping, if really
needed.

--Pekka Nikander