[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



-----BEGIN PGP SIGNED MESSAGE-----


>>>>> "Derek" == Derek Atkins <warlord@mit.edu> writes:
    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 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: