[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: IKEv2 stuff.. Re: More MODP Diffie-Hellman groups for IKE
I have also been making the assumption that if you send a VID in the first
message then it is acceptable to send private attributes in the SA
proposals.
I think implementations that fail automatically when they recieve an unknown
attribute are just broken. It's not just private attributes that they'll
choke on. What happens to their already deployed products when someone
proposes AES?
Andrew
-------------------------------------------
Upon closer inspection, I saw that the line
dividing black from white was in fact a shade
of grey. As I drew nearer still, the grey area
grew larger. And then I was enlightened.
> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com
> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Ari Huttunen
> Sent: Tuesday, August 28, 2001 4:05 PM
> To: Jason Palmatier
> Cc: ipsec@lists.tislabs.com
> Subject: IKEv2 stuff.. Re: More MODP Diffie-Hellman groups for IKE
>
>
> 40000 + number of bits in the group.
>
> It would be nice to have officially assigned numbers, though.
> Especially since you cannot negotiate this by having a VID, since
> they are used in the first message.
>
> The same restriction applies to the.. dare I say it?.. here goes..
> X-Auth authentication type. There's no way to negotiate it's usage
> by using a VID. Our new software version sends this automatically,
> and a couple of vendors whose software refused any connection when
> they received an attribute they didn't understand, agreed to change
> their software that it skips a transform it doesn't fully understand
> and tries to match the next transform.
>
> The current RFCs do not state what to do when something like this
> happens.. i.e. an unknown attribute is received in a
> transform payload.
>
> Ari
>
> Jason Palmatier wrote:
> >
> > Have numbers been assigned to the additional MODP groups
> described in
> > draft-ietf-ipsec-ike-modp-groups-01.txt ? The bakeoff
> notes seemed to
> > indicate some testing was carried out using new larger
> groups and timeouts
> > occured from the extra computation. Were these the MODP
> groups described
> > in the above draft? If so, what numbers were used to
> negotiate them or
> > were they negotiated in a different manner? Any help would
> be appreciated.
> >
> > Jason Palmatier
> > IBM iSeries eServer
> > Endicott, NY
> > email: palmatie@us.ibm.com
>
> --
> Ari Huttunen phone: +358 9 2520 0700
> Software Architect fax : +358 9 2520 5001
>
> F-Secure Corporation http://www.F-Secure.com
>
> F(ully)-Secure products: Securing the Mobile Enterprise
>
References: