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

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

FYI

Subject: secdir review of draft-ietf-mipshop-fh80216e-06
From: Tom Yu <[email-masked]>
To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Date: Wed, 20 Feb 2008 02:30:38 -0500

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.

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.

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.)

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.
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.

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.

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.
_______________________________________________
Mipshop mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/mipshop