Re: [Ipsec] FW: Remaining issues for IKEv2

[Tero Kivinen <kivinen@iki.fi>]

Paul Hoffman / VPNC writes:
> At 3:13 PM +0300 5/17/04, Tero Kivinen wrote:
> >Anyways I can accept method #3 being SHOULD, MAY or even MUST, and
> >Method #2 being MAY.
> 
> Certainly not a MUST; it really isn't needed for interoperability. It 
> is quite conceivable that many systems would only want to work with 
> ANY, and not need either #2 or #3.

One wierd thing it thas 4.4.1.1 says support for OPAQUE is MUST. In
the RFC2401 it was SHOULD. I think it should follow the same selection
we have here for #2, i.e.. MAY or SHOULD. 

> >Our implementation have been using method #3 since year 1998, so there
> >is some experience with that. I do not know if others do that, but my
> >guess is that there is also other implementations doing same. For the
> >#2 there is no experience, as it do require OPAQUE support, thus there
> >is no way to negotiate it in the IKEv1.
> >
> >The case #3 can be simply be used without any prior negotiation or
> >configuration, and if both ends support it then packets will go
> >through.
> 
> But the negotiation is a pretty important part of #3. I see your 

No, not really. Negotiation is only needed if there is another way to
do it, i.e. if the #2 is defined. Int IKEv1 there was no way to use
#2, as you could not negotiate OPAQUE, thus there was no other way to
get fragmented packets with port selectors through. 

> point about wanting one of #2 or #3 to be a SHOULD, but I think it is 
> still way too early to prefer one, and I think it's too early to 
> guess that one will work better than the other.

Might be. I was simply commenting that we do have experience of the
statefull inspection case, so if we use running code as an guideline
which to make SHOULD, we at least have some running code for the case
#3.... 

> It is appropriate when going from Proposed to Draft to change some of 
> the requirements. Maybe leave both of these MAYs for now with the 
> intention of upping one or both to SHOULD when the document advances.

No, I do not think we need MAY+ there now... If they are MAYs then
they are MAYs, and thats it. Lets make the decision now and then
accept that. 

> >I can already say that #3 is feasible. If it is useful, that I cannot
> >say, as most of the people do NOT use port selectors at all.
> 
> A very good reason to wait until there is more experience. I suspect 
> that the new discussion in 2401bis will cause some developers to pay 
> much more attention to this and possibly exposed it more to their 
> customers. The results of that (or the continued lack of interest) 
> will be valuable.

So I assume that your vote would be on both on being MAY?

My preferred way would be #3 being SHOULD and #2 being MAY. 
-- 
kivinen@safenet-inc.com

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