Subject: [Mipshop] [Fwd: DISCUSS and COMMENT: draft-ietf-mipshop-fh80216e]

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 26 Feb 2008 16:32:15 -0800

FYI

Subject: DISCUSS and COMMENT: draft-ietf-mipshop-fh80216e
From: Tim Polk <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Date: Thu, 21 Feb 2008 07:28:42 -0800 (PST)

Discuss:
The optimizations described in this document are rather nice, and I support
publication of this document.  There are a couple of issues that need to be
addressed first, though.

1. The link layer (IEEE 802.16e) utilizes the IEEE 802.21
primitives to trigger the FMIPv6. In other words, IEEE 802.21
is used for inter-layer communications (L2<->L3).

The following questions arise:
a) IEEE 802.21 is still a draft, what happens if the utilized
primitives are modified or removed in the final standard? Are
other triggers possible for IEEE 802.16?  It seems advantageous
to provide a general solution and use IEEE 802.21 as example.

b) RFC 4260 provides a solution for IEEE 802.11 fast HO without
such triggers. Since IEEE 802.21 is media-independent couldn’t the
same primitives used as trigger in IEEE 802.11 networks (RFC 4260)? 

2. The security considerations in Section 7 are incomplete and
contain some incorrect statements. 

First of all, the referenced security considerations cover only
the security of FMIPv6 messages. This follows that a security
discussion for IEEE 802.16e and utilized IEEE 802.21 messages is
required.  Furthermore, interleaving these messages may create
new vulnerabilities and thus the proposed message flow should be
analyzed in its entirety.

The consideration of IEEE 802.16 messages is incomplete, and the
messages that need to be protected and the kind of required
protection are not explicitly mentioned. In addition, I believe 
the statement that EAP or EAP-TTLS, EAP-SIM and EAP-AKA are mandatory
authentication mechanisms in IEEE 802.16 is incorrect. IEEE 802.16e
supports two authentication mechanisms, namely RSA with X.509
certificates and EAP. No mandatory EAP methods are specified, just
guidelines they must meet as specified in RFC 4017.

No consideration of the utilized IEEE 802.21 primitives is provided.
In the current IEE 802.21 draft, such inter-layer event messages are
not protected and it could be argued that inter layer messages within
a MN do not require protection. However, that should be mentioned.

Comment:
Section 1
2nd paragraph
- Should mention that RFC 4260 provides a fast HO solution for IEEE
802.11 networks.
- Provide reference for IEEE 802.16.

Section 5
Several acronyms from FMIPv6 are used without any introduction, e.g.
AR, PAR, FBU, NAR, etc.

Section 6
-again many acronyms/message are used without any introduction, e.g.
UNA, HI, HACK, etc and others used in the figures
-change “..belongs to the different subnet” to “..belongs to a
different subnet”

Subsection 6.1
-no reference to Figure 3
-for clarification maybe add that msg between L3 and L2 are IEEE
802.21, msg between MN L2 and the BS are IEEE 802.16, and msg
between MN L2 and the AR are FMIPv6.

Subsection 6.2
-no reference to Figure 4

Section 7
-reference EAP [RFC 3748] and other protection mechanism after
updating section (see technical comments)

Subject: Re: DISCUSS and COMMENT: draft-ietf-mipshop-fh80216e
From: Heejin Jang <[email-masked]>
To: Tim Polk <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, [email-masked]
Date: Mon, 25 Feb 2008 06:02:15 +0000 (GMT)

Hi, Tim

I appreciate your valuable comments.
Some comments need to be considered together with comments
received from other folks, and I'll send the revised results in a
separate mail after revision soon.

Kindly see my inline reply.

> -----Original Message-----
> From: Tim Polk [mailto:[email-masked]] 
> Sent: Friday, February 22, 2008 12:29 AM
> To: [email-masked]
> Cc: [email-masked]; 
> [email-masked]
> Subject: DISCUSS and COMMENT: draft-ietf-mipshop-fh80216e
> 
> Discuss:
> The optimizations described in this document are rather nice, 
> and I support publication of this document.  There are a 
> couple of issues that need to be addressed first, though.
> 
> 1. The link layer (IEEE 802.16e) utilizes the IEEE 802.21 
> primitives to trigger the FMIPv6. In other words, IEEE 802.21 
> is used for inter-layer communications (L2<->L3).
> The following questions arise:
> a) IEEE 802.21 is still a draft, what happens if the utilized 
> primitives are modified or removed in the final standard? Are 
> other triggers possible for IEEE 802.16?  It seems 
> advantageous to provide a general solution and use IEEE 
> 802.21 as example.
> 
> b) RFC 4260 provides a solution for IEEE 802.11 fast HO 
> without such triggers. Since IEEE 802.21 is media-independent 
> couldnt the same primitives used as trigger in IEEE 802.11 
> networks (RFC 4260)? 

This is a good comment.  The 802.21 is for Vertical handover while 
our solution is for Horizental handover. Furthurmore, the document is 
on-going and subject to change. So we are planning to update the 
document so that it can utilize the general abstraction primitives 
(not specific 802.21 message), or mention the interleaving procedures 
without giving specific L2 primitives such as RFC4260, rather than 
depending on IEEE 802.21. 
 
> 2. The security considerations in Section 7 are incomplete 
> and contain some incorrect statements. 
> 
> First of all, the referenced security considerations cover 
> only the security of FMIPv6 messages. This follows that a 
> security discussion for IEEE 802.16e and utilized IEEE 802.21 
> messages is required.  Furthermore, interleaving these 
> messages may create new vulnerabilities and thus the proposed 
> message flow should be analyzed in its entirety.

We got the same comments from Tom yu, and it seems that
the security section needs some major re-work.
 
> The consideration of IEEE 802.16 messages is incomplete, and 
> the messages that need to be protected and the kind of 
> required protection are not explicitly mentioned. In 
> addition, I believe the statement that EAP or EAP-TTLS, 
> EAP-SIM and EAP-AKA are mandatory authentication mechanisms 
> in IEEE 802.16 is incorrect. IEEE 802.16e supports two 
> authentication mechanisms, namely RSA with X.509 certificates 
> and EAP. No mandatory EAP methods are specified, just 
> guidelines they must meet as specified in RFC 4017.

Ok. 

> No consideration of the utilized IEEE 802.21 primitives is provided.
> In the current IEE 802.21 draft, such inter-layer event 
> messages are not protected and it could be argued that inter 
> layer messages within a MN do not require protection. 
> However, that should be mentioned.

As you mentioned, such inter-layer primitives does not need to 
be protected but 802.16e messages which may trigger the inter-layer
primitives needs to be protected. We'll describe this point clearly 
during the revision of secrity consideration.
> 
> Comment:
> Section 1
> 2nd paragraph
> - Should mention that RFC 4260 provides a fast HO solution for IEEE
> 802.11 networks.

Ok. We'll add a descrition of RFC 4260 for a brief summay.

> - Provide reference for IEEE 802.16.

Ok.

> Section 5
> Several acronyms from FMIPv6 are used without any introduction, e.g.
> AR, PAR, FBU, NAR, etc.

Ok. We'll give a full description for the FMIPv6 network messages and 
the network entities.

> 
> Section 6
> -again many acronyms/message are used without any introduction, e.g.
> UNA, HI, HACK, etc and others used in the figures 

Answered previously.

-change 
> ..belongs to the different subnet to ..belongs to a different subnet

Ok.

> Subsection 6.1
> -no reference to Figure 3

Ok. We'll give a reference for the figures.

> -for clarification maybe add that msg between L3 and L2 are 
> IEEE 802.21, msg between MN L2 and the BS are IEEE 802.16, 
> and msg between MN L2 and the AR are FMIPv6.

Ok. This will be reflected in Section 6.

> Subsection 6.2
> -no reference to Figure 4

Answered previously.

> Section 7
> -reference EAP [RFC 3748] and other protection mechanism 
> after updating section (see technical comments)

Ok. 

_______________________________________________
Mipshop mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/mipshop