[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: