Re: [RRG] Re: Does every host need a FQDN name in the future?//re:[RRG] draft-rja-ilnp-intro-01.txt

[Brian E Carpenter <brian.e.carpenter@gmail.com>]

On 2008-08-08 05:51, Tony Li wrote:
> Hi Iljitsch,
>  
> 
> |> |- can't filter on it, so this will be done on locators = no
> |> |renumberability
> |
> |> The local site *can* guarantee that an identifier is unique, so it  
> |> can in
> |> fact filter on inbound identifiers.  Filtering on remote 
> |identifiers  
> |> is
> |> trivially insecure (regardless of uniqueness) due to spoofing.
> |
> |The id/loc overload allows for a return routability check;  
> |cryptographic identifiers allow for a challenge.
> 
> 
> True, but now we're drifting into the realm of how much security is provided
> just by filtering.  My strong preference is that if you want security, it
> should be provided by real crypto, not just by identifier filtering.  Again,
> spoofing identifiers is going to happen.
> 
> 
> |> |- can't look locators up using the id, so a working locator must
> |> |always accompany id = reduced multihoming and mobility
> |
> |> I'm failing the logical leap here.  Could you spell out where this  
> |> is a
> |> problem?
> |
> |If you find yourself in the situation where the currently known  
> |locator(s) are unreachable, you can't ask the other side for 
> |locators.  
> |If you also can't look them up, you can't contact the correspondent  
> |through another locator and the session is dead or can't be  
> |established. With mobility this is especially likely as a mobile host  
> |will often not know its new locator before the old one stops working.
> |
> |In theory a locator->locator lookup would be possible, maybe through  
> |the DNS. In that case, the ID value is superfluous.
> 
> 
> Except that the locator isn't host-specific.  As before, you could
> conceivably do a reverse lookup on (locator, id) -> name -> {locator} to get
> the new set of locators.
> 
> 
> |Maybe we should simply deprecate identifiers. After all, I know who I  
> |am and you know who you are, and the packets get there through the  
> |locators. And if identity is really necessary, higher layers can  
> |manage it (TLS etc).
> 
> 
> Or, perhaps, you're taking Christian's side that the real identifier is the
> FQDN.  The locally unique identifier is simply a form of a nonce.  ;-)

No ;-) needed, I think. An identifier needs to be unique for as long as
it needs to be unique for. If we stipulate that no transport connection
has a lifetime greater than T, then the transport ID only needs
to be unique for T+epsilon. (Where lifetime means the time after which
all ends of the connection have deleted all relevant state.) So you can
imagine a world in which the FQDN is used in a discovery phase to get
a fresh unique transport ID and a set of locators that currently
reach that transport ID.

   Brian

--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg