[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: NAT and IPsec
RE: NAT and IPsec
>In terms of requirements, I think we'd be on the rong path
>if we put much effort in getting all IPsec and KE modes
>to work.
Certainly, trying to get AH to work is a waste of
ime.
However, if it is possible to get transport mode SP
and IPCOMP to work, I'd argue that it is a win.
>approaches like RSIP aren't very fruitful
I'd agree. All approaches requiring changing code on
he host;
if you also require changing router code, then
eployment
will be of the same order of difficulty as IPv6. To y
mind, RSIP is a "short term" solution that an only be
deployed in the long term. That makes it a on-starter.
>Bernard's draft says in section 7.1 the ollowing...
>Is this really the case?
As you point out, it's better to send both ESP and ESP-encapsulated proposals at the same time, and see which ones are accepted. I'm going to
delete those paragraphs in the next version.
>I worry about the denial of service issues for lain
>UDP encapsulation.
I think that this is worth worrying about. In fact,
here
are some who believe that it is a show stopper. We hould
have this discussion up front, so we know what the potential attacks are, and can analyze the proposals
o
determine whether they are vulnerable.
> Does somebody have an idea how long a large NAT's DP
> session storage lasts, typically?
Low-end NATs can age sessions out as quickly as 0
seconds to a minute.
>have there been incidents to specifically block KE
>and IPsec but let other UDP traffic through implemented
>by a very hostile NAT
Some NAT vendors have required "upgrades" efore enabling
support of various protocols. The goal here seems to e to
obtain a fee every time the user attempts to add ew
host capabilities. This kind of business model
leads to products that are intentionally hostile. However, in most cases basic support for TCP and DP
can be assumed.
> To what extent do we believe that the use of Psec
> through NAT must be negotiated, and to hat extent
> it could just be _configured_?
I'm not a big fan of manual configuration. People se
their devices in many places -- when I'm at home
might use a NAT, but at work, perhaps not. A ood
solution should detect what situation I'm in
nd
do the right thing. Having to switch settings henever
you move detracts from the mobile experience.
> I saw in the minutes of the last NAT WG meeting
hat
> somebody proposed the use of L2TP to tunnel Psec.
To my mind this doesn't provide any advantages over UDP encapsulation, just more overhead.
>And doesn't Microsoft have some protocol that
unnels
>everything along that?
Other than various VPN solutions (PPTP, IPSEC tunnel ode,
L2TP/IPSEC), and a sockets remoting capability, I'm ot aware
of any other tunneling functionality implemented in indows.
Follow-Ups: