Re: draft-ietf-ipsec-ikev2-00.txt

[Shane Amante <shane@amante.org>]

Tero,

Thanks for the reply to some of my points.  Please see below.

On Sun, Dec 30, 2001 at 11:11:54AM +0200, Tero Kivinen wrote:
> shane@amante.org (Shane Amante) writes:
> > 2.6 Cookies
> > My observation is that Paragraph 6 ("It may be convenient for the
> > IKE-SA identifier ...") seems to be adding more complexity, rather
> > than promoting the stated goal of reducing it.  Is it too onerous to
> > get rid of the feature described in Paragraph 6?
> 
> Actually the feature that allows the responder to change the cookie
> also fixes one denial of service attack for the active attacker, which
> can listen all packets, and can send packets, but cannot remove
> packets in transit.

[snip]

Very clever.  It would be useful for the authors to include your above
paragraph in the spec, and a brief description of the attack(s) you
outlined, in order to elaborate on "why" the cookie changing feature,
in Paragraph 6, provides more value beyond just "convenience".



> > 7.7 Certificate Request Payload
> > 
> > Last sentence in this section: "If no certificates exist then no
> > further processing is performed-- this is not an error condition of
> > the protocol."  I recommend that this be considered an error in
> > IKEv2, otherwise how is the sender of the CERTREQ going to know
> > what was the specific problem with it's request?  I recommend the
> > following language:
> >    If no certificates exist, no further processing is performed.  A
> >    NOTIFY MUST be sent to the sender of the CERTREQ informing them of
> >    this fact using an appropriate error code, (defined below in the 
> >    "error codes" section of IKEv2 memo).
> 
> I hope that you mean that the negotiation still continues as normally,
> we just include that notification payload to the reply packet, but do
> not consider it as an error condition of the protocol. I think it must
> be warning condition only not error condition.

OK.  I was just trying to point out that a notify MUST be sent by the
Responder to let the Initiator know what was wrong with the CERTREQ.

[snip]


> > 7.10.1 Notify Message Types
> > 
> > Is it recommended that multiple NOTIFY payloads be packed into a
> > single Informational exchange?  Or, should multiple NOTIFY payloads be
> > put in their own, separate IKE messages?
> > 
> > Here are a few more suggestions, which are probably going to be quite
> > controversial since they go against the grain of re-using as much
> > of IKEv1 as possible:
> 
> I think we should use the format described in the
> draft-ietf-ipsec-notifymsg-04.txt (which seems to have expired). 

I can't find this in the IETF's internet-draft archive, do you or
someone else have a pointer or a copy that you could send to me?

-shane