[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: I-D ACTION:draft-ietf-ipsec-nat-t-ike-04.txt
> We do need the vendor ID after we have the RFC too, as otherwise we
> cannot detect if the other end supports the NAT-T at all (and sending
> new payload numbers etc before getting information if the other end
> supports them would be very good for interoperability).
In other words, updating the minor version would be the appropriate
solution, but chances are this will break a whole bunch of implementations,
so keeping the vendor id will be simpler. I concur.
One more issue that I just noticed. When rekeying a phase 1 w/ NAT-T, you
automatically send packets to port 4500. Does this mean that we shouldn't
include the NAT-D payloads during the phase 1 rekey? What about the vendor
ids?
Andrew
--------------------------------------
The odd thing about fairness is when
we strive so hard to be equitable
that we forget to be correct.
> -----Original Message-----
> From: Tero Kivinen [mailto:kivinen@ssh.fi]
> Sent: Tuesday, November 12, 2002 3:47 PM
> To: ipsec@lists.tislabs.com
> Cc: "Andrew Krywaniuk"
> Subject: Re: I-D ACTION:draft-ietf-ipsec-nat-t-ike-04.txt
>
>
> andrew.krywaniuk@alcatel.com ("Andrew Krywaniuk") writes:
> > I'm sure that a whole bunch of us are wondering: what's
> with the unspecified
> > vendor id?
> > Does this mean that the current draft is going to be the
> last one and all
> > further numbers will be assigned by IANA? (In that case,
> why would we need a
> > vendor id at all?)
>
> Yes, we do belive that this is the final version, as I wanted to
> remove those XXX change later texts from the document, I replaced them
> with proper numbers. Anyways I do not want anybody to implement
> anything based on those numbers before we get this out as RFC I left
> out the one piece i.e the vendor-ID.
>
> We do need the vendor ID after we have the RFC too, as otherwise we
> cannot detect if the other end supports the NAT-T at all (and sending
> new payload numbers etc before getting information if the other end
> supports them would be very good for interoperability).
> --
> kivinen@ssh.fi
> SSH Communications Security http://www.ssh.fi/
> SSH IPSEC Toolkit http://www.ssh.fi/ipsec/
>