Subject: [secdir] SECDIR review of draft-ietf-netlmm-grekey-option-06

From: Tobias Gondrom <[email-masked]>
Date: Thu, 02 Apr 2009 23:16:55 +0100

Hello,

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.

Overall, the document is clear and ok, although I am not that particularly strong with MIPv6 etc.

>From the review I have one simple Question and one comment:
1. simple maybe stupid Question: Section 6.4 Status codes:
What do you mean with the abbrevation "TBD" in this text?
e.g. "GRE KEY OPTION NOT REQUIRED (TBD less than 128)"

2. COMMENT on Section 9 Security Considerations: 
Considering the potential risks, I find it unnecessary weak to state that the there described security mechanisms "can be used". The section should use the stronger term of "SHOULD be" used instead throughout the whole section. 
Additionally in the last paragraph:"In Proxy Mobile IPv6 [RFC5213], the use of IPsec [RFC4301] for protecting a mobile node's data traffic is optional." should rather use the term "recommended"/"RECOMMENDED" instead of "optional".

Best regards,

Tobias

_______________________________________________
secdir mailing list
[email-masked]
https://mailman.mit.edu/mailman/listinfo/secdir

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 2 Apr 2009 17:51:45 -0500

Hi Tobias,
Thanks for the review and comments. Please see comments inline.

Regards,
Ahmad

> -----Original Message-----
> From: Tobias Gondrom [mailto:[email-masked]] 
> Sent: Thursday, April 02, 2009 5:17 PM
> To: [email-masked]
> Cc: [email-masked]; Muhanna, Ahmad (RICH1:2H10); Khalil, 
> Mohamed (RICH2:2S20); [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; [email-masked]
> Subject: [secdir] SECDIR review of draft-ietf-netlmm-grekey-option-06
> 
> Hello,
> 
> 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.
> 

[Ahmad]
What it means is this Status code will be allocated from the same
namespace as the Status code for MIP6 BA. The "TBD" will be replaced by
the proper number by IANA and since it is NOT a rejection code, it needs
to be the next available number less than 128.

> Considering the potential risks, I find it unnecessary weak 
> to state that the there described security mechanisms "can be 
> used". The section should use the stronger term of "SHOULD 
> be" used instead throughout the whole section. 

[Ahmad]
These risks are inherited from the base Proxy MIP6 protocol. A
recommendation of SHOULD in this specification which whole objective is
to facilitate a dynamic negotiation of the uplink and downlink GRE keys
using the existing Proxy MIP6 and MIPv6 signaling could be considered an
over specification on top of the base protocol.

> Additionally in the last paragraph:"In Proxy Mobile IPv6 
> [RFC5213], the use of IPsec [RFC4301] for protecting a mobile 
> node's data traffic is optional." should rather use the term 
> "recommended"/"RECOMMENDED" instead of "optional".

[Ahmad]
Actually, the same text is used in RFC5213 (Proxy Mobile IPv6) which
bases its reasoning on RFC3775 which states that it is optional.

The following is the text from RFC5213 under section 4.

"
   ............................................. As in Mobile IPv6
   [RFC3775], the use of IPsec for protecting a mobile node's data
   traffic is optional.
"

If we state here it is RECOMMENDED, we may be introducing a requirement
that is stronger than what in RFC5213. This specification does not
introduce any new requirement on top of PMIPv6 with respect to
protecting the mobile node's data traffic.