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

[jouni korhonen <[e-mail]>]

Hi again,

GOTO the end of mail.


On Feb 10, 2011, at 12:36 AM, Julien Laganier wrote:

> Jouni,
> 
> On Wed, Feb 9, 2011 at 2:22 PM, jouni korhonen <[e-mail]> 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?

My original comment was to point out that the statement "The HA has no ability to force the MN to secure user traffic." is not so black and white in all cases. Using IKE definitely is not as slick as the solution proposed in the I-D. I am completely happy if the earlier statement is modified e.g. "The HA has limited abilities, if any, to force the MN to secure user traffic." And the probably referencing to RFC4877.

- JOuni


> 
> --julien