[MEXT] review of draft-bajko-mext-sod-01

[jouni korhonen <[e-mail]>]

Hi,

In Beijing meeting I volunteered to review draft-bajko-mext-sod-01.

I'll skip the editorials and such. The text would need some editing for sure ;)


* Section 1

   As per the current MIP6 [RFC3775] specification, only the MN has the
   ability to enable security for user-plane traffic. The HA has no
   ability to force the MN to secure user traffic.

Strictly based on rfc3775 yes. However, if IKE is used as the key management protocol, then it is possible to have some level of security level negotiation between the MN and the HA. That approach would not be as dynamic as proposed in the I-D but still..

* Section 2

This section would definitely benefit from having more references to the different technologies/elements listed. Also expanding some of the acronyms would not make harm.

* Section 3

   response acknowledging the request and setting the flag for user
   plane traffic security to Null indicating to the MN that the traffic
   on the link between the MN and HA will not be encrypted.

Setting to "Null"..? Do you rather mean the HA modifies the SPD for HA->MN direction accordingly and makes the MN destined user traffic to bypass IPsec? And a similar action needs to be done on the MN for the MN->HA direction.

* Section 4.1

   S    When set, this flag indicates HA acknowledges, or strongly
   recommends, use of user plane encryption. When clear, HA does not
   support or allow use of user plane encryption.

This also means that the MN has no way of knowing whether the S was unset because a) HA policy said so, or b) HA did not understand the whole thing. In case of b) the MN might want to detach from this particular HA and try to find a HA that supports the feature proposed in this I-D. I see this as an issue that needs to be solved somehow. 

* Section 4.2

I understand the introduction of this option but would still consider it not being an essential part of the on-demand security enhancement proposed by this I-D.

* Section 5

   This document does not require actions by IANA.

I kind of disagree ;)

As a summary. The proposed solution seems useful. Some work on the I-D is though needed.

- Jouni