Re: [netlmm] Issue: Auth Option support

Julien Laganier wrote:
> On Friday 07 September 2007, Alexandru Petrescu wrote:
>> Julien Laganier wrote:
>>> Hi Sri,
>>>
>>> On Thursday 06 September 2007, Sri Gundavelli wrote:
>>>> I'm confused, should the draft say
>>>>
>>>> "Both LMA and MAG MUST implement IPsec" and
>>>> "all the signaling messages SHOULD be protected using IPSec".
>>>>
>>>> Will this ok, when reviewed by the security folks ?
>>>>
>>>> or mandate IPsec for this specification and let other draft
>>>> relax this in the presence of an alternative approach ?
>>>>
>>>> Please comment.
>>> Somehow, "MUST implement" and "SHOULD use" together seems a bit
>>> tautologic.
>>>
>>> To me "SHOULD use" is sufficient since it covers both of the two
>>> possibles cases:
>>>
>>> - deployment follows the SHOULD recommendation, it uses IPsec to
>>> protect PMIPv6, in which case it supports it, since it's using it
>>> :), or
>>>
>>> - deployment ignores the SHOULD recommendation, does not uses
>>> IPSec, in which case it is useless to implement it since it's not
>>> used...
>>>
>>> I'd prefer having "MUST protect integrity of signalling messages,
>>> and SHOULD use IPsec ESP to protect integrity of those messages".
>>> We might also add "MAY use IPsec AH".
>> I'm not sure what you mean...
>>
>> Do you mean to use ESP to offer authentication (integrity
>> protection)? I'd suggest to make AH a should, for this purpose, not
>> ESP.
> 
> For an IPsec implementation ESP is MUST and AH is a MAY, therefore I 
> meant exactly what I said: ESP for integrity protection. For the 
> reference, this is an excerpt from Section 3.2 of RFC4301:
> 
>                         IPsec implementations MUST support ESP and MAY
>    support AH. (Support for AH has been downgraded to MAY because
>    experience has shown that there are very few contexts in which ESP
>    cannot provide the requisite security services.  Note that ESP can be
>    used to provide only integrity, without confidentiality, making it
>    comparable to AH in most contexts.)

Ok, I was not aware of that paragraph.

I was thinking AH protection was enough but it seems it is not 
necessary, and that ESP is necessary.

>> Or do you mean to use ESP to offer confidentiality (encrypted
>> packets)? 
> 
> No I don't mean that. I don't see confidentiality protection as a 
> requirement for PMIPv6 security.

Err...

>> In this case, ESP is the only possibility to do 
>> confindentiality, because authopt doesn't; so not sure why needing to
>> debate the use of ESP for confidentiality, it is pretty clear.
>>
>> Also, when you say to protect integrity of signalling messages, which
>> of those do you assume?  authopt only does bu/back, it doesn't do
>> other mip6 signalling.  So I think you only assume integrity of
>> bu/back, right?
> 
> I mean protection of PMIPv6 messages, i.e. defined/used by the PMIPv6 
> specification. Seems that's limited to pBU/pBAck, right?

Right... that's what the PMIPv6 spec says.  It is strange we struggle 
with timestamp/seqno issues whose main goal is to make it more reliable 
and at the same time we ignore Binding Error, Binding Refresh Request.

Alex

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

_______________________________________________
netlmm mailing list
netlmm@ietf.org
https://www1.ietf.org/mailman/listinfo/netlmm