Subject: shim6 @ ietf70

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 30 Nov 2007 17:28:36 +0100

Hi,

We don't have a slot in Vancouver next week, which makes sense because  
all the drafts are in last call. However, there have been some issues  
brought up that may or may not be of importance for those documents.  
Maybe it would be useful to have a small gathering of shim6ers to  
discuss all of this? It would be especially useful if most of the  
draft authors could find the time for this.

If you're interested, please send me your availability and I'll  
summerize to the list.

Delivery-date: Fri, 30 Nov 2007 16:30:42 +0000
From: Iljitsch van Beijnum <[email-masked]>
To: shim6-wg <[email-masked]>
Subject: shim6 @ ietf70
Date: Fri, 30 Nov 2007 17:28:36 +0100

Hi,

We don't have a slot in Vancouver next week, which makes sense because  
all the drafts are in last call. However, there have been some issues  
brought up that may or may not be of importance for those documents.  
Maybe it would be useful to have a small gathering of shim6ers to  
discuss all of this? It would be especially useful if most of the  
draft authors could find the time for this.

If you're interested, please send me your availability and I'll  
summerize to the list.

Delivery-date: Sun, 25 Nov 2007 10:21:40 +0000
Cc: shim6-wg <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
To: Geoff Huston <[email-masked]>
Subject: Re: TSV-DIR Review of draft-ietf-shim6-protocol-09.txt
Date: Sun, 25 Nov 2007 11:20:21 +0100

On 25 nov 2007, at 9:42, Geoff Huston wrote:

> Fowarded....

Please note that the various reviews and last calls are currently  
generating shim6-related discussions on the IETF discussion list,  
which aren't all copied to the draft authors or the shim6 list.

Delivery-date: Sun, 25 Nov 2007 08:43:28 +0000
Date: Sun, 25 Nov 2007 19:42:58 +1100
From: Geoff Huston <[email-masked]>
To: shim6-wg <[email-masked]>
Subject: Re: TSV-DIR Review of draft-ietf-shim6-protocol-09.txt

Fowarded....

 From [email-masked] Fri Nov 23 14:05:57 2007
Date: Fri, 23 Nov 2007 06:05:44 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: Iljitsch van Beijnum <[email-masked]>
cc: shim6-wg <[email-masked]>, [email-masked]
Subject: Re: TSV-DIR Review of draft-ietf-shim6-protocol-09.txt

> Note that we explicitly say that this applies to local knowledge that an
> address doesn't work, although then the issue is confused by mentioning
> deprecation, which leaves the address involved still reachable.

Yes.

> The issue is also different from regular operation, because if I pull out my
> ethernet cable when I'm not running shim6, the only two options are keeping
> the session open until it times out or giving up immediately. The latter is
> suboptimal because I could put the cable back in before the session times out.
> But with shim6, it's possible to rehome the connection to a different
> interface so it keeps running whether or not the cable is plugged in again.

My concern is about wireless media which can experience large variations
in signal/noise ratio, in the process generating transient "link down"
indications.   This could cause those connections to migrate to other
media/interfaces.  If the host has implemented the strong host model, then
when the transient "link down" is resolved, the connection won't resume
using the prior outbound interface.  This could lead to applications
experiencing sub-optimal conditions  long-term  based on a transient
event.

There are a few approaches that come to mind:

a. Continue to make decisions based on timers, perhaps using the "link
down" indication as a hint to lower the timer values (e.g. requiring
only two retransmissions instead of three)

2. Suggest the weak host model to be used along with SHIM6, so that if
the "link down" proves to be transient, the connection will migrate back
to its former outgoing interface.

> It would be possible to adjust the keepalive interval based on RTT estimates,
> though.

If the information is available, this might be the best approach.

Delivery-date: Sat, 24 Nov 2007 14:34:37 +0000
Cc: shim6-wg <[email-masked]>, [email-masked]
From: Iljitsch van Beijnum <[email-masked]>
To: Bernard Aboba <[email-masked]>
Subject: Re: TSV-DIR Review of draft-ietf-shim6-protocol-09.txt
Date: Sat, 24 Nov 2007 13:31:37 +0100

On 23 nov 2007, at 15:05, Bernard Aboba wrote:

> My concern is about wireless media which can experience large  
> variations
> in signal/noise ratio, in the process generating transient "link down"
> indications.   This could cause those connections to migrate to other
> media/interfaces.

Wouldn't that be something that should be fixed in the driver for that  
interface? Declaring a link to be down has significant implications on  
many systems, this shouldn't be done at the drop of a hat for links  
where this determination isn't easily made. Having drivers declare  
links down too soon and then having the next layer ignore that is not  
a good solution, especially because there are also link layers which  
can determine their up/down status much more accurately.

> If the host has implemented the strong host model, then
> when the transient "link down" is resolved, the connection won't  
> resume
> using the prior outbound interface.  This could lead to applications
> experiencing sub-optimal conditions  long-term  based on a transient
> event.

Hm, I must say that I don't know off the top of my head if shim6 will  
automatically rehome to the primary address pair after some time. I'll  
have to reread the specifications. Or does anyone else remember this?

> There are a few approaches that come to mind:

> a. Continue to make decisions based on timers, perhaps using the "link
> down" indication as a hint to lower the timer values (e.g. requiring
> only two retransmissions instead of three)

I'm not a fan of timer-based decision making if it can be avoided  
because it's extra work and you pretty much always wait too long or  
not long enough.

> 2. Suggest the weak host model to be used along with SHIM6, so that if
> the "link down" proves to be transient, the connection will migrate  
> back
> to its former outgoing interface.

That would be good, yes.

>> It would be possible to adjust the keepalive interval based on RTT  
>> estimates,
>> though.

> If the information is available, this might be the best approach.

But is it worth the trouble? The timeout will remain the same (10  
seconds unless something else is established during the shim context  
setup) so the only difference is that if the RTT is 10 ms you could  
choose to send a keepalive after 9980 ms but if it's 1500 ms you send  
the keepalive after 6000 ms. Implementers will probably just use 3  
seconds so 3 keepalives are seen before a timeout or 4 seconds so 2  
are seen before a timeout.

Delivery-date: Fri, 23 Nov 2007 11:49:10 +0000
Cc: shim6-wg <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
To: Bernard Aboba <[email-masked]>
Subject: Re: TSV-DIR Review of draft-ietf-shim6-protocol-09.txt
Date: Fri, 23 Nov 2007 12:46:57 +0100

[redirecting to the shim6 list]

>> When traffic is flowing in both directions or when there is no   
>> traffic,
>> there is no need to send keeplives.

> That makes sense.  It would be helpful for the protocol document
> to include this explanation in the keepalive section

You're right, this is not made explicit in the document.

I'll leave it up to others to decide if another iteration is  
warranted, but if so, i think we should add this.

> (and also for
> the Failure Detection specification to remove the reference to
> TCP Keepalives, since they're unrelated).

You're right.

> Yes.  If the transport layer can make the information available, then
> it seems to me that Failure Detection could be improved, providing
> for TCP a better approximation of the functionality in SCTP.

Which REAP values do you think could be changed based on information  
available to transport protocols?

>>> In general, it would not be desirable for SHIM6 to initiate the re-
>>> homing of a TCP connection due to a transient failure.  Link layer  
>>> "down"
>>> indications or resulting address deprecations are examples of this.

>> The trouble is, how do you know a problem is transient?

> You don't.  That's why "link down" indications are best ignored by
> both the Internet and Transport layers.

A multihoming solution ignoring outages kind of defeats the  
purpose.  :-)

Note that we explicitly say that this applies to local knowledge that  
an address doesn't work, although then the issue is confused by  
mentioning deprecation, which leaves the address involved still  
reachable.

The issue is also different from regular operation, because if I pull  
out my ethernet cable when I'm not running shim6, the only two options  
are keeping the session open until it times out or giving up  
immediately. The latter is suboptimal because I could put the cable  
back in before the session times out. But with shim6, it's possible to  
rehome the connection to a different interface so it keeps running  
whether or not the cable is plugged in again.

>> About address deprecation: I do seem to remember a discussion  
>> where  the
>> conclusion was that deprecation is no reason to stop using an   
>> address
>> just because it's deprecated. Telling the other end that an  address
>> should no longer be used when it's deprecated would have that   
>> effect, so
>> if the proto document mandates that, that could be  problematic.

> It is suggested not mandated.  However, it's hard to see a  
> circumstance
> in which this would be helpful (and it will often hurt), so I'd  
> prefer to
> see the suggestion removed.

Marcelo, Erik?

>>> 6.  Interactions of SHIM6 with congestion control.  Section 4.3 of  
>>> the
>>> Failure Detection document talks about exploration timeout values.
>>> Exploration can be kicked off if no inbound traffic is
>>> received within Send Timeout (default = 10 seconds).

>>> The first observation is that the Send Timeout should probably  
>>> depend
>>> on the RTO estimate, as it does in SCTP.  Otherwise we could have a
>>> network with a high RTO and SHIM6 exploration could commence  
>>> after  RTO
>>> is backed off only a few times.  This would be undesirable from a
>>> congestion control point of view.

>> We need the timeout to be somewhat long to accommodate the case  
>> where  a
>> host receives a packet, then does processing and finally sends an  
>> answer.
>> However, it also needs to be fairly short so that we have time  to  
>> repair
>> a failure before the user, application or transport protocol  give  
>> up.  I
>> don't think alignment with the transport's retransmission  timeout  
>> makes
>> sense here.

> The RTO represents the best estimate of the maximum time that can
> expire until an ACK is expected.   So while I'd agree that failover  
> should
> occur prior to transport connection teardown, it is not desirable  
> for this
> to occur before a minimum number of RTOs has expired.  The time that
> this takes will depend on the RTO.  For example, if the goal is to  
> re-home
> after 3 timeouts, using an RTOmin of 1 second, three timeouts will  
> take
> 7 seconds.   However, where the RTO is much larger,  10 seconds might
> correspond to fewer timeouts (maybe only 2).

Ok, the text about how the retransmission timeout is computed in RFC  
793 is somewhat complex, so rather than risking getting it wrong, let  
me ask you: what are values one would expect to see for the RTO in a  
number of common deployments, such as a low RTT / high bandwidth LAN,  
a long fat pipe, and a low bandwidth / high delay mobile link?

We do not mandate an interval for generating keepalives except a  
maximum of 8 seconds, but I would expect implementers to go for 3  
seconds based on the 10 second timeout. The other end can't then  
dynamically reduce the timeout, at most it can increase it.

It would be possible to adjust the keepalive interval based on RTT  
estimates, though.

