[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> Michael Richardson <mcr@sandelman.ottawa.on.ca> writes:

    >> Why do we have to keep the NAT mapping for the IKE stream port alive?

    Derek> Because IPsec (and IKE) are peer-to-peer protocols and not
    Derek> client-server protocols?  NAT forces a client-server protocol (only
    Derek> the client, sitting behind the NAT, can initiate connections).  What

  right, so let's not pretend that we need to retain the peer-to-peer ness.

    Derek> happens if the server wants to initiate a rekey?  Or needs to notify
    Derek> the client IKE daemon of some importation information (e.g. "I'm going
    Derek> away -- delete your SA!").

  Fine.

    >> It isn't like the "gateway" is going to be able to initiate to the client
    >> unless the client cooperates.

    Derek> No, but while the client is connected the "gateway" may still have
    Derek> something to say _during_ the conversation.

  So, it says it.
  If the NAT has timed out, it creates a new source port. The gateway updates 
its notion of where the client is if the ISAKMP packets decrypts properly.

    >> 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> Yes, this should certainly be the case.  One should respond to the
    Derek> source port/IP that is in the received packet.  But that is a
    Derek> completely separate issue from over-loading IKE (or KINK) and ESP onto
    Derek> the same UDP port.

  Well, the argument for overloading is that it reduces the number of keepalives. 
    a) I question the need to keep the NAT mapping for the IKE port alive.
    b) if you wish, the second keepalive should not hurt anyone.

  If having everyone behind the NAT keep two ports on the NAT alive kills the
NAT box... well... uh...  (I'm trying to make a sad face, but it doesn't seem to work)

]       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

iQCVAwUBO31WkIqHRg3pndX9AQEKjAP/Sw19BZiBb8WwDpYWc2CQH7qZtmWo+F9k
KKjj/rhSo4emSeMWKnACB9acSxPl8e6/HWkvDQxM2BedkC2cBsme0FiwsXTyD8++
PhRGGo+DjHCnFdzmNEqaQ3avukkwBfn1uAC8rPuvX0lI9iBcMzZlr2xSoI7u518T
M2bJQQw0OXM=
=ddTb
-----END PGP SIGNATURE-----
Follow-Ups: References: