Re: [Ipsec] FW: Remaining issues for IKEv2

[Stephen Kent <kent@bbn.com>]

At 10:01 AM -0700 5/20/04, Paul Hoffman / VPNC wrote:
>At 10:18 AM -0400 5/20/04, Stephen Kent wrote:
>>At 7:56 AM -0700 5/19/04, Paul Hoffman / VPNC wrote:
>>>At 10:58 AM +0300 5/19/04, Tero Kivinen wrote:
>>>>One wierd thing it thas 4.4.1.1 says support for OPAQUE is MUST.
>>>
>>>Then that *needs* to be corrected in the next version of the draft.
>>
>>Support for the selector type in the SPD is trivial, and if we 
>>mandate support for OPAQUE now, then we're set for later elevation 
>>of one of these options to SHOULD from MAY, for example.
>
>True, but I worry about mandating the ability for a 2401bis system 
>to support a selector type when it doesn't support the mechanics 
>that goes with the selector. It gets tricky in 2401bis because the 
>new fragmentation ideas are spread throughout the document. We might 
>just have to live with that.

I appreciate the concern.  We are working on the next rev and found 
another place where OPAQUE seems appropriate (not for fragmentation 
support), which would be another reason to include it, if the WG 
agrees with the added material that refers to OPAQUE.

>
>>>>My preferred way would be #3 being SHOULD and #2 being MAY.
>>>
>>>That makes some sense too; it's just more adventurous than I would 
>>>be with this protocol without a lot more support from other 
>>>vendors.
>>
>>I agree with Tero that #3 as SHOULD is appropriate. My only concern 
>>re #3, as Ted noted earlier, is that it imposes an unacceptable 
>>burden on high speed implementations. Thus, if #3 is SHOULD, then I 
>>think it would be legitimate for such implementations to not 
>>support it (consistent with the interpretation of SHOULD).
>
>Agree. Not following a SHOULD because you know that you won't be 
>able to consistently figure out where the fragment would go is 
>perfectly legitimate.

I'm always encouraged when we agree :-)

>
>>   I would like these implementations to support #2 in that case. A 
>>statement that an implementation SHOULD support either #2 or #3 
>>might be one way of expressing this notion.
>
>A very good suggestion. The paragraph currently at the end of page 
>49 could be changed from:
>     To address the above requirements, three approaches have been
>     defined:
>To:
>     To address the above requirements, three approaches have been
>     defined. Implementations MUST support method #1 below, and SHOULD
>     support method #2 or method #3 (or both).

again, great!

>Editorial suggestion: breaking out the three proposals as 
>subsections (7.1, 7.2, 7.3) would make it easier to read, 
>particularly if you add more text to them.
>

Thanks for the suggestions,

Steve

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