>>> The suggested value of the Initial Probe Timeout (500ms)
>>> is less than RTOmin and 4 probes can be sent before initiating
>>> exponential backoff.  This seems like it could violate "conservation
>>> of packets".  Why doesn't exponential backoff begin immediately?

>> Then you'd either have to send the first few probes in quick   
>> succession
>> without leaving a reasonable amount of time for responses  to come  
>> back,
>> or it would take very long for the first 5 or so probes  to go out.  
>> 500 ms
>> is still relatively aggressive as it's well below  the maximum  
>> observed
>> RTTs on the internet.

> The issue is kicking off SHIM6 exploration simultaneously with
> transport layer congestive backoff.  While SHIM6 exploration is  
> designed
> to find alternate paths, the paths could still share a bottleneck.    
> So
> while transport layer congestive backoff  is attempting to let packets
> drain from the network, SHIM6 will be injecting more packets.  In  
> these
> situations, aggressively sending Probes will not improve the  
> likelihood
> that they will get through.

Hm, I don't see that happening very easily. If there is a routine  
level of congestion, you would still expect to see at least one packet  
coming in every 10 seconds. So it should be rare for path exploration  
to be triggered by congestion. If the congestion is bad enough that  
this does happen, then I'd consider that a feature, as shim6 will then  
most likely select another path, avoiding the congested part of the  
network.

> With respect to 500ms being "well below the maximum observed RTT on  
> the
> Internet", I'd observe that RTOmin is set at 1 second.  So my
> recommendation would be to set the minimum Initial Probe Timeout to
> RTOmin, and allow upwards adjustment based on the RTO estimate, if
> available.

In a transport protocol, you're sending every packet to the same  
destination over (presumably) the same path, so there is no value in  
sending message 2 if there's still a chance that there will be an  
answer for message 1. In REAP, ideally, we'd want to probe all paths  
immediately and then use the one for which we get the first answer.  
That would be too aggressive. 500 ms is short enough to allow an  
answer to come back in 95% or so of all cases, but it also has the  
property that if the first probed path has a rather long delay (700 ms  
mobile link) while the second probe has a much better delay (150 ms  
wired) then the second probe will see a reply faster than the first  
one so we select the second path, which is probably the right choice  
in this case.

Delivery-date: Thu, 22 Nov 2007 17:01:59 +0000
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
From: Iljitsch van Beijnum <[email-masked]>
To: Bernard Aboba <[email-masked]>
Subject: Re: TSV-DIR Review of draft-ietf-shim6-protocol-09.txt
Date: Thu, 22 Nov 2007 17:59:45 +0100

On 22 nov 2007, at 17:17, Bernard Aboba wrote:

> However, this relationship is not explored.  The TCP keepalive  
> interval
> is generally kept quite large, partly out of a desire not to tear down
> idle TCP connections due to a transient failure.  The SHIM6 keepalive
> interval during idle is not defined in the Failure Detection document,
> but my impression was that it could be much shorter and this would
> seem to collide with the philosophy of TCP keepalives.

Shim6 REAP keepalives aren't sent when a shim6 context is idle.

The REAP protocol assumes that traffic must always be bidirectional,  
so when there has been outgoing traffic but no incoming traffic, there  
must be a failure. Keepalives exist to accommodate the cases where  
there is legitimately only incoming traffic but no return traffic.  
When traffic is flowing in both directions or when there is no  
traffic, there is no need to send keeplives.

> The SCTP algorithms make extensive use
> of transport layer information such as retransmission counts, which
> the SHIM6 Failure Detection document seems to assume will be  
> unavailable.

Right. Shim6 must work for all kinds of communication. However, it  
would be good to make use of transport protocol knowledge when  
available. You feel there are missed opportunities in this area?

> In general, it would not be desirable for SHIM6 to initiate the re- 
> homing
> of a TCP connection due to a transient failure.  Link layer "down"
> indications or resulting address deprecations are examples of this.

The trouble is, how do you know a problem is transient?

About address deprecation: I do seem to remember a discussion where  
the conclusion was that deprecation is no reason to stop using an  
address just because it's deprecated. Telling the other end that an  
address should no longer be used when it's deprecated would have that  
effect, so if the proto document mandates that, that could be  
problematic.

(One scenario is a router that no longer sends RAs but still continues  
to route, it would be possible to use the addresses after they've  
become deprecated until they become invalid in this case.)

> 6.  Interactions of SHIM6 with congestion control.  Section 4.3 of the
> Failure Detection document talks about exploration timeout values.
> Exploration can be kicked off if no inbound traffic is
> received within Send Timeout (default = 10 seconds).

> The first observation is that the Send Timeout should probably depend
> on the RTO estimate, as it does in SCTP.  Otherwise we could have a
> network with a high RTO and SHIM6 exploration could commence after  
> RTO is
> backed off only a few times.  This would be undesirable from a  
> congestion
> control point of view.

We need the timeout to be somewhat long to accommodate the case where  
a host receives a packet, then does processing and finally sends an  
answer. However, it also needs to be fairly short so that we have time  
to repair a failure before the user, application or transport protocol  
give up. I don't think alignment with the transport's retransmission  
timeout makes sense here.

> The suggested value of the Initial Probe Timeout (500ms)
> is less than RTOmin and 4 probes can be sent before initiating
> exponential backoff.  This seems like it could violate "conservation
> of packets".  Why doesn't exponential backoff begin immediately?

Then you'd either have to send the first few probes in quick  
succession without leaving a reasonable amount of time for responses  
to come back, or it would take very long for the first 5 or so probes  
to go out. 500 ms is still relatively aggressive as it's well below  
the maximum observed RTTs on the internet.

