[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