[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: shim6 control packets coming from unkown locators

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

 
> 
> 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: owner-shim6@psg.com [mailto:owner-shim6@psg.com] 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.
> >
> >
> >



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