[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: NAT Traversal
pcn@cisco.com ("Chinna N.R. Pellacuru") writes:
> Depending on local policy, one of the following MUST be done:
> a) If the protocol header after the ESP header is a TCP/UDP
> header, zero the checksum field in the TCP/UDP header.
> b) If the protocol header after the ESP header is a TCP/UDP
> header, recompute the checksum field in the TCP/UDP header.
> c) If the protocol header after the ESP header is a TCP/UDP
> header and the peer's real source IP address has been received
> according to [Kiv00], incrementally recompute the TCP/UDP checksum:
> - subtract the IP source address in the received packet
> from the checksum
> - add the real IP source address received via IKE to the checksum
>
> - What "local policy" is being reffered to here?
Implementations own local policy. If the implementation knows for sure
that it's TCP/UDP stack does not care about checksums, it can simply
zero them. If the IPsec + NAT-T is working under operating system
TCP/UDP stack, and cannot affect the checksumming code of the stack,
it needs to recalculate the checksum (either by incremental update or
with full packet).
> - If it is OK here to just "recompute the checksum field" why not do it
> for all ESP decapsulation.
Performance reasons. Also it is simply extra stuff if you know that
the operating system stack is going to ignore it anyways.
> - IKE is a key management protocol. "NAT discovery" doesn't belong in a
I agree. Some people in the WG think that we should also allow NATs to
live, thus we must cope with them. If you do not agree with the IPsec
WG, then you should complain to WG in general.
The IPsec WG charter has item:
----------------------------------------------------------------------
The IPSEC working group will restrict itself to the following
short-term work items to improve the existing key management protocol
(IKE) and IPSEC encapsulation protocols:
1. Changes to IKE to support NAT/Firewall traversal
...
----------------------------------------------------------------------
> - Cookies are used to identify IKE SAs. Just because you have a bizzare
Yes. Cookies identify IKE, and there is NOTHING anybody else can
assume that the cookies are. For example the one of the son of the ike
drafts changes the order of the cookies to fix one problem in IKE (i.e
the cookie order will always be receiver, sender, not initiator,
responder). Also the sender cookie can change. This means that all the
NATs doing IKE cookie magic will be broken again...
> - Port 500 is for IKE, not for UDP encapsulated ESP traffic. The rest of
> the world assumed that, and now that you are coming in later and breaking
> that assumption, you should deal it somehow, and not expect the rest of
> the world to just vanish. How convenient!
Because of the broken NAT boxes we propably need to do special hack to
switch ports on the fly inside phase 1 just to get those broken NAT
boxes working.
> What design principles is your solution based on?
Has to work with existing hardware. When this proposal was first made
none of the NAT boxes did this kind of broken magic on the IKE
packets, thus it worked fine with NAT boxes out there. Then we
suddenly noticed that our fine proposal that worked everywhere has
been broken by people doing some kind of magic that do work sometimes
somewhere if the phase of the moon is right.
> Why is not changing a NAT device the "most important" design
> principle?
I think second largist (or so) ISP in Finland would be too happy if I
go there and say that I want to change their NAT boxes, so that I can
run IPsec through it.
> NAT changes every day to accomidate new protocols.
NAT might change, installed base does not change that often. What I
would really like to see to get those broken NAT boxes to support
basic IP properly before they start breaking other protocols. If the
NAT vendors cannot even get the fragmentation/reassembly working I
don't think we can assume they can get anything done properly.
> Ever wonder why customers are buying those "IPsec pass-through" boxes like
> crazy?
Propably because they don't know anything about it and they do not
know how it works? They think it might work, and next time when they
start using it they will notice that it only works in some limited
cases?
> Because they work and it is simple and elegant and because of it's
> simplicity they are cheap.
Considering how much IPsec is now used if we count out all the VPN
stuff, I don't think you can say that they work because people buy
them... I think most of the customers who buy them haven't run single
IPsec session through the boxes.
--
kivinen@ssh.fi
SSH Communications Security http://www.ssh.fi/
SSH IPSEC Toolkit http://www.ssh.fi/ipsec/