Re: [BEHAVE] REQ 1 and REQ 7 of RFC5382 were supposed to be fixed years ago

[ivan c <[e-mail]>]

Hi Simon,

See my comments interleaved.

On Tue, 18 Jun 2013 10:05:17 +0200, Simon Perreault
<[e-mail]> wrote:
> Ivan,
> 
> Thanks for the explanation. I believe I have a good understanding of 
> what you are proposing now.
> 
> There are several smaller technical issues with your reasoning which I 
> won't address now because they are tangential. I want to focus on your 
> suggestion that we should recommend port preservation. I see the 
> following major issues:
> 
> - Adding new constraints on NAT implementations is not going to meet 
> much success. I don't believe anyone is going to change their existing 
> NAT code now in such a fundamental way as to implement port preservation

> just because the IETF asks for it in a new RFC.

(First, to avoid any confusion, it is important to use the term "TCP port
preservation" instead of just "port preservation", as this only applies to
TCP)
In reality, TCP port preservation has already implemented by most home
NATs at least.
As already noted in Saikat Guha's paper back in 2005, almost all EIM NATs
in his sample set were already implementing TCP port preservation.
Nowadays, this is even more pervasive: Linksys, Netgear, and many others;
in a country like France, this is implemented by most ISP-made internet
triple-play gateways (called "Boxes" there) including the ones of Orange,
Free, SFR, Numericable, offering a near 100% coverage of the country.
The goal is to standardize what has already been widely deployed
worldwide, following the IETF mantra, "running code wins".
The alternatives for applications when a NAT does not have TCP port
preservation are not appealing: STUNT when the NAT is EIM, otherwise UPnP,
port forwarding, and, when all options have been exhausted, fallback on
the
worst of the worst: TCP over UDP (extensively used by bittorrent), which
is
dangerous for the internet as a whole.


> 
> - Port preservation is not applicable to CGN, where a subscriber often 
> only has access to a limited range of external ports.

It would be nice to elaborate on this. 
A CGN should leave the whole ephemeral ports range to all its subscribers,
which is defined by the IANA to be [2^15+2^14;  2^16-1]. Combined with TCP
port overloading, this allows usage of TCP port preservation by CGNs.
Rationale of why port overloading is acceptable for TCP:
- as long as endpoints are distincts, port overloading preserves the
uniqueness of the 5-tuple.
- when 2 endpoints are the same, the NAT refuses, silently or actively,
the second TCP connection. The application can then retry with a new
ephemeral port. If p is the probability of conflict, and n the number of
tries, the probability of failure decreases exponentially in p^n, which
gives an essentially deterministic behavior. As a collision is expected to
be a rare event, the probability p would be small anyway.


> 
> - There are ways to improve the scalability of EIM without killing it. 
> I've been advocating for some time that NATs should be allowed to use 
> EDM for protocols that they know will not break, with EIM as a default. 
> For example, using EDM for TCP port 80 and UDP port 53 is easy, 
> harmless, and has a big impact.

Agreed, although some extra care is needed, as explained below, the
benefits clearly outweigh the complexity of the implementation.

As a preliminary remark, the use case that you mention of DNS request is
out of scope because each DNS request uses a new socket (non-bound, so it
uses a new local endpoint). As a result this doesn't reuse an existing NAT
mapping. Anyway, EDM should not be used as a fallback for UDP, for reasons
i'll skip for now, as I'm assuming the contentious point for CGNs is TCP,
not UDP.

First of all, the context for TCP: fallback on EDM is somewhat desirable
when there is a conflicting mapping. The alternative would be to actively
or silently refuse the outgoing TCP SYN, which is not desirable as it
somewhat breaks end-to-end connectivity guarantees. (although browsers for
instance are known to retry connections)
A NAT can fallback on EDM when it is clearly assumed that the application
issuing the TCP SYN is not P2P. This is often the case for HTTP, and can
be
used as a heuristic by the NAT/CGN.

However, these heuristics might be a lot more complicated that what we may
have anticipated, for the following non-exhaustive list of reasons:
- although HTTP is usually used with active/passive TCP socket pairs
(client/server), nothing prevents it from being used in a P2P context with
TCP simultaneous open. This is already being seen in the wild.
- port numbers do not give any information about the upper-layer protocol,
at most they can provide some heuristics. We know that P2P applications
*love* to impersonate well-known ports to bypass firewall policies. For
example, Skype *always* binds on 80 or 443 if it sees you have UPnP
activated in your gateway
- DPI doesn't prove to be a much help either for our heuristics: for
instance, Skype simulate an HTTP or SSL handshake on ports 80 or 443. The
reason, again, is to bypass intermediate firewall policies.


On the other hand, in the following use case, EDM is perfectly acceptable:
a TCP SYN is sent by a client behind a NAT, and the destination appears to
be a well-known HTTP server belonging to Google, Facebook, etc.
As this use case represents a sizeable amount of the current internet
traffic, I would definitely mention this in an RFC. A CGN would simply
need
to carry a static, updatable list of ip addresses ranges of well-known
popular HTTP servers, to allow fallback on EDM when desired.



> 
> Simon
> _______________________________________________
> Behave mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/behave




-- 
_Ivan Chollet_