[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
Michael Richardson <mcr@sandelman.ottawa.on.ca> writes:
> True.
> But, the security evaluation of what you permit through the firewall has
> now changed because standard products now make UDP port 500 a tunneling port.
And if you let through UDP/500 w/o IPPROTO 50, you're in just as much
trouble (and even being obnoxious). I would say this makes it easier
with a NAT gateway -- if you want to allow IPsec, you open UDP/500.
If not, then you don't. This way you don't need to keep track of TWO
things and make sure they match. In anything, this is simplifying
life!
> You are complicated the non-NAT case in order to support the NAT case.
> At least use a different port than 500.
How is this complicating the non-NAT case? In the case of non-NAT,
you get regular IKE. How is this complicated?
> I disagree with the need to keep the IKE port alive.
Then you are confused about why there is IKE phase-I state.
> In order to support this in a BSD protocol stack I must write a kernel
> thread (or "nfsd"-like kernel process) that waits on UDP port 500 socket, and
> *if* the zeros are not present, must push the packet into a *different* port
> 500 so that my regular IKE can receive this.
Or you could have your IKE daemon parse it and then pass the packet
back down into the kernel. There are many ways of doing this.
-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
References: