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

[Alberto García <[e-mail]>]

Hi,

|  -----Mensaje original-----
|  De: [e-mail] [mailto:[e-mail]] En nombre de
|  Javier Ubillos
|  Enviado el: miércoles, 28 de abril de 2010 14:21
|  Para: [e-mail]
|  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