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

Re: Avoiding tricking IKE v2 nodes into talking v1



On Mon, 26 Aug 2002, Paul Koning wrote:

> >>>>> "Jan" == Jan Vilhuber <vilhuber@cisco.com> writes:
>
>  Jan> On Mon, 26 Aug 2002, Paul Koning wrote:
>  >> But vendor ID payloads don't announce any protocol action, they
>  >> only set a namespace for subsequent private payloads.  You can
>  >> only have one at a time
>
>  Jan> Where does it say this? I see no reason why you couldn't have 15
>  Jan> vendor-id payloads in message 5 or 6 (or anywhere else for that
>  Jan> matter).
>
>  Jan> Also, I don't see why a vendor-id is narrowly defined as "set a
>  Jan> namespace for subsequent private payloads" (unless I missed a
>  Jan> section in the IKE spec). I see them as announcing any
>  Jan> capability you like, with or without additional private
>  Jan> payloads.
>
> Ok, that's what I get for relying on memory rather than re-reading the
> words line by line... :-(
>
> Yes, it does say you can have more than one.  When you do that, it
> isn't clear to me which namespace then applies to the private payload
> numbers.  (The one immediately preceding it in the bytestream???)
>

Yes, you're absolutely right. But if all you are announcing is
'capability' rather than needing more payloads, you should be OK.

I agree it's suboptimal. I've never liked the vendor-id for that
reason (and one of these days I'll actually write up my counter-
proposal based on the radius vendor-specific attribute)...


> The spec does say that the payload announces an instance of an
> implementation, which isn't the same thing as announcing a request for
> a feature or action.  But I suppose it's reasonable enough to stretch
> it that far.
>

Modulo the namespace confusion, as you point out.

jan
 --
Jan Vilhuber                                            vilhuber@cisco.com
Cisco Systems, San Jose                                     (408) 527-0847

http://www.eff.org/cafe