[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: shim6 control packets coming from unkown locators
Hi,
Thanks for the pointers. I have passed them to my colleagues in ENABLE.
Best regards,
Alvaro
> -----Mensaje original-----
> De: Thierry Ernst [mailto:thierry.ernst@inria.fr]
> Enviado el: lunes, 22 de octubre de 2007 13:27
> Para: Geoff Huston
> CC: alvaro.vives@consulintel.es; 'Brian E Carpenter'; 'Jari Arkko';
> 'shim6'
> Asunto: Re: shim6 control packets coming from unkown locators
>
>
> 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: 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.