Iljitsch

Delivery-date: Mon, 19 Nov 2007 19:01:10 +0000
Cc: shim6 <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: shim6-proto minor remarks
Date: Mon, 19 Nov 2007 19:50:51 +0100
To: Matthijs Mekking <[email-masked]>

thanks!

i will correct those in the next review

regards, marcelo

El 19/11/2007, a las 14:50, Matthijs Mekking escribi=F3:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hello,
>
> Just some minor remarks about the shim6-proto.
>
> MAX_UPDATE_TIMEOUT is not defined in Section 14, but is mentioned =20
> in the
> draft.
>
> Some typo's:
> Page 9:   behaviour -> behavior (since the rest of the document also
>           uses 'beahvior')
> Page 42:  pruposes -> purposes
> Page 56:  unstrucutred -> unstructured
> Page 72:  recieve -> receive
> Page 78:  If CGA (and not HBA) is used to verify one or more fo the
>           locators included in the locator listfo the locators ->
>           remove the words 'fo the'
> Page 85:  extenson header -> extension header
> Page 85:  porpuses -> purposes
> Page 91:  presudoheader -> pseudoheader
> Page 98:  pruposes -> purposes
> Page 100: singly-homed -> single-homed
> Page 108: Tiemout -> Timeout (2x)
>
> Regards,
>
> Matthijs Mekking
> [email-masked]
> Foundation NLnet Labs
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFHQZSTV9yvZHaszAMRAna+AJ9apvlgLWCLK5k3doUzA/wgL/40igCfe63+
> qNkapdItLIE4c/czPmykKFo=3D
> =3DnEtY
> -----END PGP SIGNATURE-----
>

Delivery-date: Mon, 19 Nov 2007 18:52:25 +0000
Cc: shim6 <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: shim6-hba minors
Date: Mon, 19 Nov 2007 19:50:46 +0100
To: Matthijs Mekking <[email-masked]>

thanks!

i will correct those in the next review

regards, marcelo

El 19/11/2007, a las 15:24, Matthijs Mekking escribi=F3:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> for this draft, only typos:
> Page 6:  identifer -> identifier
> Page 6:  infrastucture -> infrastructure
> Page 6:  oposed -> opposed
> Page 6:  appraoch -> approach
> Page 12: tto -> to
> Page 16: perfomed -> performed
> Page 18: reccomendations -> recommendations
> Page 18: whil ->  while
> Page 18: implemntations -> implementations
> Page 20: Parameter Data Strcutre -> Parameter Data Structure
>
> Regards,
>
> Matthijs Mekking
> [email-masked]
> Foundation NLnet Labs
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFHQZyPV9yvZHaszAMRArAXAJ0ZAjfU/k8suJyxZaCOqepHAqZcqgCglPIn
> L19kUW1PpwKI+YXJAapXGGo=3D
> =3DZYzU
> -----END PGP SIGNATURE-----
>

Delivery-date: Mon, 19 Nov 2007 14:25:33 +0000
Date: Mon, 19 Nov 2007 15:24:15 +0100
From: Matthijs Mekking <[email-masked]>
To: shim6 <[email-masked]>
Subject: shim6-hba minors

for this draft, only typos:
Page 6:  identifer -> identifier
Page 6:  infrastucture -> infrastructure
Page 6:  oposed -> opposed
Page 6:  appraoch -> approach
Page 12: tto -> to
Page 16: perfomed -> performed
Page 18: reccomendations -> recommendations
Page 18: whil ->  while
Page 18: implemntations -> implementations
Page 20: Parameter Data Strcutre -> Parameter Data Structure

Regards,

Matthijs Mekking
[email-masked]
Foundation NLnet Labs

Delivery-date: Mon, 19 Nov 2007 13:52:08 +0000
Date: Mon, 19 Nov 2007 14:50:11 +0100
From: Matthijs Mekking <[email-masked]>
To: shim6 <[email-masked]>
Subject: shim6-proto minor remarks

Hello,

Just some minor remarks about the shim6-proto.

MAX_UPDATE_TIMEOUT is not defined in Section 14, but is mentioned in the
draft.

Some typo's:
Page 9:   behaviour -> behavior (since the rest of the document also
          uses 'beahvior')
Page 42:  pruposes -> purposes
Page 56:  unstrucutred -> unstructured
Page 72:  recieve -> receive
Page 78:  If CGA (and not HBA) is used to verify one or more fo the
          locators included in the locator listfo the locators ->
          remove the words 'fo the'
Page 85:  extenson header -> extension header
Page 85:  porpuses -> purposes
Page 91:  presudoheader -> pseudoheader
Page 98:  pruposes -> purposes
Page 100: singly-homed -> single-homed
Page 108: Tiemout -> Timeout (2x)

Regards,

Matthijs Mekking
[email-masked]
Foundation NLnet Labs

Delivery-date: Thu, 08 Nov 2007 12:50:33 +0000
Date: Thu, 08 Nov 2007 14:48:31 +0200
From: Jari Arkko <[email-masked]>
To:  [email-masked]
CC: shim6 <[email-masked]>, "W. Mark Townsley" <[email-masked]>
Subject: shim6-proto and shim6-hba

Marcelo,

Thanks for your responses and the updated draft. I have
finally found time to look through the diffs. The new draft
satisfies the issues I raised in the AD review. The draft
will now move forward.

Next I'll need a new version for the HBA draft. I think we
closed all the issues on that one too, so its only a matter
of submitting it and me sending it forward to Last Call.

Jari

Delivery-date: Wed, 07 Nov 2007 09:13:38 +0000
From: "Alvaro Vives Martinez" <[email-masked]>
To: <[email-masked]>, "'shim6'" <[email-masked]>
Subject: RE: shim6 control packets coming from unkown locators
Date: Wed, 7 Nov 2007 10:11:43 +0100
Reply-To: [email-masked]

Hi Geoff,

I am sorry for the delayed response but a project meeting took place and
decisions were taken.

Because of no resources left for this task given that the project is in the
finishing stages, the ENABLE project will not face the task of analyzing
SHIM6 draft from the mobility point of view.

Anyhow, some project partners have showed interest in this issue and they
probably will address this issue in future efforts.

Thanks,
Alvaro Vives
Consulintel

> -----Mensaje original-----
> De: Geoff Huston [mailto:[email-masked]]
> Enviado el: lunes, 22 de octubre de 2007 14:26
> Para: Thierry Ernst
> CC: [email-masked]; 'Brian E Carpenter'; 'Jari Arkko';
> 'shim6'
> Asunto: Re: shim6 control packets coming from unkown locators
>=20
>=20
>=20
> Thierry Ernst wrote:
> >
> > Since we are opening the discussion on the combination of shim6 with a
> > mobility solution
>=20
> Well for "we" being equal to the SHIM6 WG, then no, I don't think that
> was the intent  - it certainly was not my intent in my initial response.
>=20
> I thought that the token was over to the ENABLE project to investigate
> this a little further and report back.
>=20
>=20
> , I would like to remind about the multihoming analysis
> > of NEMO and MIPv6 where issues related to shim6 are mentioned:
> >
> > NEMO: http://www.ietf.org/rfc/rfc4980.txt
> > MIPv6:
> > http://www.ietf.org/internet-drafts/draft-ietf-monami6-mipv6-analysis-
> 03.txt
> >
> >
> > I just wonder if these documents are being considered in the ENABLE
> > project.
> >
>=20
> I trust that the ENABLE folk will pick up these pointers.
>=20
>=20
> > We are looking for comments from the shim6 WG on the MIPv6 analysis.
>=20
>=20
> Right now we are in the process of working through the AD's initial
> comments leading to IESG review of the core documents.
>=20
> >
> > Thierry
> >
> >
> >> There was a pretty long-standing design objective in shim6 that it did
> >> no deliberate harm to mobility solutions (and indeed did no deliberate
> >> harm to IPv6 at all of course!), but equally that it did not attempt
> >> to position itself as an alternative approach to mobility to
> >> mobileipv6 and that shim6's objective was the multihoming case where
> >> the agility across addresses was across space rather than across time
> >> - i.e. the alternative potential addresses were simultaneously
> >> available and explorable rather than sequentially available and
> >> potentially singly explorable.
> >>
> >> Right now the core specification of SHIM6 has passed working group
> >> last call and the document editors are resolving comments from the
> >> area director prior to submitting this as a proposed standard to the
> >> IESG for publication.
> >>
> >> So right now this possibility of making changes to the UPDATE REQUEST
> >> message is not readily "open" at this point in time in terms of adding
> >> this into the working group's agenda of study for this activity as a
> >> procedural matter.
> >>
> >> However the invocation of procedure should not necessarily preclude
> >> consideration of good ideas and if the ENABLE project is willing to
> >> undertake further analysis of the issue to figure out the full extent
> >> of changes to shim6 for their intended application to mobility, and
> >> come to a conclusion that a particular set of changes would be
> >> necessary and sufficient for their use in this context, and that such
> >> changes would completely benign for the intended shim6 multihoming
> >> case from the perspective of performance and security, then I suspect
> >> that the case to adopt such a change to shim6 would be stronger. So I
> >> would encourage the ENABLE project to undertake more investigation of
> >> this and provide a report to the shim6 working group when such a study
> >> is complete.
> >>
> >> On the other hand you need to be aware that the documents are well
> >> advanced along the track now, so time is an important consideration if
> >> the ENABLE project wanted to head down such a path.
> >>
> >> wg chair hat off:.....
> >> As a purely personal comment:
> >> However I am a little surprised at this request given that I read from
> >> the ENABLE site "ENABLE will concentrate on the following main areas
> >> of work: Enhancement of Mobile IPv6...Enrichment of the basic mobility
> >> service provided by Mobile IPv6 ..This activity will investigate
> >> scalability and performance issues that Mobile IPv6 might raise "
> >> Given that shim6 is not mobileipv6 and shim6 really has not been
> >> designed to operate efficiently within the timing constraints that we
> >> conventionally believe to be associated with mobility then it is not
> >> altogether obvious that further refinement of shim6 would necessarily
> >> produce a solution that was superior to mobileipv6 in any case.
> >>
> >>
> >> regards,
> >>
> >>   Geoff
> >>
> >>
> >> Alvaro Vives Martinez wrote:
> >>> Hi Marcelo,
> >>>
> >>> Within the ENABLE project (www.ist-enable.org) SHIM6 has been
> >>> evaluated as a
> >>> possible mobility solution. The fact that UPDATE REQUEST message that
> >>> comes
> >>> from an unknown locator is not accepted was a problem in this context.
> >>>
> >>> So, if this possibility is still open I would like to push for it, at
> >>> least
> >>> for the UPDATE REQUEST message and if no security risks are
> >>> introduced, of
> >>> course.
> >>>
> >>> This would open the field for SHIM6 as a mobility solution, there are
> >>> other
> >>> missing pieces being evaluated as well, because of its LOC/ID split
> >>> nature.
> >>> This would be in addition to the multihoming support.
> >>>
> >>> We will follow with attention whatever is said about this issue.
> >>>
> >>> Regards,
> >>> Alvaro Vives
> >>> Consulintel
> >>>
> >>>> -----Mensaje original-----
> >>>> De: [email-masked] [mailto:[email-masked]] En nombre de
> >>>> marcelo
> >>>> bagnulo braun
> >>>> Enviado el: viernes, 28 de septiembre de 2007 8:48
> >>>> Para: Brian E Carpenter
> >>>> CC: Jari Arkko; shim6
> >>>> Asunto: Re: shim6 control packets coming from unkown locators
> >>>>
> >>>> Hi Brian,
> >>>>
> >>>>
> >>>> El 27/09/2007, a las 21:51, Brian E Carpenter escribi=F3:
> >>>>
> >>>>> Marcelo,
> >>>>>
> >>>>> On 2007-09-28 02:45, marcelo bagnulo braun wrote:
> >>>>>
> >>>>> <big snip>
> >>>>> ...
> >>>>>> For the R1bis message, it would result in a reduction of security,
> >>>>>> since anyone knowing the context tag value could tear down a
> >>>>>> context even if he is not located along the path. this could be
> >>>>>> enough, though
> >>>>>> So, the question is general for all the spec, should we support
> >>>>>> control messages from unknown locators?
> >>>>> This makes me very nervous that we'd be opening a fairly big
> security
> >>>>> hole that would be quite painful to close.
> >>>>>
> >>>> agree that security issues should be addressed carefully, but i think
> >>>> this is possible, at least for UPDATE packets. Probe packets may
> >>>> require a bit more thought, and will require an UPDATE before
> >>>> actually sending packets to the locators, but i think it should work.
> >>>>
> >>>> Regards, marcelo
> >>>>
> >>>>
> >>>>>    Brian
> >>>
> >>>
> >>>
> >>>
> >>> **********************************************
> >>> The IPv6 Portal: http://www.ipv6tf.org
> >>>
> >>> Bye 6Bone. Hi, IPv6 !
> >>> http://www.ipv6day.org
> >>>
> >>> This electronic message contains information which may be privileged
> >>> or confidential. The information is intended to be for the use of the
> >>> individual(s) named above. If you are not the intended recipient be
> >>> aware that any disclosure, copying, distribution or use of the
> >>> contents of this information, including attached files, is prohibited.
> >>>
> >>>
> >>>
> >

**********************************************
The IPv6 Portal: http://www.ipv6tf.org

Bye 6Bone. Hi, IPv6 !
http://www.ipv6day.org

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

Delivery-date: Wed, 07 Nov 2007 09:08:34 +0000
From: "Alvaro Vives Martinez" <[email-masked]>
To: <[email-masked]>, "'shim6'" <[email-masked]>
Subject: RE: shim6 control packets coming from unkown locators
Date: Wed, 7 Nov 2007 10:05:19 +0100
Reply-To: [email-masked]

Hi,

Thanks for the pointers. I have passed them to my colleagues in ENABLE.

Best regards,
Alvaro

> -----Mensaje original-----
> De: Thierry Ernst [mailto:[email-masked]]
> Enviado el: lunes, 22 de octubre de 2007 13:27
> Para: Geoff Huston
> CC: [email-masked]; 'Brian E Carpenter'; 'Jari Arkko';
> 'shim6'
> Asunto: Re: shim6 control packets coming from unkown locators
>=20
>=20
> Since we are opening the discussion on the combination of shim6 with a
> mobility solution, I would like to remind about the multihoming analysis
> of NEMO and MIPv6 where issues related to shim6 are mentioned:
>=20
> NEMO: http://www.ietf.org/rfc/rfc4980.txt
> MIPv6:
> http://www.ietf.org/internet-drafts/draft-ietf-monami6-mipv6-analysis-
> 03.txt
>=20
> I just wonder if these documents are being considered in the ENABLE
> project.
>=20
> We are looking for comments from the shim6 WG on the MIPv6 analysis.
>=20
> Thierry
>=20
>=20
> > There was a pretty long-standing design objective in shim6 that it did
> > no deliberate harm to mobility solutions (and indeed did no deliberate
> > harm to IPv6 at all of course!), but equally that it did not attempt to
> > position itself as an alternative approach to mobility to mobileipv6 and
> > that shim6's objective was the multihoming case where the agility across
> > addresses was across space rather than across time - i.e. the
> > alternative potential addresses were simultaneously available and
> > explorable rather than sequentially available and potentially singly
> > explorable.
> >
> > Right now the core specification of SHIM6 has passed working group last
> > call and the document editors are resolving comments from the area
> > director prior to submitting this as a proposed standard to the IESG for
> > publication.
> >
> > So right now this possibility of making changes to the UPDATE REQUEST
> > message is not readily "open" at this point in time in terms of adding
> > this into the working group's agenda of study for this activity as a
> > procedural matter.
> >
> > However the invocation of procedure should not necessarily preclude
> > consideration of good ideas and if the ENABLE project is willing to
> > undertake further analysis of the issue to figure out the full extent of
> > changes to shim6 for their intended application to mobility, and come to
> > a conclusion that a particular set of changes would be necessary and
> > sufficient for their use in this context, and that such changes would
> > completely benign for the intended shim6 multihoming case from the
> > perspective of performance and security, then I suspect that the case to
> > adopt such a change to shim6 would be stronger. So I would encourage the
> > ENABLE project to undertake more investigation of this and provide a
> > report to the shim6 working group when such a study is complete.
> >
> > On the other hand you need to be aware that the documents are well
> > advanced along the track now, so time is an important consideration if
> > the ENABLE project wanted to head down such a path.
> >
> > wg chair hat off:.....
> > As a purely personal comment:
> > However I am a little surprised at this request given that I read from
> > the ENABLE site "ENABLE will concentrate on the following main areas of
> > work: Enhancement of Mobile IPv6...Enrichment of the basic mobility
> > service provided by Mobile IPv6 ..This activity will investigate
> > scalability and performance issues that Mobile IPv6 might raise " Given
> > that shim6 is not mobileipv6 and shim6 really has not been designed to
> > operate efficiently within the timing constraints that we conventionally
> > believe to be associated with mobility then it is not altogether obvious
> > that further refinement of shim6 would necessarily produce a solution
> > that was superior to mobileipv6 in any case.
> >
> >
> > regards,
> >
> >   Geoff
> >
> >
> > Alvaro Vives Martinez wrote:
> >> Hi Marcelo,
> >>
> >> Within the ENABLE project (www.ist-enable.org) SHIM6 has been
> >> evaluated as a
> >> possible mobility solution. The fact that UPDATE REQUEST message that
> >> comes
> >> from an unknown locator is not accepted was a problem in this context.
> >>
> >> So, if this possibility is still open I would like to push for it, at
> >> least
> >> for the UPDATE REQUEST message and if no security risks are
> >> introduced, of
> >> course.
> >>
> >> This would open the field for SHIM6 as a mobility solution, there are
> >> other
> >> missing pieces being evaluated as well, because of its LOC/ID split
> >> nature.
> >> This would be in addition to the multihoming support.
> >>
> >> We will follow with attention whatever is said about this issue.
> >>
> >> Regards,
> >> Alvaro Vives
> >> Consulintel
> >>
> >>> -----Mensaje original-----
> >>> De: [email-masked] [mailto:[email-masked]] En nombre de
> >>> marcelo
> >>> bagnulo braun
> >>> Enviado el: viernes, 28 de septiembre de 2007 8:48
> >>> Para: Brian E Carpenter
> >>> CC: Jari Arkko; shim6
> >>> Asunto: Re: shim6 control packets coming from unkown locators
> >>>
> >>> Hi Brian,
> >>>
> >>>
> >>> El 27/09/2007, a las 21:51, Brian E Carpenter escribi=F3:
> >>>
> >>>> Marcelo,
> >>>>
> >>>> On 2007-09-28 02:45, marcelo bagnulo braun wrote:
> >>>>
> >>>> <big snip>
> >>>> ...
> >>>>> For the R1bis message, it would result in a reduction of security,
> >>>>> since anyone knowing the context tag value could tear down a
> >>>>> context even if he is not located along the path. this could be
> >>>>> enough, though
> >>>>> So, the question is general for all the spec, should we support
> >>>>> control messages from unknown locators?
> >>>> This makes me very nervous that we'd be opening a fairly big security
> >>>> hole that would be quite painful to close.
> >>>>
> >>> agree that security issues should be addressed carefully, but i think
> >>> this is possible, at least for UPDATE packets. Probe packets may
> >>> require a bit more thought, and will require an UPDATE before
> >>> actually sending packets to the locators, but i think it should work.
> >>>
> >>> Regards, marcelo
> >>>
> >>>
> >>>>    Brian
> >>
> >>
> >>
> >>
> >> **********************************************
> >> The IPv6 Portal: http://www.ipv6tf.org
> >>
> >> Bye 6Bone. Hi, IPv6 !
> >> http://www.ipv6day.org
> >>
> >> This electronic message contains information which may be privileged
> >> or confidential. The information is intended to be for the use of the
> >> individual(s) named above. If you are not the intended recipient be
> >> aware that any disclosure, copying, distribution or use of the
> >> contents of this information, including attached files, is prohibited.
> >>
> >>
> >>

