[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: shim6 control packets coming from unkown locators
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:gih@apnic.net]
> Enviado el: lunes, 22 de octubre de 2007 14:26
> Para: Thierry Ernst
> CC: alvaro.vives@consulintel.es; 'Brian E Carpenter'; 'Jari Arkko';
> 'shim6'
> Asunto: Re: shim6 control packets coming from unkown locators
>
>
>
> 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: 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.