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

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

Except if the NAT times out there is NO WAY for the "gateway" to send
the IKE message to the "client".  Sure, if the "client" is the
initiator of the new message then we don't have a problem, but the
whole point was that the "server" may need to initiate re-key or other
notification messages while the IKE SA is alive.

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

Ok, your question is acknowledged.  Others believe that the "server"
IKE daemon may need to communicate with the "client" IKE daemon for
server-initiated re-key or notification messages.  You may disagree
with that, but the consensus seems to be that such communication is
required.

>     b) if you wish, the second keepalive should not hurt anyone.

So now you're doubling the number of "keepalive" packets?  Worse, you
are now _FORCING_ keepalives on the IKE port (because IKE is only
rarely used, most of the traffic on the IKE port will be keepalives,
in your model).

At least if you overload ESP onto the same port as IKE then any 'real'
traffic will automatically act as your keepalive.  That means you only
need to send out additional keepalives when you don't have any other
outgoing traffic.  Similarly, you have a direct binding between IKE
and ESP.

What happens if your ESP binding disappears and IKE doesn't?  Or
worse, what happens if your IKE binding disappears and ESP doesn't?
Moreover, how are you supposed to tell your peer what the ESP port
will be?  If you're behind a NAT box, you have no idea what port
your peer will see.

At least if you overload onto IKE, you already know the port number.
Otherwise, the client would have to send an ESPoUDP packet to the
server on some other port but somehow tie the existing IKE negotiation
onto that other port?  Gee, now THERE'S a reduction in complexity for
you -- dynamically changing port addresses.

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

Have you ever had a NAT box (that you do NOT control) fail on your in
the middle of your session?  If you had, you would't be so quick to
judge.  Are NATs evil?  Yes.  But they're an evil we have to live with
so long as "we" don't control the connectivity we're given (e.g. at a
conference).

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