Subject: Re: shim6 control packets coming from unkown locators
From: Geoff Huston <[email-masked]>
To: Thierry Ernst <[email-masked]>
Cc: [email-masked], 'Brian E Carpenter' <[email-masked]>, 'Jari Arkko' <[email-masked]>, 'shim6' <[email-masked]>
Date: Mon, 22 Oct 2007 22:26:24 +1000

Thierry Ernst wrote:
> 
> Since we are opening the discussion on the combination of shim6 with a 
> mobility solution

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.

I thought that the token was over to the ENABLE project to investigate 
this a little further and report back.

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

I trust that the ENABLE folk will pick up these pointers.

> We are looking for comments from the shim6 WG on the MIPv6 analysis.

Right now we are in the process of working through the AD's initial 
comments leading to IESG review of the core documents.

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

Delivery-date: Mon, 22 Oct 2007 11:28:41 +0000
Date: Mon, 22 Oct 2007 13:26:59 +0200
From: Thierry Ernst <[email-masked]>
Organization: INRIA
To: Geoff Huston <[email-masked]>
CC:  [email-masked],  'Brian E Carpenter' <[email-masked]>, 'Jari Arkko' <[email-masked]>, 'shim6' <[email-masked]>
Subject: Re: shim6 control packets coming from unkown locators

This is a multi-part message in MIME format.
--------------030304030707050306090807
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

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:

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.

We are looking for comments from the shim6 WG on the MIPv6 analysis.

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

--------------030304030707050306090807
Content-Type: text/x-vcard; charset=utf-8;
 name="thierry.ernst.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="thierry.ernst.vcf"

begin:vcard
fn:Thierry Ernst
n:Ernst;Thierry
org:INRIA Rocquencourt;IMARA - LARA
adr:;;;;;;France
tel;work:+33 1 39 63 59 30
tel;fax:+33 1 39 63 54 91
url:http://www.lara.prd.fr
version:2.1
end:vcard

--------------030304030707050306090807--

Delivery-date: Sat, 20 Oct 2007 18:54:18 +0000
Cc: [email-masked], 'Jari Arkko' <[email-masked]>, 'shim6' <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: shim6 control packets coming from unkown locators
Date: Sat, 20 Oct 2007 20:53:02 +0200
To: Brian E Carpenter <[email-masked]>

El 19/10/2007, a las 0:02, Brian E Carpenter escribi=F3:

> On 2007-10-19 06:38, Alvaro Vives Martinez wrote:
> ...
>
>> Yes, in fact, actual work seems to go in that direction but =20
>> following this
>> path we reach an almost-MIPv6 solution. The SHIM6 only approach =20
>> had some
>> advantages over MIPv6 if it does not use the rendez-vous point. A =20
>> balance
>> among them seems to be the key.
>
> It seems to me that to accept control packets from unknown
> locators, we'd need a trust anchor of some kind - an entity
> that can provide a nonce to be included in such unexpected
> control packets, for example. That seems like a rendez-vous
> point, even if its only job is as a trust anchor.
>

i don't think that is strictly the only option

I mean you could send the UPDATE message from an unknown locator, but =20=

that the unknown locator is contained also in the locator list =20
contained in the LOCATOR message (as well as the CGA signature for =20
this new previously unknonw locator)

So, the receiving node would need to first verify the locator list =20
signature and if it is successfull, then accept the message, and if =20
not discard it.

regards, marcelo

>    Brian
>

Delivery-date: Sat, 20 Oct 2007 18:50:39 +0000
Cc: Brian E Carpenter <[email-masked]>, Jari Arkko <[email-masked]>, shim6 <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: shim6 control packets coming from unkown locators
Date: Sat, 20 Oct 2007 20:48:49 +0200
To: [email-masked]

El 18/10/2007, a las 19:38, Alvaro Vives Martinez escribi=F3:

>>
>> While Mobile-IP is outside of the scope of the SHIM6 WG (above =20
>> from the
>> "do no harm" level) here are some considerations.
>>
>> I think it is possible to use SHIM6 in a mobility context without
>> allowing update messages from unknown locators. My take is that any
>> complete IP mobility solution needs some form of rendez-vous =20
>> point, such
>> as a home agent or set of home agents. That is necessary in order to
>> allow initial contact and also to allow for simultaneous movement =20
>> of two
>> communicating peers. Once the MNs have such a fixpoint (or set of
>> fixpoints) then it is trivial to have the update messages be sent =20
>> with a
>> source locator that is already known to the peer; if all locators =20
>> have
>> changed at once there is still the home locator which the MN can =20
>> use by
>> tunneling the update message via its home agent(s).
>>
>> Have you considered such an approach in your work?
>
> Yes, in fact, actual work seems to go in that direction but =20
> following this
> path we reach an almost-MIPv6 solution. The SHIM6 only approach had =20=

> some
> advantages over MIPv6 if it does not use the rendez-vous point. A =20
> balance
> among them seems to be the key.
>

I guess that the point is that you cannot use  SHIM6 as a mobility =20
solution if you don't also use some form of anchor point (Home Agent =20
in MIP, RVS in HIP), since those are needed for simoultaneous =20
movement and for receiving incoming communications. So once you have =20
this anchor point, you can use it also to send the UPDATE messages. =20
The only difference would be that in case of a failure on the HA, =20
ongoing communication would fail, as oposed to the case where you can =20=

send the UPDATEs directly where the communication would survive.

So, the benefit achieved with supporting UPDATE mesages from unknown =20
locator would be this enhanced fault tolerance for this particular case.

(Of course, there may be other benefits as the ones pointed out by =20
Jari but in other scnarios not related to mobility)

Regards, marcelo

> Best regards,
> Alvaro Vives
> Consulintel
>
>
>
>>     Erik
>>
>>
>
>
>
>
> **********************************************
> The IPv6 Portal: http://www.ipv6tf.org
>
> Bye 6Bone. Hi, IPv6 !
> http://www.ipv6day.org
>
> This electronic message contains information which may be =20
> privileged or confidential. The information is intended to be for =20
> the use of the individual(s) named above. If you are not the =20
> intended recipient be aware that any disclosure, copying, =20
> distribution or use of the contents of this information, including =20
> attached files, is prohibited.
>
>
>
>

Delivery-date: Fri, 19 Oct 2007 07:38:48 +0000
From: "Alvaro Vives Martinez" <[email-masked]>
To: <[email-masked]>
Cc: "'Jari Arkko'" <[email-masked]>, "'shim6'" <[email-masked]>
Subject: RE: shim6 control packets coming from unkown locators
Date: Fri, 19 Oct 2007 09:36:47 +0200
Reply-To: [email-masked]

Hi Brian,

One of the requisites in the mobile context is that CGAs must be used
because HBA are based on the in-advance knowledge of all the address set of
the node. We have based our study on this.

IMHO the CGA stuff can then be used to verify a new locator. From Sec 7.2 of
the draft:

" There are two separate aspects of locator verification.  One is to
   verify that the locator is tied to the ULID, i.e., that the host
   which "owns" the ULID is also the one that is claiming the locator
   "ownership".  The Shim6 protocol uses the HBA or CGA techniques for
   doing this verification.  The other is to verify that the host is
   indeed reachable at the claimed locator...."

If the locator could be verified to be tied to an ULID, then this could be
matched against existing contexts ULIDs, with the help of a received context
tag.

The draft authors are for sure who can evaluate how the acceptance or not of
unknown locators could be done in a safe way.

Regards,
Alvaro Vives
Consulintel

> -----Mensaje original-----
> De: [email-masked] [mailto:[email-masked]] En nombre de Brian E
> Carpenter
> Enviado el: viernes, 19 de octubre de 2007 0:02
> Para: [email-masked]
> CC: 'Jari Arkko'; 'shim6'
> Asunto: Re: shim6 control packets coming from unkown locators
> 
> On 2007-10-19 06:38, Alvaro Vives Martinez wrote:
> ...
> 
> > Yes, in fact, actual work seems to go in that direction but following
> this
> > path we reach an almost-MIPv6 solution. The SHIM6 only approach had some
> > advantages over MIPv6 if it does not use the rendez-vous point. A
> balance
> > among them seems to be the key.
> 
> It seems to me that to accept control packets from unknown
> locators, we'd need a trust anchor of some kind - an entity
> that can provide a nonce to be included in such unexpected
> control packets, for example. That seems like a rendez-vous
> point, even if its only job is as a trust anchor.
> 
>     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.

Delivery-date: Thu, 18 Oct 2007 22:03:28 +0000
Date: Fri, 19 Oct 2007 11:02:16 +1300
From: Brian E Carpenter <[email-masked]>
Organization: University of Auckland
To:  [email-masked]
CC: 'Jari Arkko' <[email-masked]>, 'shim6' <[email-masked]>
Subject: Re: shim6 control packets coming from unkown locators

On 2007-10-19 06:38, Alvaro Vives Martinez wrote:
...

> Yes, in fact, actual work seems to go in that direction but following this
> path we reach an almost-MIPv6 solution. The SHIM6 only approach had some
> advantages over MIPv6 if it does not use the rendez-vous point. A balance
> among them seems to be the key.

It seems to me that to accept control packets from unknown
locators, we'd need a trust anchor of some kind - an entity
that can provide a nonce to be included in such unexpected
control packets, for example. That seems like a rendez-vous
point, even if its only job is as a trust anchor.

    Brian

Delivery-date: Thu, 18 Oct 2007 17:47:59 +0000
From: "Alvaro Vives Martinez" <[email-masked]>
To: <[email-masked]>, "'Geoff Huston'" <[email-masked]>
Cc: <[email-masked]>, "'Brian E Carpenter'" <[email-masked]>, "'Jari Arkko'" <[email-masked]>, "'shim6'" <[email-masked]>
Subject: RE: shim6 control packets coming from unkown locators
Date: Thu, 18 Oct 2007 19:47:29 +0200
Reply-To: [email-masked]

Hi Marcelo,

Thanks for the clarification.

My intention was just to say that if this possibility is added to the
protocol, one of the drawbacks of SHIM6 as a mobility solution would
disappear. The specific control message involved in the detected problems
was UPDATE REQUEST.

Of course, I do not want to push for a SHIM6 revision to be able to use it
for mobility. Despite Geoff's words it seems that it is too late. Anyhow
ENABLE project will produce some deliverables containing the analysis
carried out. But this is a little off topic I guess...

Best regards,
Alvaro Vives
Consulintel

> -----Mensaje original-----
> De: marcelo bagnulo braun [mailto:[email-masked]]
> Enviado el: jueves, 18 de octubre de 2007 17:56
> Para: Geoff Huston
> CC: [email-masked]; [email-masked]; 'Brian E Carpenter';
> 'Jari Arkko'; 'shim6'
> Asunto: Re: shim6 control packets coming from unkown locators
>=20
> FWIW, Jari's review brought this issue from a different perspective,
> basically, he asked whether a shim6 node would accept probe packets
> from unknown locators, so a given node deosn't have to inform the
> peer about all its locators, and still use them in case of a failure.
>=20
> regards, marcelo
>=20
>=20
>=20
> El 17/10/2007, a las 13:40, Geoff Huston escribi=F3:
>=20
> > Alvaro,
> >
> > 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, 18 Oct 2007 17:39:15 +0000
From: "Alvaro Vives Martinez" <[email-masked]>
To: <[email-masked]>
Cc: "'Brian E Carpenter'" <[email-masked]>, "'Jari Arkko'" <[email-masked]>, "'shim6'" <[email-masked]>
Subject: RE: shim6 control packets coming from unkown locators
Date: Thu, 18 Oct 2007 19:38:50 +0200
Reply-To: [email-masked]

Hi Erik,

<snip>
> > 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.
> 
> While Mobile-IP is outside of the scope of the SHIM6 WG (above from the
> "do no harm" level) here are some considerations.
> 
> I think it is possible to use SHIM6 in a mobility context without
> allowing update messages from unknown locators. My take is that any
> complete IP mobility solution needs some form of rendez-vous point, such
> as a home agent or set of home agents. That is necessary in order to
> allow initial contact and also to allow for simultaneous movement of two
> communicating peers. Once the MNs have such a fixpoint (or set of
> fixpoints) then it is trivial to have the update messages be sent with a
> source locator that is already known to the peer; if all locators have
> changed at once there is still the home locator which the MN can use by
> tunneling the update message via its home agent(s).
> 
> Have you considered such an approach in your work?

Yes, in fact, actual work seems to go in that direction but following this
path we reach an almost-MIPv6 solution. The SHIM6 only approach had some
advantages over MIPv6 if it does not use the rendez-vous point. A balance
among them seems to be the key.

Best regards,
Alvaro Vives
Consulintel

 
>     Erik
> 
> 

**********************************************
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, 18 Oct 2007 17:34:51 +0000
From: "Alvaro Vives Martinez" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, "'Brian E Carpenter'" <[email-masked]>, "'Jari Arkko'" <[email-masked]>, "'shim6'" <[email-masked]>
Subject: RE: shim6 control packets coming from unkown locators
Date: Thu, 18 Oct 2007 19:32:47 +0200
Reply-To: [email-masked]

Hi Geoff,

Thanks for the prompt response.

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

Cristal clear.

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

I understand this and I was not sure to send a mail about this issue but I
understood that from AD's comments and Marcelo's response that some points
were "open", at least among them, am I right? One of these points is the one
related with control packets coming from unknown locators.

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

It was not my intention to propose changes to the protocol. Just expressed
my opinion/support, based on the work carried out within one project, about
what I considered a possible change suggested by the AD revision of the
draft. If I am not wrong this would be a change on the packet processing
rather than on the message format.

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

This would be a possibility and I have to transmit your words to the project
to know what they think about this.

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

I understand this and this could be a problem, added to the fact that the
project is ending beginning next year.

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

>From the web site main page, third paragraph of the objectives:
"...Moreover, the promising but not yet fully understood mobility management
alternatives (e.g., Host Identity Protocol) will be assessed, with the
objective to identify possible strategies for their smooth deployment
starting from an architecture based on Mobile IPv6."

That is, some alternatives to MIPv6 were considered and evaluated and SHIM6
was chosen for further study. The unknown locator issue was one of the
problems identified if SHIM6 is used for mobility, and I just wanted to
inform the SHIM6 community of this point because of what seemed to me an
"slightly open door". There were some advantages also in using SHIM6 as a
mobility solution.

Best regards,
Alvaro Vives
Consulintel

=20
>=20
> regards,
>=20
>    Geoff
>=20
>=20
> 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, 18 Oct 2007 15:56:31 +0000
Cc: [email-masked], [email-masked], 'Brian E Carpenter' <[email-masked]>, 'Jari Arkko' <[email-masked]>, 'shim6' <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: shim6 control packets coming from unkown locators
Date: Thu, 18 Oct 2007 17:56:03 +0200
To: Geoff Huston <[email-masked]>

FWIW, Jari's review brought this issue from a different perspective, =20
basically, he asked whether a shim6 node would accept probe packets =20
from unknown locators, so a given node deosn't have to inform the =20
peer about all its locators, and still use them in case of a failure.

regards, marcelo

El 17/10/2007, a las 13:40, Geoff Huston escribi=F3:

> Alvaro,
>
> There was a pretty long-standing design objective in shim6 that it =20
> did no deliberate harm to mobility solutions (and indeed did no =20
> deliberate harm to IPv6 at all of course!), but equally that it did =20=

> not attempt to position itself as an alternative approach to =20
> mobility to mobileipv6 and that shim6's objective was the =20
> multihoming case where the agility across addresses was across =20
> space rather than across time - i.e. the alternative potential =20
> addresses were simultaneously available and explorable rather than =20
> sequentially available and potentially singly explorable.
>
> Right now the core specification of SHIM6 has passed working group =20
> last call and the document editors are resolving comments from the =20
> area director prior to submitting this as a proposed standard to =20
> the IESG for publication.
>
> So right now this possibility of making changes to the UPDATE =20
> REQUEST message is not readily "open" at this point in time in =20
> terms of adding this into the working group's agenda of study for =20
> this activity as a procedural matter.
>
> However the invocation of procedure should not necessarily preclude =20=

> consideration of good ideas and if the ENABLE project is willing to =20=

> undertake further analysis of the issue to figure out the full =20
> extent of changes to shim6 for their intended application to =20
> mobility, and come to a conclusion that a particular set of changes =20=

> would be necessary and sufficient for their use in this context, =20
> and that such changes would completely benign for the intended =20
> shim6 multihoming case from the perspective of performance and =20
> security, then I suspect that the case to adopt such a change to =20
> shim6 would be stronger. So I would encourage the ENABLE project to =20=

> undertake more investigation of this and provide a report to the =20
> shim6 working group when such a study is complete.
>
> On the other hand you need to be aware that the documents are well =20
> advanced along the track now, so time is an important consideration =20=

> 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 =20
> from the ENABLE site "ENABLE will concentrate on the following main =20=

> areas of work: Enhancement of Mobile IPv6...Enrichment of the basic =20=

> mobility service provided by Mobile IPv6 ..This activity will =20
> investigate scalability and performance issues that Mobile IPv6 =20
> might raise " Given that shim6 is not mobileipv6 and shim6 really =20
> has not been designed to operate efficiently within the timing =20
> constraints that we conventionally believe to be associated with =20
> mobility then it is not altogether obvious that further refinement =20
> of shim6 would necessarily produce a solution that was superior to =20
> mobileipv6 in any case.
>
>
> regards,
>
>   Geoff
>
>
> Alvaro Vives Martinez wrote:
>> Hi Marcelo,
>> Within the ENABLE project (www.ist-enable.org) SHIM6 has been =20
>> evaluated as a
>> possible mobility solution. The fact that UPDATE REQUEST message =20
>> that comes
>> from an unknown locator is not accepted was a problem in this =20
>> context.
>> So, if this possibility is still open I would like to push for it, =20=

>> at least
>> for the UPDATE REQUEST message and if no security risks are =20
>> introduced, of
>> course.
>> This would open the field for SHIM6 as a mobility solution, there =20
>> are other
>> missing pieces being evaluated as well, because of its LOC/ID =20
>> 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 =20=

>>> 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 =20
>>>> security
>>>> hole that would be quite painful to close.
>>>>
>>> agree that security issues should be addressed carefully, but i =20
>>> 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 =20
>>> 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 =20
>> privileged or confidential. The information is intended to be for =20
>> the use of the individual(s) named above. If you are not the =20
>> intended recipient be aware that any disclosure, copying, =20
>> distribution or use of the contents of this information, including =20=

>> attached files, is prohibited.
>

Delivery-date: Thu, 18 Oct 2007 15:48:42 +0000
Date: Thu, 18 Oct 2007 08:46:55 -0700
From: Erik Nordmark <[email-masked]>
To: [email-masked]
CC: [email-masked], "'Brian E Carpenter'" <[email-masked]>, "'Jari Arkko'" <[email-masked]>, "'shim6'" <[email-masked]>
Subject: Re: shim6 control packets coming from unkown locators

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.

While Mobile-IP is outside of the scope of the SHIM6 WG (above from the 
"do no harm" level) here are some considerations.

I think it is possible to use SHIM6 in a mobility context without 
allowing update messages from unknown locators. My take is that any 
complete IP mobility solution needs some form of rendez-vous point, such 
as a home agent or set of home agents. That is necessary in order to 
allow initial contact and also to allow for simultaneous movement of two 
communicating peers. Once the MNs have such a fixpoint (or set of 
fixpoints) then it is trivial to have the update messages be sent with a 
source locator that is already known to the peer; if all locators have 
changed at once there is still the home locator which the MN can use by 
tunneling the update message via its home agent(s).

Have you considered such an approach in your work?

    Erik

Delivery-date: Wed, 17 Oct 2007 11:39:14 +0000
Date: Wed, 17 Oct 2007 21:40:25 +1000
From: Geoff Huston <[email-masked]>
To: [email-masked]
Cc: [email-masked], 'Brian E Carpenter' <[email-masked]>, 'Jari Arkko' <[email-masked]>, 'shim6' <[email-masked]>
Subject: Re: shim6 control packets coming from unkown locators

Alvaro,

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

Delivery-date: Wed, 17 Oct 2007 08:42:18 +0000
From: "Alvaro Vives Martinez" <[email-masked]>
To: <[email-masked]>, "'Brian E Carpenter'" <[email-masked]>
Cc: "'Jari Arkko'" <[email-masked]>, "'shim6'" <[email-masked]>
Subject: RE: shim6 control packets coming from unkown locators
Date: Wed, 17 Oct 2007 10:39:47 +0200
Reply-To: [email-masked]

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
>=20
> Hi Brian,
>=20
>=20
> El 27/09/2007, a las 21:51, Brian E Carpenter escribi=F3:
>=20
> > 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.
> >
>=20
> 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.
>=20
> Regards, marcelo
>=20
>=20
> >    Brian
>=20

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