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

From: Javier Ubillos <[email-masked]>
Date: Mon, 03 May 2010 11:57:06 +0200

On Thu, 2010-04-29 at 16:20 +0200, Alberto García wrote:
> 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...

Sorry, I was being deliberately vague.
I'm not sure what the details are, and I did not want to rule some
possibility out due to my own misunderstandings. 

> 
> |  
> |  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. 

Then I'm confused about how the context is used and re-used.
I thought that each new call to socket() would create a new context,
independently of source/destination address pairs.

> 
> |  
> |  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.

Ofcourse :)

Thanks for your reply
// Javier Ubillos

---

From: Javier Ubillos <[email-masked]>
Date: Mon, 03 May 2010 12:06:11 +0200

On Fri, 2010-04-30 at 02:02 -0700, Erik Nordmark wrote:
> On 04/28/10 05:20 AM, Javier Ubillos wrote:
> > 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?
> 
> 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.
> 

It looks as if 1.5 was what I was unknowingly referring to.

However, if not when the locator becomes unreachable, when is an ULID
declared invalid?

When that locator _does_ respond, but with invalid context (or some
other expected 'error' behavior)?
When it becomes un-routable? (prefix change)

> > 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.
> 
> 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.
> 

Thank you for that tip. I'll make sure I read up!

Thank you
// Javier

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 03 May 2010 09:19:29 -0700

> However, if not when the locator becomes unreachable, when is an ULID

I think you are asking about the definition of "invalid", which is 
specified in RFC 4862. (It is when the address allocation is withdrawn, 
whether using stateless address allocation or DHCPv6.) In an 
implementation that typically corresponds to the address no longer being 
configured e.g., doesn't show up in ifconfig -a.

This is completely unrelated to an address being unreachable.

Note that the address allocation needs to be withdrawn before the 
address can possibly be reassigned to some other node.

> When it becomes un-routable? (prefix change)

I don't know what an "invalid context" means. Please explain.

A shim6 host can loose state, which can result in one end having context 
state and the other end not having it. RFC 5533 specifies how the 
protocol recovers from context state loss.

    Erik

---

From: Alberto García <[email-masked]>
Date: Tue, 4 May 2010 10:52:08 +0200

Hi,

|  -----Mensaje original-----
|  De: Javier Ubillos [mailto:[email-masked]]
|  Enviado el: lunes, 03 de mayo de 2010 11:57
|  Para: Alberto García
|  CC: [email-masked]; [email-masked]
|  Asunto: RE: [shim6] Problems with ULID (IP) over longer sessions.
|  
|  On Thu, 2010-04-29 at 16:20 +0200, Alberto García wrote:
|  > 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...
|  
|  Sorry, I was being deliberately vague.
|  I'm not sure what the details are, and I did not want to rule some
|  possibility out due to my own misunderstandings.
|  
|  >
|  > |
|  > |  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.
|  
|  Then I'm confused about how the context is used and re-used.
|  I thought that each new call to socket() would create a new context,
|  independently of source/destination address pairs.

This is discussed in RFC 5533, D.1. "Context Granularity"

Regards,
Alberto

|  
|  >
|  > |
|  > |  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.
|  
|  Ofcourse :)
|  
|  
|  Thanks for your reply
|  // Javier Ubillos