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

[Julien Laganier <[e-mail]>]

Jouni -

Thanks for the review!

Please see some comments below:

On Wed, Feb 9, 2011 at 1:19 PM, jouni korhonen <[e-mail]> wrote:
> 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..

My understanding of IKE is that although it can be used to update the
SPD,  changing the fundamentals of a bypass or protect rules that
applies to user plane traffic wouldn't  fall in the scope of IKE --
see quote from RFC 5996:

   When an RFC4301-compliant IPsec subsystem receives an IP packet that
   matches a "protect" selector in its Security Policy Database (SPD),
   the subsystem protects that packet with IPsec.  When no SA exists
   yet, it is the task of IKE to create it.  Maintenance of a system's
   SPD is outside the scope of IKE, although some implementations might
   update their SPD in connection with the running of IKE (for an
   example scenario, see Section 1.1.3).

   Traffic Selector (TS) payloads allow endpoints to communicate some of
   the information from their SPD to their peers.  These must be
   communicated to IKE from the SPD (for example, the PF_KEY API [PFKEY]
   uses the SADB_ACQUIRE message).  TS payloads specify the selection
   criteria for packets that will be forwarded over the newly set up SA.
   This can serve as a consistency check in some scenarios to assure
   that the SPDs are consistent.  In others, it guides the dynamic
   update of the SPD.

Would you disagree?

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

I think so.

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

I agree with Jouni. And actually I've commented many times ;-) that
the flag should go away and a new mobility option should be included
that carries to flag, an 'I' for integrity protection, and a 'C' for
confidentiality protection since these are different capabilities.
Also having it in a mobility option would avoid the issue outline
since a HA that doesn' t understand the option would not send it back
and the MN wouldn't have to guess what happened.

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

Agree.

> * Section 5
>
>   This document does not require actions by IANA.
>
> I kind of disagree ;)

I think we need action by IANA to register new mobility option.

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

Agree.

--julien