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

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.

- JOuni


> 
>   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?
>