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

[<[e-mail]>]

Thanks for the reviews and comments.
We are cognizant of Julien's comments regarding the flag (from the past
two meetings :) ) and will make the necessary changes in the next rev.

-Raj

On 2/9/11 3:53 PM, "ext Julien Laganier" <[e-mail]> wrote:

>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