Subject: Re: [Mipshop] [Fwd: Re: Comments draft-ietf-mipshop-fh80216e-06]

From: Heejin Jang <[email-masked]>
Date: Wed, 27 Feb 2008 07:02:46 +0000 (GMT)

Hi, Michael

I appreciate your kind review. 
Some of your comments are the same as what we've received 
from other reviewers and currently we're working on it.

kindly see below.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> [email-masked]
> Sent: Wednesday, February 27, 2008 11:27 AM
> To: [email-masked]; [email-masked]
> Subject: Re: [Mipshop] [Fwd: Re: Comments 
> draft-ietf-mipshop-fh80216e-06]
> 
> Hi Vijay, Heejin,
> 
> Regarding the removal of references to 802.21 due that being too SDO
> specific, .21 is developed by the IEEE 802 LMSC just as .16e is. It is
> the same SDO, so  the reference to .16e and .21 stand on 
> equal footing. 

802.16e needs to be located in the normative reference because its
handover procedures should be fully understood for the new document. 
Please see the below RFC3967.

On the other hand, We're planning to remove a 802.21 dependency in the 
text body and introduce a 802.21 primitives as an example only in the appendix 
section. So I think that it is reasonable to put it in the informative reference as 
suggested by Vijay. 

In RFC 3967, 

   "Within an RFC, references to other documents fall into two general
   categories: "normative" and "informative".  Broadly speaking, a
   normative reference specifies a document that must be read to fully
   understand or implement the subject matter in the new RFC, or whose
   contents are effectively part of the new RFC, as its omission would
   leave the new RFC incompletely specified." 

> In Section 4, the MN is described as using native .16 L2 mechanisms for
> network topology discovery. Although not specifically designed to
> facilitate intra .16 handover, 802.21 also provides a service that can
> provide the topology. The service (information service query)  is a MN
> 'pull', so is not subject to the particular DoS attack mentioned in
> other reviews.

Ok. However, since we decided to provide the 802.21 as an example, we 
cannot relay on the security mechanism provided by the 802.21-spec or 
MIHF documents (in mipshop). Furthermore, to my knowledge, the 802.21
does not define any security mechanism and just rely on the L2 security
or L3 one in use. Anyway we'll see those documents as a reference during 
revising security consideration section.

> In Section 5, the adjective 'close'is used in reference to the use of
> 802.21, FMIPv6 and 802.16e. Since both 802.21 and FMIPv6 provide link
> independent interfaces and services, this characterization can give the
> wrong impression. In general MIP acceleration techniques and .21
> services have at times been mis-labeled as 'close' when they achieve the
> performance gains while providing standardized link independent
> interfaces and services.

Ok. For clarity, we'll revise the text as below.

In Section 5.

Old:

   In this section, we describe the desirable FMIPv6 handover procedure
   in 802.16 networks.  We introduce four primitives proposed by
   [802.21] for the close interaction between FMIPv6 and 802.16e, and
   present the detailed interaction procedure.

New:

   In this section, we describe the desirable FMIPv6 handover procedures
   in 802.16 networks.  We introduce four primitives for the efficient interleaving
   of FMIPv6 and 802.16e handover procedures, and present the detailed 
   handover procedures by using them.  
 
> In Section 5.1, a review was concerned about the possibility of an
> attacker triggering a flood of link detected events from the 802.21
> implementation. This kind of attack will cause the MN to 
> indicated some kind of signal upward from the L2 implementation if the MN is 
> listening for these .16 messages. When .21 is being used, the link event is
> 'consumed' or 'interpreted' and presented upward in a media 
> independent fashion. It is possible (probably typical) for a .21 implementation to
> have information that could help mitigate this attack. In suchi
> mplementations, the MIHF would receive the link event from 
> the .16e L2, but deliver selected events upwards to FMIPv6.

Right. This was also commented by the previous reviewers.
We're working on the revision of security consideration section now, 
and the security vulnerability you pointed out will be mentioned.

> In Section 5.2, the scenario does not include network 
> initiated HO as a possibility. Is it within the possible use cases to discuss 
> such an option?

This document also mentions about the netowrk-initiated HO as below.

In the 3rd paragraph of Section 3:

 "The handover preparation can be initiated by either the MN or the BS....
  The BS then replies with a MOB_BSHO-RSP containing the recommended 
   BSs to the MN after negotiating with candidates.  Optionally it may confirm 
   handover to the target BS over backbone when the target is decided. 
   The BS alternatively may trigger handover with a MOB_BSHO-REQ message."

In Section 5.2

"  When the MN decides to change links based on its policy such as the
   degrading signal strength or increasing packet loss rate, it
   initiates handover by sending a MOB_MSHO-REQ to the BS and receives a
   MOB_BSHO-RSP from the BS as a response.  Alternatively the BS may
   initiate handover by sending a  to the MN."

And it (MOB_BSHO-REQ) is also illustrated in the Figure 3 and 4.
But, in my understanding, there is no difference in the proposed mechanism
whether the HO is triggered by the BS or MN. If there is any, kindly let me know.

> 
> Thanks for taking on this work. We really need these solutions to be
> clear.

> Best Regards,
> Michael

Thanks again. 

- Best regards, 
Heejin Jang

> 
> 
> >-----Original Message-----
> >From: [email-masked] 
> >[mailto:[email-masked]] On Behalf Of ext Vijay Devarapalli
> >Sent: 26 February, 2008 16:36
> >To: 'Mipshop'
> >Subject: [Mipshop] [Fwd: Re: Comments draft-ietf-mipshop-fh80216e-06]
> >
> >FYI.
> >
> >I forwarded a bunch of comments that we got as a result of the 
> >IETF last call on draft-ietf-mipshop-fh80216e-06. Heejin has 
> >been addressing those comments and revising the draft. If 
> >anyone has comments on the changes being made, now would be a 
> >good time to speak up.
> >
> >Vijay
> >
> _______________________________________________
> Mipshop mailing list
> [email-masked]
> http://www.ietf.org/mailman/listinfo/mipshop
_______________________________________________
Mipshop mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mipshop

---

From: <[email-masked]>
Date: Wed, 27 Feb 2008 02:50:14 -0600

Hei  Heejin,

Just quick clarification on  the points below...
>From: ext Heejin Jang [mailto:[email-masked]] 
>Sent: 26 February, 2008 23:03
>To: Williams Michael.G (Nokia-OCTO/Dallas)
>Cc: [email-masked]; [email-masked]; 
>[email-masked]; 
>[email-masked]; [email-masked]
>Subject: Re: Re: [Mipshop] [Fwd: Re: Comments 
>Some of your comments are the same as what we've received from 
>other reviewers and currently we're working on it.
>
>kindly see below.
>
>> Regarding the removal of references to 802.21 due to them being too
SDO 
>> the same SDO, so  the reference to .16e and .21 stand on equal 
>> footing.
>
>802.16e needs to be located in the normative reference because 
>its handover procedures should be fully understood for the new 
>document. 
>On the other hand, We're planning to remove a 802.21 
>dependency in the text body and introduce a 802.21 primitives 
>as an example only in the appendix section. So I think that it 
>is reasonable to put it in the informative reference as 
>suggested by Vijay. 
>
>In RFC 3967, 
>

It seems a bit of a step backwards, away from the original conception of
the work, to remove normative references to .21. Many of the
presentations in MIPSHOP have illustrated use of MIP with .21. It was a
major impetus of .21 to add features to the L2 to satisfy the needs of
facilitating network layer mobility. Would it be possible to retain
normative reference to .21, perhaps following some path used in previous
successful joint projects that were documented in RFC 4441?

>> In Section 4, the MN is described as using native .16 L2 mechanisms 
>> for network topology discovery. Although not specifically 
>designed to 
>Ok. However, since we decided to provide the 802.21 as an 
>example, we cannot relay on the security mechanism provided by 
>the 802.21-spec or MIHF documents (in mipshop). Furthermore, 
>to my knowledge, the 802.21 does not define any security 
>mechanism and just rely on the L2 security or L3 one in use. 
>Anyway we'll see those documents as a reference during 

You are correct. The use of the MIH IS to pull information on the
topology is not a security mechanism. However, using this approach
happens to mitigate the threat from listening to spoofed L2 broadcasts
from an attacker. The use of an MIH IS query could be listed as a third
possibility to get the topology, in addition to the two cases presented
in the current draft.

>> independent interfaces and services, this characterization can give 
>> the wrong impression. In general MIP acceleration techniques and .21 
>> services have at times been mis-labeled as 'close' when they achieve 
>> the performance gains while providing standardized link independent 
>> interfaces and services.
>

Great. In addition, keeping the reference to .21 would  be better.

>> implementation. This kind of attack will cause the MN to indicated 
>> some kind of signal upward from the L2 implementation if the MN is 
>> listening for these .16 messages. When .21 is being used, the link 
>> event is 'consumed' or 'interpreted' and presented upward in a media 
>> independent fashion. It is possible (probably typical) for a .21 
>> implementation to have information that could help mitigate this 
>> attack. In suchi mplementations, the MIHF would receive the 
>link event 
>> from the .16e L2, but deliver selected events upwards to FMIPv6.
>
>We're working on the revision of security consideration 
>section now, and the security vulnerability you pointed out 
>will be mentioned.
>

Ok. If text were added discussing the .21 MIH function, then there could
be a suggested mitigation as well.

>initiated HO as 
>> a possibility. Is it within the possible use cases to 
>discuss such an 
>> option?
>
>But, in my understanding, there is no difference in the 
>proposed mechanism whether the HO is triggered by the BS or 
>MN. If there is any, kindly let me know.

Thanks for pointing out those points. It might be more clear to have a
separate section or paragraph separating the network initiated case. As
it is above, the topic is 'When the MN decides to change links'...

The initiation of HO by the network might begin with the native .16
triggers as is described, or by using a .21 media independent mechanism.
HO initiation using the .21 trigger mechanisms may provide some
additional features. If desired such an example could be included.

Thanks for considering these comments.

BR,
Michael

>> >I forwarded a bunch of comments that we got as a result of the IETF 
>> >last call on draft-ietf-mipshop-fh80216e-06. Heejin has been 
>> >addressing those comments and revising the draft. If anyone has 
>> >comments on the changes being made, now would be a good 
>time to speak 
>> >up.
>> >
>> >Vijay
>> >

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 29 Feb 2008 15:21:38 -0800

> successful joint projects that were documented in RFC 4441?

I wanted to comment on this particular topic.

The intention is to not require 802.21 to be implemented for
someone to be able to use FMIPv6 over 802.16e access networks.
So we are just modifying the text to reflect this.

The document will still describe how to use FMIPv6 over
802.16e using 802.21 primitives.

Vijay

---

From: "Rajeev Koodli" <[email-masked]>
Date: Fri, 29 Feb 2008 19:53:46 -0800

> 802.16e using 802.21 primitives.

Right. It's been the thinking all along that FH-802.16e should be able to
run without requiring 802.21, but be able to use it when available.

-Rajeev