Re: [Gen-art] Gen-Art Last Call Review: draft-burgin-ipsec-suiteb-profile-00

[Alexey Melnikov <[e-mail]>]

Hi Paul,

Paul Hoffman wrote:

>I'll jump in wearing my shepherd hat.
>
>On Jul 4, 2011, at 1:27 PM, Alexey Melnikov wrote:
>  
>
>>How are you planning to achieve interoperability if one endpoint can use a mechanism which the other end is not required to support?
>>    
>>
>
>The draft assures interoperability between peers that are both at a minimum level (minLOS) of security of 128 bits. It also assures interoperability between peers that are at a minLOS of 192 bits. It has a SHOULD-level wording that would assure interoperability for systems that have different minLOSs.
>
>There are policy reasons why a system might only handle one security level; however, for systems that don't have such policy restrictions, the draft says that they SHOULD handle the other level.
>
>This is a conscious decision on the part of the authors, one that has been discussed within the authors' organizations. In my mind, it is better that they are being honest about it instead of having requirements that we know will silently ignored by some policies.
>  
>
Ok, I withdraw my original comment on this text.

>>>  A responder configured in a system at a minimum level of security
>>>  of 128 bits SHOULD accept the first Suite B UI suite offered by the
>>>
>>>Is this a new requirement in this document, or is this repeating a general requirement stated in another document? If the latter, a reference is needed here, ideally accompanied by some text stating that the requirement comes from another document.
>>>
>>>Similar text later in the same section.
>>>
>>>  initiator that it can accommodate.  If none of the four suites are
>>>  offered, the responder MUST return a Notify payload with the error
>>>  "NO_PROPOSAL_CHOSEN".
>>>
>>>[kwb] These are new, so no reference is given.        
>>>
>>Why is this a SHOULD and not a MUST, i.e. what are the possible reasons for not selecting the first offered mechanism?    
>>
>
>A system at minLOS_128 might also be able to support 192-bit security and have a policy of preferring it; the initiator might offer them in the reverse order for some reason. This SHOULD allows the responder to achieve the higher security even if the initiator didn't prefer it.
>
After thinking a bit more about that: we had a similar debate in the 
SASL WG and decided that the responder has no reason to trust the order 
suggested by the initiator. Why is this SHOULD important at all? I would 
feel more comfortable if the whole sentence is deleted or restated not 
to use RFC 2119 keywords.

>>>  The administrative user interface, (UI), for a system that conforms
>>>  to this profile MUST allow the operator to specify a single suite.
>>>  If only one suite is specified in the administrative UI, the IKEv2
>>>  implementation MUST only offer algorithms for that one suite.
>>>
>>>This requirement is unusual, because IETF documents rarely have requirements on UIs. Can you please elaborate what is this trying to achieve?
>>>      
>>>
>
>RFC 4308, "Cryptographic Suites for IPsec", is unusual, and is an exception to that "rarely". A small but significant number of IPsec VPN vendors have followed it.
>  
>
Ok.