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

Jouni,

On Wed, Feb 9, 2011 at 2:22 PM, jouni korhonen <[email protected]> wrote:
> Julien,
>
> On Feb 9, 2011, at 11:53 PM, Julien Laganier wrote:
>
>> Jouni -
>>
>> Thanks for the review!
>>
>> Please see some comments below:
>>>
>>> * 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:
>
> I should have written my thoughts clearer. What I meant here is that a MN and a HA may have a bunch of proposals to agree on. The MN and the HA can agree on a transform that provides no encryption. And this is essentially for the HA to enforce. I know it is somewhat far fetched but doable to some extent.

Hmm. If for a single MN-HA pair there might be situations in which
confidentiality protection is to be afforded and other in which it is
not, the SPD will have to be modified. Quoting RFC 4301:

           o Processing info -- which action is required -- PROTECT,
             BYPASS, or DISCARD.  There is just one action that goes
             with all the selector sets, not a separate action for each
             set.  If the required processing is PROTECT, the entry
             contains the following information.
[...]
                - algorithms -- which ones to use for AH, which ones to
                  use for ESP, which ones to use for combined mode,
                  ordered by decreasing priority

Would it be correct to interpret your statement as having on the HA a
PROTECT rule with algorithms as follows and in that order:

    AES_CBC + HMAC-SHA1-96 followed by HMAC-SHA1-96

would allow the the MN to negotiate Confidentiality protection and
Integrity Protection vs. Integrity protection only by changing its
local SPD only to contain either AES_CBC + HMAC-SHA1-96
(Confidentiality protection and Integrity Protection) or HMAC-SHA1-96
(Intergrity protection only) and thus no MIPv6 signaling extension is
needed in this case because IKE would do the job?

I'd agree.

However, the SPD would have to be modified in case the userplane is to
be passed cleartext, and that means the HA SPD has to say BYPASS, and
IKE doen't allow to negotiate this.

Comments?

--julien