Re: [BEHAVE] REQ 1 and REQ 7 of RFC5382 were supposed to be fixed years ago
ivan c <ivan@cacaoweb.org> Tue, 18 June 2013 16:56 UTC
Return-Path: <ivan@cacaoweb.org>
X-Original-To: behave@ietfa.amsl.com
Delivered-To: behave@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix)
with ESMTP id AB13421F9AAE for <behave@ietfa.amsl.com>;
Tue, 18 Jun 2013 09:56:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.514
X-Spam-Level:
X-Spam-Status: No, score=-2.514 tagged_above=-999 required=5 tests=[AWL=0.085,
BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com
[127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aO249KJ0nTcf for
<behave@ietfa.amsl.com>; Tue, 18 Jun 2013 09:56:20 -0700 (PDT)
Received: from mail.cacaoweb.org (mail.cacaoweb.org [46.105.102.78]) by
ietfa.amsl.com (Postfix) with ESMTP id 390C021F972E for <behave@ietf.org>;
Tue, 18 Jun 2013 09:56:16 -0700 (PDT)
Received: from www-data by mail.cacaoweb.org with local (Exim 4.72)
(envelope-from <ivan@cacaoweb.org>) id 1UozDP-00058K-DX for behave@ietf.org;
Tue, 18 Jun 2013 18:57:07 +0200
To: Behave <behave@ietf.org>
X-PHP-Originating-Script: 0:func.inc
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Date: Tue, 18 Jun 2013 18:57:07 +0200
From: ivan c <ivan@cacaoweb.org>
Organization: cacaoweb
In-Reply-To: <51C014BD.8070008@viagenie.ca>
References: <e652e4eda1b80ef8507455034552e0eb@cacaoweb.org>
<51BF2333.2010700@viagenie.ca>
<e7266646e10dc08c085da97d57717f46@cacaoweb.org>
<51C014BD.8070008@viagenie.ca>
Message-ID: <b92b6f405592a22c37f6a38dfbc50a38@cacaoweb.org>
X-Sender: ivan@cacaoweb.org
User-Agent: RoundCube Webmail/0.3.1
Subject: Re: [BEHAVE] REQ 1 and REQ 7 of RFC5382 were supposed to be fixed
years ago
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: ivan@cacaoweb.org
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/behave>,
<mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/behave>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>,
<mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Jun 2013 16:56:24 -0000
Hi Simon, See my comments interleaved. On Tue, 18 Jun 2013 10:05:17 +0200, Simon Perreault <simon.perreault@viagenie.ca> 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 > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave -- _Ivan Chollet_
- [BEHAVE] REQ 1 and REQ 7 of RFC5382 were supposed… ivan c
- Re: [BEHAVE] REQ 1 and REQ 7 of RFC5382 were supp… Simon Perreault
- Re: [BEHAVE] REQ 1 and REQ 7 of RFC5382 were supp… ivan c
- Re: [BEHAVE] REQ 1 and REQ 7 of RFC5382 were supp… Simon Perreault
- Re: [BEHAVE] REQ 1 and REQ 7 of RFC5382 were supp… Senthil Sivakumar (ssenthil)
- Re: [BEHAVE] REQ 1 and REQ 7 of RFC5382 were supp… ivan c
- Re: [BEHAVE] (no subject) ivan c
- Re: [BEHAVE] (no subject) Senthil Sivakumar (ssenthil)
- Re: [BEHAVE] (no subject) ivan c
- Re: [BEHAVE] (no subject) Rajiv Asati (rajiva)
- Re: [BEHAVE] (no subject) ivan c
- Re: [BEHAVE] (no subject) Simon Perreault
- Re: [BEHAVE] (no subject) Senthil Sivakumar (ssenthil)
- Re: [BEHAVE] (no subject) Dan Wing
- Re: [BEHAVE] (no subject) Dan Wing
- Re: [BEHAVE] (no subject) ivan c
- Re: [BEHAVE] TCP port overloading, preservation a… ivan c
- Re: [BEHAVE] (no subject) ivan c
- Re: [BEHAVE] (no subject) Simon Perreault
- Re: [BEHAVE] TCP port overloading, preservation a… Simon Perreault
- Re: [BEHAVE] (no subject) ivan c
- Re: [BEHAVE] (no subject) ivan c
- Re: [BEHAVE] TCP port overloading, preservation a… ivan c
- Re: [BEHAVE] (no subject) Simon Perreault
- Re: [BEHAVE] TCP port overloading, preservation a… Simon Perreault
- Re: [BEHAVE] (no subject) ivan c
- Re: [BEHAVE] (no subject) cb.list6
- Re: [BEHAVE] (no subject) Simon Perreault
- Re: [BEHAVE] (no subject) Simon Perreault
- Re: [BEHAVE] (no subject) Reinaldo Penno (repenno)
- Re: [BEHAVE] (no subject) ivan c
- Re: [BEHAVE] (no subject) Simon Perreault
- Re: [BEHAVE] (no subject) ivan c
- Re: [BEHAVE] (no subject) ivan c
- Re: [BEHAVE] (no subject) Simon Perreault
- Re: [BEHAVE] (no subject) Simon Perreault
- Re: [BEHAVE] (no subject) Mark Andrews
- Re: [BEHAVE] (no subject) ivan c
- [BEHAVE] DNS vs port overloading Simon Perreault
- Re: [BEHAVE] (no subject) ietfdbh
- Re: [BEHAVE] (no subject) Simon Perreault
- Re: [BEHAVE] DNS vs port overloading Mark Andrews
- Re: [BEHAVE] DNS vs port overloading Simon Perreault
- Re: [BEHAVE] (no subject) ivan c
- Re: [BEHAVE] (no subject) Simon Perreault
- Re: [BEHAVE] (no subject) ivan c
- Re: [BEHAVE] (no subject) Tom Taylor
- Re: [BEHAVE] (no subject) Simon Perreault
- Re: [BEHAVE] (no subject) ivan c
- Re: [BEHAVE] (no subject) ivan c
- Re: [BEHAVE] DNS vs port overloading Mark Andrews
- Re: [BEHAVE] (no subject) ivan c
- Re: [BEHAVE] (no subject) Simon Perreault
- Re: [BEHAVE] DNS vs port overloading Simon Perreault
- [BEHAVE] UDP socket programming Simon Perreault
- Re: [BEHAVE] TCP port overloading, preservation a… ivan c
- Re: [BEHAVE] DNS vs port overloading ivan c