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

Re: draft-ietf-ipsec-udp-encaps-00: non-500 ESP encap, 32bits of , i-cookie=0


>     Derek> For NAT traversal, I think it is eminently ideal for the keying
>     Derek> and data streams to share a port..  Otherwise you need twice as
>     Derek> many keepalives to keep the NAT mapping happy.
>
>   Why do we have to keep the NAT mapping for the IKE stream port alive?
>
>   It isn't like the "gateway" is going to be able to initiate to the
client
> unless the client cooperates.

The gateway might need to initiate a rekey, or even send some sort of
keepalive / DPD packet (even though none have been standardized at the
moment), or for that fact some sort of Informational message (INVALID SPI?).

>
>   The only real thing that has to be done is to have the responder reply
to
> the origin port each time. We already know that the Internet dies in the
> presence of an active attack (you can just drop all packets!), so I do not
> see why we should worry about keeping the same port for IKE.
>
>     Derek> Speaking as the chair of KINK, I'd like to make sure that KINK
>     Derek> does a similar transposition.  I can certainly see carrying ESP
>     Derek> within KINK-like UDP messages on the KINK port.
>
>   For the firewall point of view, this really sucks.
>
>   For the non-security related NAT, who cares?
>
> ]       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");  [
>
> -----BEGIN PGP SIGNATURE-----
> Version: 2.6.3ia
> Charset: latin1
> Comment: Processed by Mailcrypt 3.5.6, an Emacs/PGP interface
>
> iQCVAwUBO3wwUIqHRg3pndX9AQGErAP+MdlBXt6901sQUoqK8o3cZFisDDGCqvtQ
> UEwEoeckT4ujeI2RP/Y1pK7MsYoIOVzUgzo5fg2W66kGxN0r6GnxjxLsHC1z2rbG
> vMlsP7QTug0QcyF/UOJQMi0Ar4fvh1y05MdknbvPBoWDtw23z9jNj6EHQW1KcNmk
> 3UPDijwsqNs=
> =3LMi
> -----END PGP SIGNATURE-----
Follow-Ups: References: