Re: peer address protection and NAT Traversal

[Michael Richardson <mcr@xxxxxxxxxxxxxxxxxxxxxx>]

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


>>>>> "Charlie" == Charlie Kaufman <Charlie_Kaufman@xxxxxxxxxxxxxxxx> writes:
    Charlie> Mapped UDP port assignments in NATs can be timed out prematurely. When this
    Charlie> happens, packets coming from the Internet to the NAT will be dropped (or

  I thought that a great deal of effort needed to be expended to make sure
that this doesn't occur...

    Charlie> against the node whose IP address was forged in the header. If he doesn't,
    Charlie> all the packets sent will be lost in the case where a genuine NAT remapped
    Charlie> addresses. Since NATs are not generally capable of cryptographic
    Charlie> authentication, there is no reliable way to distinguish these
    Charlie> cases.

...

    Charlie> So what I'd like to propose is that IPsec SAs *not* try to survive
    Charlie> mid-connection NAT renumberings. That an IP address and UDP port be

  I would agree here.
  If there were some way for the client to determine that the NAPT mapping
has changed, then it could essentially rekey the connection. One way to do
this is to have the gateway side reflect the NAPT ports involved to the
client *inside* of the IKE SA. 

  Yes, the gateway has to keep track of this stuff, but ultimately, the
client worries about rekeying things upon determining that the mapping has
changed. The gateway *does* have to always use the new mappings for IKE
packets - it just doesn't change the IPsec SA.

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] mcr@xxxxxxxxxxxxxxxxxxxxxx http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Finger me for keys

iQCVAwUBPiHggYqHRg3pndX9AQHUiAQAx9N35r2P9r+dIhqTR1tSAGyFWzdwxdmO
vtBj4WzB/puqRk25j77Kd8wcvo0Lus8NGVqqiJh8SoAnzkNFHzIJLwwcJ2dA8ebe
Ac7EmG8yNER+JK0wAUa9PLBysE/+vocfMfkJoyX9CRTe3LfuAqHL+iUH5IhwfpH6
LLMiwxZQNwc=
=OUMF
-----END PGP SIGNATURE-----