[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: NAT Traversal



pcn@cisco.com ("Chinna N.R. Pellacuru") writes:
<snip>
> > Whole point of SPI's is that they're values that are convenient for the
> > receiver to handle. Thus, having them mandated by either remote SPI
> > selection, or some mystical 'NAT compatibility hash function' sounds
> > not-so-convenient to me.
> OK, it's the prettyness and other vague arguments again:
> 
> - IKE is a key management protocol. "NAT discovery" doesn't belong in a
> key management protocol. Go get your own protocol to do weird things like
> "NAT discovery". We have enough people pulling their hair off, looking at
> the complexity of IKE. We are trying to simplify it in Son-of-IKE, but
> looks like some people just don't get it. How does Son-of-IKE do "NAT
> discovery"?! Why should "NAT discovery" be a requirement for a key
> management protocol? Yeah, IKE will soon solve all our problems, and we
> can go home happy and start thinking about the grandson-of-IKE. How
> convenient!

Setting SPIs by some magic formula sounds of NAT-oriented kludge to me as
well.

<snip>

> What design principles is your solution based on? Why is not changing a
> NAT device the "most important" design principle? NAT changes every day to
> accomidate new protocols. It's not the case that NAT devices don't change
> at all, and all new protocols have to do UDP encapsulation to get through
> NAT! We will not change NAT but screw up most of IKE and IPsec!

Unfortunately you are NOT usually able to choose which type of NAT you are
behind. Some of the hotels, ISPs et al whose "Internet Access" I've tried
to use have had awful kludge NATs that basically do simple TCP/UDP NAPT
without any support for other protocols or application level handling.

If 'change all network devices' was applicable solution, I'd say we'd be
running IPv6 and not worrying about the legacy issues (such as NAT) at all.

Why isn't RSIP out there everywhere if that is a valid assumption? 

> > What do you do in case of collisions? Not let traffic through? One big
> > server can have say, 10k SAs up at any time, so chance of collision _does_
> > exist there, and solution that works on best-effort basis isn't very good
> > one.
> Tell me about it. How does your "NAT keepalives" make absolutely sure that
> the NAT translations are kept alive? Are you sending a keepalive every
> microsecond to be absolutely sure that no NAT translation expires? What if
> some NAT box is using a sub microsecond timeout to blow away it's UDP
> translations. There are practical and acceptable limits for everything.
> You can very rarely design for the absoute, if at all.
> 
> In your case if a NAT translation expires for some reason beyond your
> control (for example a NAT implementation decides to prune it's
> translations randomly because there are too many translations), then you
> are completely hosed!
> 
> ------------------------------------------------------------------
> Important note: But if NAT is translating on SPI matching, it can always
> setup the translations again just by matching the SPIs.
> ------------------------------------------------------------------

What if traffic is (mostly) unidirectional? I believe this match-SPI logic
works on assumption that you have traffic going out semi-constantly.

Is that valid assumption? 

In case of some UDP-based streaming applications, for example, I have
encountered up to minute of unidirectional traffic. If your NAT happens to
reset mappings in 30 seconds (which seems to be industry minimum, barring
running out of memory), your stream is screwed half the time.

<snip>
> Good point. We'll write up an ID and submit it. You can discuss possible
> solutions until there is some critical mass. You don't have to absoultely
> start with an ID to even start discussing some ideas.

Obviously. But comparison is unfair if one solution is totally specified
and other one is mostly handwaving (I've seen maybe one or two paragraphs
about it here). And I believe comparison is what you're very bent on.

<snip>
> I think it's prudent to let NAT do it's job, so that it knows what it is
> doing.  This is more natural, and this is how NAT deals with all protocols
> under the sun. But as usual, IPsec want's to act special. We are special,
> we are immortal, we are a "security protocol"!

You believe we can actually keep all NATs up to date constantly? By that
argument, we could get instant upgrade to IPv6 as well as long as IPv4
worked side-by-side. I don't believe in that.

> Ever wonder why customers are buying those "IPsec pass-through" boxes like
> crazy? Because they work and it is simple and elegant and because of it's
> simplicity they are cheap.

The pass-thru works for end-user but not for ISP. In case of single user,
you don't need to maintain state and state resets don't hurt (you can have
dedicated memory easily enough for few IKE/IPsec SAs).

> I hope that in the best interest of the customers a good working solution
> gets standardized, not something that is bizzare and does NOT work.

Likewise.

> > > -Most of all, massive hand waving about "built-in host NAT implementation
> > > within the IPsec stack" is the most prettiest of all
> > It isn't mandatory; however, it makes possible what the simple 'passthru'
> > fails in.
> Please stop this hand waving atleast until someone gets back to me on the
> details of how this will work. I am yet to receive a clarification on the
> scenario I described in my other mail. For now let's just say that no
> solution can handle this scenario, and it is not a requirement to move
> forward.

Read draft-stenberg-ipsec-nat-traversal-02.txt (it's long expired but it's
still available on the 'net and it details some design things better than
current drafts). Section 3.4 details built-in NAT functionality.

> Expect to see our ID soon, and you can try and poke holes in our approach.
> It's nothing special. It's just the IPsec pass-through with the added SPI
> matching to give NAT more intelligence about IPsec.

Looking forward to it.

>     chinna

-Markus

-- 
Markus Stenberg <stenberg@ssh.com> of SSH Communications Security (www.ssh.com)