[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: shim6 control packets coming from unkown locators
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:marcelo@it.uc3m.es]
> Enviado el: jueves, 18 de octubre de 2007 17:56
> Para: Geoff Huston
> CC: alvaro.vives@consulintel.es; owner-shim6@psg.com; 'Brian E Carpenter';
> 'Jari Arkko'; 'shim6'
> Asunto: Re: shim6 control packets coming from unkown locators
>
> 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.
>
> regards, marcelo
>
>
>
> El 17/10/2007, a las 13:40, Geoff Huston escribió:
>
> > 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: 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.