**********************************************
The IPv6 Portal: http://www.ipv6tf.org

Bye 6Bone. Hi, IPv6 !
http://www.ipv6day.org

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

Delivery-date: Thu, 01 Nov 2007 15:11:48 +0000
Cc: shim6 <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: shim6 control packets coming from unkown locators
Date: Thu, 1 Nov 2007 16:06:59 +0100
To: Jari Arkko <[email-masked]>

Ok, i will leave as it is now and submit a reviwd version containing =20
all previous comments from the AD review

Regards, marcelo

El 01/11/2007, a las 12:25, Jari Arkko escribi=F3:

> Marcelo,
>
>>>
>>>> o Other control messages (Update, Keepalive, Probe): Deliver to the
>>>> context with CT(local) equal to the Receiver Context Tag included
>>>> in the packet. Verify that the IPv6 source address field is part
>>>> of Ls(peer) and that the IPv6 destination address field is part of
>>>> Ls(local). If not, send a R1bis message.
>>>>
>>>
>>> Does this prevent properly handling a Probe if the peer
>>> did not bother to / did not have time to report the
>>> address as its own? I would expect that hosts might not
>>> report all addresses, if they have many, and if there's
>>> a sudden rehoming to a previously unknown prefix,
>>> the host HAS to send a Probe from this previously
>>> unknown address. This appears OK from a security
>>> perspective, at least if we are using CGAs and not
>>> HBAs.
>>
>>
>> later on, you mention that:
>>
>>
>>>
>>>> o An attacker which is present on the path so that it can find out
>>>> the context tags, can generate a R1bis message after it has moved
>>>> off the path. For this packet to be effective it needs to have a
>>>> source locator which belongs to the context,
>>>>
>>>
>>> Really? What if CGA is used, must the R1bis even then come from a
>>> previously known address?
>>
>>
>> In the shim6 protocol as currently defined, all shim6 control =20
>> messages
>> (after R2) must come from locators contained in the locator set known
>> by the peer. this applies once the context has been established. For
>> I1,R1,I2 and R2 other constraints apply.
>> So, basically, Update messages, probe messages, R1bis messages, must
>> come from a locator included in the locator set known by the peer.
>>
>> I guess the motivation for this is that the shim6 protocol design was
>> focused on multihoming and not in mobility
>>
>> So, i guess it would be possible to update the spec in order to
>> support receiving those messages from previously unkown locators. In
>> the case of UPDATE messages could be easy, because we could require
>> that the update message must contain the new locator that is being
>> used as source address, signed.
>> In the case of the probe message, it may be ok to receive messages
>> from an unknown locator, but it wouldn't be possible to send packets
>> to it until it hasn't been properly verified i.e. an update message
>> signed has been received
>> For the R1bis message, it would result in a reduction of security,
>> since anyone knowing the context tag value could tear down a context
>> even if he is not located along the path. this could be enough, =20
>> though
>>
>> So, the question is general for all the spec, should we support
>> control messages from unknown locators?
>
> We don't want to turn shim6 into a mobility protocol (at least
> not in this RFC; if research projects have an interest in
> looking at that they should feel free to do so and report
> back to us later).
>
> However, I think there are legitimate reasons for wanting to
> update to a previously unreported locator even in multihoming.
> As a result, I would be interested in seeing the Update capable
> of doing that.
>
> But this does not imply that we'd have to support such changes
> in the middle of context buildup.
>
> The Update change is easy. The one thing that worries me though
> is Probe.
>
> Making that work would need some extra logic.
>
> Hm.
>
> Lets make this a future extension.
>
> Jari
>
>

Delivery-date: Thu, 01 Nov 2007 11:27:56 +0000
Date: Thu, 01 Nov 2007 13:25:27 +0200
From: Jari Arkko <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
CC: shim6 <[email-masked]>
Subject: Re: shim6 control packets coming from unkown locators

Marcelo,

>>
>>> o Other control messages (Update, Keepalive, Probe): Deliver to the
>>> context with CT(local) equal to the Receiver Context Tag included
>>> in the packet. Verify that the IPv6 source address field is part
>>> of Ls(peer) and that the IPv6 destination address field is part of
>>> Ls(local). If not, send a R1bis message.
>>>
>>
>> Does this prevent properly handling a Probe if the peer
>> did not bother to / did not have time to report the
>> address as its own? I would expect that hosts might not
>> report all addresses, if they have many, and if there's
>> a sudden rehoming to a previously unknown prefix,
>> the host HAS to send a Probe from this previously
>> unknown address. This appears OK from a security
>> perspective, at least if we are using CGAs and not
>> HBAs.
>
>
> later on, you mention that:
>
>
>>
>>> o An attacker which is present on the path so that it can find out
>>> the context tags, can generate a R1bis message after it has moved
>>> off the path. For this packet to be effective it needs to have a
>>> source locator which belongs to the context,
>>>
>>
>> Really? What if CGA is used, must the R1bis even then come from a
>> previously known address?
>
>
> In the shim6 protocol as currently defined, all shim6 control messages
> (after R2) must come from locators contained in the locator set known
> by the peer. this applies once the context has been established. For
> I1,R1,I2 and R2 other constraints apply.
> So, basically, Update messages, probe messages, R1bis messages, must
> come from a locator included in the locator set known by the peer.
>
> I guess the motivation for this is that the shim6 protocol design was
> focused on multihoming and not in mobility
>
> So, i guess it would be possible to update the spec in order to
> support receiving those messages from previously unkown locators. In
> the case of UPDATE messages could be easy, because we could require
> that the update message must contain the new locator that is being
> used as source address, signed.
> In the case of the probe message, it may be ok to receive messages
> from an unknown locator, but it wouldn't be possible to send packets
> to it until it hasn't been properly verified i.e. an update message
> signed has been received
> For the R1bis message, it would result in a reduction of security,
> since anyone knowing the context tag value could tear down a context
> even if he is not located along the path. this could be enough, though
>
> So, the question is general for all the spec, should we support
> control messages from unknown locators?

We don't want to turn shim6 into a mobility protocol (at least
not in this RFC; if research projects have an interest in
looking at that they should feel free to do so and report
back to us later).

However, I think there are legitimate reasons for wanting to
update to a previously unreported locator even in multihoming.
As a result, I would be interested in seeing the Update capable
of doing that.

But this does not imply that we'd have to support such changes
in the middle of context buildup.

The Update change is easy. The one thing that worries me though
is Probe.

Making that work would need some extra logic.

Hm.

Lets make this a future extension.

Jari