[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: IKEv2 stuff.. Re: More MODP Diffie-Hellman groups for IKE

RFC 2407 says:

4.5.3 Attribute Negotiation

   If an implementation receives a defined IPSEC DOI attribute (or
   attribute value) which it does not support, an ATTRIBUTES-NOT-SUPPORT
   SHOULD be sent and the security association setup MUST be aborted,
   unless the attribute value is in the reserved range.

   If an implementation receives an attribute value in the reserved
   range, an implementation MAY chose to continue based on local policy.

This is a problem for adding new SA attributes because including
an alternate proposal doesn't help.  I believe there was agreement
on the list that the text in the first paragraph above is too
aggressive and should be replaced by a requirement to ignore any
proposal containing an unsupported attribute or value.

--David

> -----Original Message-----
> From: Michael Richardson [mailto:mcr@sandelman.ottawa.on.ca]
> Sent: Friday, August 31, 2001 12:41 PM
> To: Ari Huttunen
> Cc: Jason Palmatier; ipsec@lists.tislabs.com
> Subject: Re: IKEv2 stuff.. Re: More MODP Diffie-Hellman 
> groups for IKE 
> 
> 
> 
> >>>>> "Ari" == Ari Huttunen <Ari.Huttunen@F-Secure.com> writes:
>     Ari> 40000 + number of bits in the group.
> 
>     Ari> It would be nice to have officially assigned numbers, though.
>     Ari> Especially since you cannot negotiate this by having 
> a VID, since
>     Ari> they are used in the first message.
> 
>     Ari> The same restriction applies to the.. dare I say 
> it?.. here goes..
>     Ari> X-Auth authentication type. There's no way to 
> negotiate it's usage
>     Ari> by using a VID. Our new software version sends this 
> automatically,
>     Ari> and a couple of vendors whose software refused any 
> connection when
>     Ari> they received an attribute they didn't understand, 
> agreed to change
>     Ari> their software that it skips a transform it doesn't 
> fully understand
>     Ari> and tries to match the next transform.
> 
>     Ari> The current RFCs do not state what to do when 
> something like this
>     Ari> happens.. i.e. an unknown attribute is received in a 
> transform payload.
> 
>   I thought that you are supposed to ignore proposals that you do not
> understand. Where "understand" means either that you match:
> 	    assigned #,		  
> 	    (VID, private#) 
> 
> ]       ON HUMILITY: to err is human. To moo, bovine.         
>   |  firewalls  [
> ]   Michael Richardson, Sandelman Software Works, Ottawa, ON  
>   |net architect[
> ] mcr@sandelman.ottawa.on.ca 
http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy");
[