Subject: [Mipshop] [Fwd: Re: secdir review of draft-ietf-mipshop-fh80216e-06]

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

FYI

Subject: Re: secdir review of draft-ietf-mipshop-fh80216e-06
From: "Heejin Jang" <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Date: Sat, 23 Feb 2008 14:38:38 +0900

Hi, Tom.

I appreciate your valuable comments.
Some comments need to be considered together with other 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 -------
> Sender : Tom Yu<[email-masked]>
> Date : 2008-02-20 16:30 (GMT+09:00)
> Title : secdir review of draft-ietf-mipshop-fh80216e-06
>
> I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the
> IESG.  These comments were written primarily for the benefit of the
> security area directors.  Document editors and WG chairs should treat
> these comments just like any other last call comments.
>
> I am not very familiar with IEEE 802.16, which appears to be a focus
> of this document.  This document normatively references IEEE
> 802.16e-2005, which is a 864-page document that I did not have time to
> read in its entirety.  IEEE 802.16e-2005 is in the form of an
> amendment (and thus requires reading the amended document for context)
> to IEEE 802.16-2004, which is itself nearly 900 pages long.  Also, I
> lack access to the IEEE 802.21 draft, so some of my comments may be
> already addressed by the content of that document.  (See also my later
> comment on informative vs normative reference to 802.21.)

> It appears that this I-D proposes a method for using the primitives in
> (as yet unapproved draft) IEEE 802.21 to provide seamless handovers by
> means of tight L2-L3 handover integration.  This should be made more
> clear in the abstract, which currently makes no mention of IEEE
> 802.21.

