Subject: [shim6] Problems with ULID (IP) over longer sessions.

From: Javier Ubillos <[email-masked]>
Date: Wed, 28 Apr 2010 14:20:59 +0200

Hi folks.

Some time ago I heard a discussion about a potential issue with shim6.
That the Upper Layer Identifier (ULID), chosen as the first pair of
locators used in the communication, could cause
problems/confusion/somethingelse when those locators where no longer
used by the hosts. I.e not in the locator lists.

I'm unsure about the details of what would cause the problem or what the
consequences could be.

My own first reaction is that if a software believes it's communicating
with an IP (a shim6 ULID), it might try to spawn more sockets/flows to
that IP.

Have this kind of issues been discussed previously on this list? ( I
couldn't find any discussions about it).
Have any one on this list some more detailed thoughts/experience about
what could cause issues?

I'm asking this because a couple of colleges and I are looking at using
alternative ULIDs which hopefully would be more of a match with session
identifiers/FQDNs or similar.

Thank you
// Javier Ubillos

---

From: Alberto García <[email-masked]>
Date: Thu, 29 Apr 2010 16:20:18 +0200

Hi,

|  -----Mensaje original-----
|  De: [email-masked] [mailto:[email-masked]] En nombre de
|  Javier Ubillos
|  Enviado el: miércoles, 28 de abril de 2010 14:21
|  Para: [email-masked]
|  CC: Zhongxing Ming
|  Asunto: [shim6] Problems with ULID (IP) over longer sessions.
|  
|  Hi folks.
|  
|  Some time ago I heard a discussion about a potential issue with shim6.
|  That the Upper Layer Identifier (ULID), chosen as the first pair of
|  locators used in the communication, could cause
|  problems/confusion/somethingelse when those locators where no longer
|  used by the hosts. I.e not in the locator lists.

That's not much precise...

|  
|  I'm unsure about the details of what would cause the problem or what the
|  consequences could be.
|  
|  My own first reaction is that if a software believes it's communicating
|  with an IP (a shim6 ULID), it might try to spawn more sockets/flows to
|  that IP.

This is completely reasonable. If a Shim6 context exists for a
communication, Shim6 will use the locators in use for the existing context,
even if the ULIDs are no longer locators. 
RFC 5533 even supports establishing a new session for a ULID which is not a
valid locator, by using other addresses and including the ULID as an option.

Don't see here any problem. 

|  
|  Have this kind of issues been discussed previously on this list? ( I
|  couldn't find any discussions about it).
|  Have any one on this list some more detailed thoughts/experience about
|  what could cause issues?
|  
|  I'm asking this because a couple of colleges and I are looking at using
|  alternative ULIDs which hopefully would be more of a match with session
|  identifiers/FQDNs or similar.

Well, security issues for these alternative ULIDs should be carefully
considered.

Regards,
Alberto

|  
|  Thank you
|  // Javier Ubillos

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 30 Apr 2010 02:02:09 -0700

> Have any one on this list some more detailed thoughts/experience about

Section 1.5 in RFC 5533 says that the communication must be terminated 
should the ULID become invalid. That handles the case of a ULID 
potentially being assigned to a different host.

Note that a ULID might be unreachable and hence unusable as a locator 
without being invalid.

> identifiers/FQDNs or similar.

It is possible to extend SHIM6 to handle 128-bit ULIDs that are never 
usable as locators. It has performance impact because one would need to 
do a ID->locator lookup before sending the first packet. A possible way 
to do this was written up in draft-nordmark-shim6-esd.

    Erik