gmane.ietf.nat.behave

Re: (no subject)

Senthil Sivakumar (ssenthil — 2013-06-19T14:38:12

Hi Ivan,

On 6/18/13 4:33 PM, "ivan c" <ivan< at >cacaoweb.org> wrote:


I have reviewed this draft and we had a bit of discussion around these
topics in the last IETF.

Ok thanks for the pointers. The NATs that I was talking about were
enterprise/SP NAT boxes,
not the home routers. Many of the CGN implementations don¹t do port
preservation. 



There are two distinct things here:
1. Port preservation is a must
2. Port preservation requires port overloading to work deterministically.

I don¹t have a lot of problem with an implementation choosing to do port
preservation if it can.
I do have issues with doing port overloading. Two reasons again.
1. Port overloading requires the destination information to be tracked by
NAT devices. That kills scalability.
2. Port overloading causes packets to be dropped if two connections going
to the same destination, causing indeterministic behavior.
   
Maybe as Rajiv suggested in another thread, maybe we need a CPE NAT
requirements document where the above requirement might be

Re: (no subject)

Simon Perreault — 2013-06-19T08:13:14

Le 2013-06-18 22:33, ivan c a écrit :

Please explain how TCP is not subject to the same problem.

Simon
_______________________________________________
Behave mailing list
Behave< at >ietf.org
https://www.ietf.org/mailman/listinfo/behave

Re: (no subject)

ivan c — 2013-06-18T22:05:04

On Tue, 18 Jun 2013 20:57:20 +0000, "Rajiv Asati (rajiva)"
<rajiva< at >cisco.com> wrote:
from
ourselves

Indeed, hopefully our new work in draft-ietf-behave-requirements-update-00
will help defining in what extent the requirements for both use cases (CGN
versus home gateways) might diverge.
We need to make each requirement's justification very clear and detailed,
so implementers can make informed decisions based on the intended usage.

Re: [v6ops] Home NAPT44 - How many ports?

ivan c — 2013-06-18T21:56:04

On Tue, 18 Jun 2013 20:24:55 +0000, "Rajiv Asati (rajiva)"
<rajiva< at >cisco.com> wrote:

(and
http://www.cisco.com/en/US/solutions/collateral/ns341/ns525/ns537/ns705/ns827/images/VNI_Hyperconnectivity_WP-12.jpg
http://www.michaelsinsight.com/2009/10/sandvine-traffic-study-confirms-the-decline-of-p2p.html

Interesting links. I wish we had access to more studies like the third
one.
However these documents seem to refer to the situation in North America,
who has Netflix, Hulu, Youtube, and is back in 2009. Apparently after the
Megavideo debacle in 2011, there was a significant drop of traffic towards
video streaming services.

It is difficult to get information about internet usage per
continent/countries.
Europe: Netflix and Hulu are not available. Netflix actually just came to
the UK. They make a large chunk of the US traffic. Youtube is heavily
throttled in France. From studies done by Orange, P2P still seems the
dominant usage.
China: P2P live streaming appears to be massively used.
Japan, India, South America

Re: (no subject)

Rajiv Asati (rajiva — 2013-06-18T20:57:20

It seems worthwhile to differentiate home router NAT implementations from enterprise/SP router NAT implementations. And the question to ask ourselves is whether we need a common set of requirements for both scenarios !!

Cheers,
Rajiv


_______________________________________________
Behave mailing list
Behave< at >ietf.org
https://www.ietf.org/mailman/listinfo/behave

Re: (no subject)

ivan c — 2013-06-18T20:33:22

Hi Senthil,

Thanks for your message. You might want to read
http://tools.ietf.org/html/draft-ietf-behave-requirements-update-00 
It features the list of updates to the existing RFC, adapted to new usage
contexts such as CGNs, mobile networks, etc.


On Tue, 18 Jun 2013 19:24:50 +0000, "Senthil Sivakumar (ssenthil)"


The discussion here is not about UDP. UDP port preservation should
generally not be implemented by NATs, as it could generate conflicts when 2
internal hosts using the same local port, each with a session to the same
endpoint. This would break end-to-end connectivity in rare cases, as there
is no fallback mechanism (as opposed to TCP).

To be clear, the requirements are as follows:
* NAT SHOULD NOT use UDP port preservation
* NAT SHOULD use TCP port preservation

Here are some NATs that have been tested and implement TCP port
preservation:
in the UK:
BT (British Telecom) (house-made gateway) - number 1 provider
Virgin (house-made gateway) - number 2 provider
Sky (Sagemcom) - number 3 provider

Re: [v6ops] Home NAPT44 - How many ports?

Rajiv Asati (rajiva — 2013-06-18T20:24:55

It is not. I agree. 
It is meant to be just a sample (as I stated in my very first email).



Indeed. Something is better than nothing. 


Interesting enough, many of the recent measurements suggest that the torrent' like p2p applications are no longer the bandwidth consumers the way they once used to be. In fact, they are now perceived to be 10-20% (and declining) of internet bandwidth. The largest internet world traffic consumer is HTTP (and HTTP video).

http://www.cisco.com/en/US/solutions/collateral/ns341/ns525/ns537/ns705/ns827/images/VNI_Hyperconnectivity_WP-12.jpg

http://www.michaelsinsight.com/2009/10/sandvine-traffic-study-confirms-the-decline-of-p2p.html

http://www.research.att.com/export/sites/att_labs/techdocs/TD_100193.pdf


Nonetheless, I do think about the number of ports that these p2p applications can consume/exhaust, since that could be in 100s (or in 1000s). Thankfully, many home router implementations may provide capabilities to restrict the exhaustion by the p2p apps.


I hope so. Ha

Re: (no subject)

Senthil Sivakumar (ssenthil — 2013-06-18T19:24:50

Hi Ivan,

On 6/18/13 1:10 PM, "ivan c" <ivan< at >cacaoweb.org> wrote:


Both TCP & UDP. The latest implementation in some router families is not
to have port preservation
(for both TCP & UDP).


Most of the NATs that I know don’t do port overloading any more.
RFC 5382 also says,
REQ-7:  A NAT MUST NOT have a "Port assignment" behavior of "Port
      overloading" for TCP.


Thanks
Senthil

_______________________________________________
Behave mailing list
Behave< at >ietf.org
https://www.ietf.org/mailman/listinfo/behave

p2p applications using STUNT and EIM NATs for TCP

ivan c — 2013-06-18T17:25:37


Hello, 

Does any of you has examples of applications that use a STUNT
server together with an EIM NAT for TCP? 

This is the single purpose
(besides the convenience of the implementation) of having an EIM NAT in the
first place: performing port prediction with the help of a STUNT server.
Surprisingly, I am not aware of any applications that rely on that. All the
p2p applications that I know of use different techniques for TCP Hole
Punching or use other alternatives, such as UPnP, port forwarding, etc.


It would be important to somewhat quantify the usage of this technique in
the wild.

Re: (no subject)

ivan c — 2013-06-18T17:10:56

Hi Senthil,

See my comments below.

On Tue, 18 Jun 2013 16:16:33 +0000, "Senthil Sivakumar (ssenthil)"
<ssenthil< at >cisco.com> wrote:

any
that
the
also

Are you talking about UDP port preservation? I think we all agree UDP port
preservation is not necessary, as long as the NAT is EIM for UDP.
About TCP port preservation, most NAT implementations have it. In some
countries (like France), all ISP-provided gateways have it.
As you note, TCP port preservation improves latency and thus performance,
when compared to the alternative of using a STUNT server.
It does not need the intermediate step of contacting the STUNT server to
perform TCP port prediction.



Nope, you would need to elaborate on this.
The probability that of an internal port collision is high because of the
birthday paradox, but port overloading is perfectly acceptable, and when a
full collision occurs (when internal ports and remote endpoints are the
same for two outgoing TCP connections), which is supposed to be a rare
event, the CGN can fallback

Re: REQ 1 and REQ 7 of RFC5382 were supposed to be fixedyears ago

ivan c — 2013-06-18T16:57:07

Hi Simon,

See my comments interleaved.

On Tue, 18 Jun 2013 10:05:17 +0200, Simon Perreault
<simon.perreault< at >viagenie.ca> wrote:


(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 appeali

Re: review of draft-penno-behave-rfc4787-5382-5508-bis

ivan c — 2013-06-18T16:50:48

Hi Kengo, 

See my answers interleaved below.

On Tue, 18 Jun 2013 13:56:54 +0900, Kengo Naito  wrote:   


3.1.2.1 will be most definitely frowned upon. Before suggesting such
alternative, the benefits need to be quantified in terms of CGN resources
usage. Is the TIME_WAIT state really that much of an issue for CGN resource
utilization? It looks to me as a micro-optimization. Of course, this can
still be suggested as a MAY in the document (as it's an interesting idea).

3.1.2.2 I was unable to fully grasp the idea and its relationship with the
TIME_WAIT state, it would be nice if you could elaborate on this.

3.1.2.3 you're mangling with the TCP protocol itself, which is arguably
even more intrusive than mangling with so fields in the TCP header like in
3.1.2.1

3.1.2.4 I don't think that RFC6191 is widely deployed, do you have any
reference for this?


the


There are a few issues with the section 4. of the draft.

Quoting: "This document clarifies that this port
   overlapping behavior can be extended to

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

Senthil Sivakumar (ssenthil — 2013-06-18T16:16:33


On 6/18/13 4:05 AM, "Simon Perreault" <simon.perreault< at >viagenie.ca> wrote:


I just want to add that I did a port preservation implementation a while
ago, but realized that the number of times that the ports couldn¹t be
preserved were getting more and more. Even though this wasn't causing any
application behavior issues, the customers were complaining because they
construed that as NAT not working properly, (whether their assumption that
is right or wrong is a different discussion), so we ended up not using the
port preservation as a default behavior in later implementations. It also
improves the performance.



Exactly, with the allocation of port sets in CGN, it becomes very
difficult to do any kind of port preservation.


For allowing EDM, one has to know their applications they are using, but
as you say port 80 can work well with EDM.

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

Simon Perreault — 2013-06-18T08:05:17

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.

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

- 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,

Re: review of draft-penno-behave-rfc4787-5382-5508-bis

Kengo Naito — 2013-06-18T04:56:54

Hi Ivan,

Thank you for the review of our draft.
Please see my comments inline,

(2013/06/17 4:14), ivan c wrote:
Then, how about using 3.1.2.2 ? This alternative do not rewrite 
timestamps nor ISNs.
Also, I do not intend to make 3.1.2.1 "must", this is only one of 
alternatives.

In the draft, I meant that Port overlapping behavior can only be used 
when the 5-tupple of connections are different.
So I think it is a bit different from overlapping behavior you wrote.
Does this behavior cause any bad effect?

Thanks for pointing, I should find the English page, and rewrite in next 
version of the draft.

FW: New Version Notification fordraft-reddy-behave-turn-auth-02.txt

Ram Mohan R (rmohanr — 2013-06-18T04:53:32

We have published the revision of this draft. This has changes to
following text of "Problems with STUN Authentication" section

<snip>
5.  Hosting multiple realms on a single IP address is challenging
       with TURN.  When a TURN server needs to send the REALM attribute
       in response to an unauthenticated request, it has no useful
       information for determining which realm it should send, except
       the source transport address of the TURN request.  Note this is a
       problem with multi-tenant scenarios only.  This is not a problem
       when deployed in Enterprise.


</snip>

Please review and provide any inputs/comments on this draft.

Authors

Re: REQ 1 and REQ 7 of RFC5382 were supposed to be fixedyears ago

ivan c — 2013-06-18T02:21:55

Hi Simon,

You will find my explanations to your 4 questions interleaved below.

First of all, a word about the context considered in this discussion: 
We have peers, all behind NATs, attempting to connect to each other via
TCP simultaneous open (TCP simultaneous open being described in TCP RFC793
Section 3.4 Figure 8).
The first step is for these peers to discover or guess what each other's
remote external endpoint will be for the TCP connection. This step is
called
"remote external endpoint prediction" or informally "port prediction" (as
the hard part is to predict the external port, as created by the NAT).
Once
external mapping have been negotiated/discovered, this information is
shared amongst the peers over some arbitrary out-of-band communication
channel. 
The second step consists in performing the actual TCP simultaneous open
to the relevant endpoint.

These steps constitute the TCP Hole Punching process, it can be used for
NAT Traversal.


On Mon, 17 Jun 2013 16:54:43 +0200, Simon Perreault
<simon.pe

BEHAVE presentations for IETF78 (Berlin)

Dan Wing — 2013-06-17T23:50:22

If you want to present at the BEHAVE meeting at IETF78 (Berlin), please send email to behave-chairs< at >tools.ietf.org with:

* name of presenter
* minutes
* internet draft filename(s)
* reason to present (e.g., education, resolve mailing list disagreement on certain point)

Preference will be given to working group milestone items, and then (time permitting) drafts which have received significant discussion on the list.  We requested a 1.5 hour slot and expect to have presentations on SYSLOG NAT logging, IPFIX NAT logging, the NAT MIB, and NAT requirements update.

-d

Re: [v6ops] Home NAPT44 - How many ports?

Benedikt Stockebrand — 2013-06-17T10:46:20

Hi Dan and lists,

Dan Wing <dwing< at >cisco.com> writes:


...or make an emergency phone call using SIP---which currently spooks
triple play providers at least here in Germany, not only because it is
bad press but disrupting emergency calls is in some cases considered a
criminal offense here.

Otherwise, in November I saw a presentation by Alain Fiocco (also Cisco)
pointing out that a single Bittorrent client already needs about 700
simultaneous connections.


Cheers,

    Benedikt

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

Simon Perreault — 2013-06-17T14:54:43

Le 2013-06-17 15:15, ivan c a écrit :

I would argue that port preservation is useless for traversal.


I don't see how EIM can be used for port prediction.


In your opinion, what is it about TCP that makes EDM OK?


Please explain.

Simon

Re: review of draft-penno-behave-rfc4787-5382-5508-bis

Reinaldo Penno (repenno — 2013-06-17T13:26:50

Hi Ivan,

Thanks for the detailed review of the draft. You might want to reference the newer version at  http://tools.ietf.org/html/draft-ietf-behave-requirements-update-00

I'm going through your comments and will start a discussion shortly.

Thanks,

Reinaldo

From: ivan c <ivan< at >cacaoweb.org<mailto:ivan< at >cacaoweb.org>>
Organization: cacaoweb
Reply-To: <ivan< at >cacaoweb.org<mailto:ivan< at >cacaoweb.org>>
Date: Sun, 16 Jun 2013 21:14:16 +0200
To: <behave< at >ietf.org<mailto:behave< at >ietf.org>>
Subject: [BEHAVE] review of draft-penno-behave-rfc4787-5382-5508-bis


Hello,

This is my review of draft-penno-behave-rfc4787-5382-5508-bis<http://www.ietf.org/mail-archive/web/behave/current/msg10831.html>, which is indeed a step in the right direction and corrects omissions and unspecified behaviors left by previous documents. I support its adoption as a working group document.





* 3.1.2.1. Rewrite timestamp and sequence number values at NAT

Requiring NATs to rewrite timestamps and ISNs seems overkill. Generally, mangling wit