We got comments that this document should not rely on the IEEE 802.21
which is too specific to some SDO. So we are planning to update the
document so that it can utilize the L2 abstraction messages (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. So, we'll revise the abstract as below.

Old:
  This document describes how a Mobile IPv6 Fast Handover can be
  implemented on link layers conforming to the 802.16e suite of
  specifications.

New:
  This document describes how a Mobile IPv6 Fast Handover can be
  implemented on link layers conforming to the 802.16e suite of
  specifications. To provide the seamless handover, this proposal tries to
  maximize the benefits of synchronizing the link layer handover with
the fast IP
  handover procedure by exploiting the link-layer handover indicators.

> SECURITY:
>
> The complete text of the Security Considerations section is:
>
>    The security consideration of the FMIPv6 specification
>    [I-D.ietf-mipshop-fmipv6-rfc4068bis] is applicable to this document.
>    Particularly, the 802.16e architecture supports a number of mandatory
>    authentication mechanisms, for example, EAP-TTLS, EAP-SIM and EAP-AKA
>    and that will allow secure handover operation of the MN.
>
> The second sentence appears to be a non sequitur, because
> fmipv6-rfc4068bis makes no mention of IEEE 802.16e.  Is the intended
> meaning closer to the following?
>
>    The security considerations of the FMIPv6 specification [...] are
>    applicable to this document.  The FMIPv6 specification requires
>    that certain messages be secured in order to avoid security
>    vulnerabilities.  The 802.16e architecture supports a number of
>    mandatory authentication mechanisms [...] that can secure these
>    FMIPv6 messages.

Ok. The texts suggested by you more clear.
We'll reflect this during the revision.

> To facilitate security analysis, it would be useful to make explicit
> whether a 802.21 primitive is triggered by an unauthenticated or an
> authenticated message.  In Section 5, the descriptions of the 802.21
> primitives implies that these primitives are intended to be abstract
> interfaces internal to an implementation.  While this means that the
> internal abstract messages constituting these primitives do not
> require authentication, the protocol messages triggering these
> abstract messages may require authentication.

> For example, in a mobile station, the Link_Detected (LD) 802.21
> indication is triggered by the 802.16 link layer when it receives a
> MOB_NBR-ADV message from a base station.  My reading of 802.16e
> reveals no evidence that the MOB_NBR-ADV message is authenticated.
> The existing text in this I-D does not explicitly mention that
> MOB_NBR-ADV is unauthenticated.  While someone familiar with 802.16e
> may already know this, explicitly indicating which 802.16e messages
> are authenticated would make it easier to analyze the proposal in this
> I-D.
>
> In the case of the Link_Detected (LD) primitive, an unauthenticated
> MOB_NBR-ADV message can cause a LD indication triggering AR discovery
> through (presumably) authenticated messages with the PAR.  Is this a
> possible denial of service where an unauthenticated attacker can send
> a flood of bogus MOB_NBR-ADV messages purporting to be from different
> base stations, causing the receiving mobile station to consume
> excessive resources handling the LD indications?  (I could believe
> that I have missed text in 802.16e or 802.21 requiring some rate
> limiting in the mobile station in response to a flood of MOB_NBR-ADV
> messages.)

Ok. We'll mention in Security consideration section that which
primitives may be triggered by authenticated messages or
unauthenticated messages in 802.16e, and describe the vulnerability to
the unauthenticated messages sent from a rogue entity.

> Section 5.1 implies that this denial of service attack is unlikely,
> asserting that the resulting RtSolPr messages sent by the mobile
> station are unlikely to cause signaling overheads described in Section
> 2 of RFC 4907, but offers no justification for this assertion.

I'm not sure I got your point exactly. If my understanding is right,
this comment resulted from our confusing description. We revised the
text as below for clarity.

Old:
  It is unlikely that RtSolPr messages may cause signaling overheads
  mentioned in Section 2 of [RFC4907].  The MN may detect more than one
  BSs and issue the Link_Detected primitives but not all at once.
  Furthermore, retransmission of RtSolPr messages are rate-limited by
  exponential backoff in [I-D.ietf-mipshop-fmipv6-rfc4068bis].

New:
  It is unlikely that RtSolPr messages may cause signaling overheads
  mentioned in Section 2 of [RFC4907] because retransmission of RtSolPr
  messages is rate-limited by the exponential backoff as described
  in Section 6.1 of [I-D.ietf-mipshop-fmipv6-rfc4068bis].

> Perhaps I am missing some background information here.  Section 5.1
> also states "The MN may detect more than one BSs and issue the
> Link_Detected primitives but not all at once.", but it's not clear to
> me whether the MN is actually forbidden to issue the Link_Detected
> primitives all at once or in rapid sequence.

Ok. It may not be right exactly as you pointed out. What we'd like to
mention is, the case that the MN detects multiple BSs all at one
rarely happens, thereby which is unlikely to result in the signaling
overheads. But multiple BSs detection  has not been considered as a
important factor which can cause the signaling overheads so far. So we
think it's better simply to give no mention for it.

>
> EDITORIAL:
>
> In Section 5, the names of the 802.21 primitives are not in the
> subsection headings.  Additionally, the names of the 802.21 primitives
> are sometimes located far from the beginnings of the subsections which
> mention them.  One possible improvement is to list the names of the
> described 802.21 primitives at the beginning of Section 5, prior to
> the subsections mentioning individual primitives.  It might also be a
> good idea to pair the subsection titles with the 802.21 primitive
> names when making this listing.

Ok. We'll reflect this comment for clear readability and understanding.
But as mentioned above, we're planning to reivise the document so that
it does not rely on IEEE 802.21. Anyway we know what you're saying and
reflect this comment as far as possible.

> REFERENCES:
>
> If the Security Considerations section cites
> draft-ietf-mipshop-fmipv6-rfc4068bis-04 as being applicable to this
> document, shouldn't that reference be normative, rather than
> informative as it is here?  Also, informative reference [802.21] cites
> IEEE P802.21/D7.1, but the most recent draft that is listed in IEEE
> Xplore is D8.0.  Should the citation be updated?  (I do not have
> access to either draft through my institutional subscription.)  Also,
> I wonder if 802.21 should be a normative reference, but this may not
> be necessary if this I-D is meant to stand separately from 802.21.
>

Ok. But I'm not sure that the informational RFC can be regarded as a
normative reference because idnits-checking sometimes gives a warning
message as below.

** Downref: Normative reference to an Informational RFC: RFC 3753 (ref.
'5') (this happened during idnits-checking for another document)

It is not still clear to me after reading rfc3967, and I'll ask it to
WG chair or AD. Regarding the out-of-date documents,  we'll refer to
the latest one
(currently 802.21 D9).

I think your feedback is very useful to improve fh80216e document,
and thanks again for that.

- Best regards,

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