[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



Michael Richardson <mcr@sandelman.ottawa.on.ca> writes:

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

Because IPsec (and IKE) are peer-to-peer protocols and not
client-server protocols?  NAT forces a client-server protocol (only
the client, sitting behind the NAT, can initiate connections).  What
happens if the server wants to initiate a rekey?  Or needs to notify
the client IKE daemon of some importation information (e.g. "I'm going
away -- delete your SA!").

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

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

>   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.

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

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord@MIT.EDU                        PGP key available


Follow-Ups: References: