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

Re: Agenda for Vienna

On maandag, mei 19, 2003, at 14:32 Europe/Amsterdam, Erik Nordmark wrote:

Some notions that seem relatively undisputed:



- we separate the identifier and locator functions so we can have

multiple locators and still have a single identifier

- IP in transit works with locators, everything above the IP layer 
with

the identifier




Yep. And I think tunneling is one approach to implement this.




:-)



I don't care much for tunnels. Now if they would really solve anything 
I guess I could live with another wasted 40 bytes per packet but I 
don't think they do as you can't trust any information in the inner 
header. So either you need crypto or you check the inner header against 
know information. But if you knew in the first place, why add the 
header...?




There might be an attribute of transparency that can be derived from 
the above

(not that I know we'd agree on it):

Assume that layer X in the stack is operating on locators (where there 
might

be arguments for X=transport and X=application, but that is separate

discussion) then X will send a packet with some source locator and some

destination locator.

The transpareency attribute would be that the X layer on the receiver

receive the same packet (apart from TTL) as the sender sent.



I think this is what happens, and I sure think this should be what 
happens.




This leads to the following questions:





- what should identifiers look like?





More detailed questions in this area are:
 - are identifiers flat or do they have internal structure?




We know that looking up stuff in a flat namespace isn't pretty. If we 
truly want the identifier to be the identifier, then we need to be able 
to look up stuff such as locators based on the identifier. We can also 
have something at an even higher level that is used as the "real" 
identifier, I think this is what the HIP people do by mapping from the 
FQDN to the crypto ID and the locators but not from the crypto ID 
directly to the locators.




 - are (the fields of) the identifiers managed for uniqueness and other

   purposes or are they more or less random? (If there is internal 
structure

   potentially different fields can be different in this respect.)



I would like to make as few assumptions about the identifiers as 
possible, so we can use different kinds of identifiers and not just 
IPv6 addresses. FQDNs would make good identifiers. Cryptographic hashes 
are also useful identifiers for some purposes. But that means we have 
to design for the lowest common denominator = no real structure = hard 
to look up.




- when receiving packets, how do we know (= better than take her word
for it) the correspondent's identifier?





Agreed.





If there is a system that maps to identifiers to locators there is

also the issue of authenticating and authorizing entries (new and 
updates)

to that system.



And yet it has to be simple enough that people who don't know an X.509 
certificate from a piece of toilet paper can deploy it.




Then there is the address selection problem. We know that the current

"pick one and die if it doesn't work" approach is no good so we have 
to

come up with something better.




I assume you meant "locator selection" and not "address selection". :-)



Aarghh, yes...

Iljitsch