Subject: [BEHAVE] Ad comments on draft-ietf-behave-p2p-state-03

From: Magnus Westerlund <[email-masked]>
Date: Tue, 04 Sep 2007 13:18:46 +0200

Hi,

I have done my AD review of this document and have the below comments.
If you don't agree with them, please discuss them with me.

1. Section 1, page 3, first paragraph:
"These issues are
   likely to persist even into the IPv6 world, where a NAT may be used
   as an IPv4 compatibility mechanism [NAT-PT]."

I think you should rewrite this considering that NAT-PT was deprecated.

2. Section 1, page 3, second paragraph:

"The
   anonymity and inaccessibility of the internal hosts behind a NAT
   device is not a problem for applications such as web browsers, which
   only need to initiate outgoing connections. This inaccessibility is
   sometimes perceived as a privacy benefit."

Is really "privacy" the main benefit. Isn't it the filtering behavior of
the NAT that blocks incoming requests and thus avoid getting the traffic
onto your local network that people like, i.e. the "firewalling" aspect
of NATs.

3. Section 1, page 3, second to last paragraph:

"  NAT traversal strategies that involve explicit signaling between
   applications and  NAT devices, namely [NAT-PMP], [NSIS-NSLP],
   [SOCKS], [RSIP], [MIDCOM], and [UPNP] are out of the scope of this
   document. [UNSAF] is in scope."

I agree that these are not in scope, but I think there should be some
mention that these techiques if available are a complement to the
techniques mentioned, allowing a client behind a NAT behave as if it was
having a public IP address, or at least an NAT external address.

4. Section 2, first paragraph:
"As
   for the notation for ports usage, all clients use ports in the
   range of 1-1000 and servers use ports in the range of
   20000-21000. NAT devices use ports 30000 and above for endpoint
   mapping."

I think there are an error in this description. To me it appears that
clients are using addresses in the range 1025-2000 in the examples.

5. Section 2.7:

  "A P2P application is an application that uses the same endpoint to
   initiate outgoing sessions to peering hosts as well as accept
   incoming sessions from peering hosts."

Considering the definition of "endpoint" in this document I don't think
this definition is characteristic for peer to peer applications. An peer
to peer application clearly can use different address and ports to
communicate with other peers.

6. Section 2.8:
"  A NAT-friendly P2P application registers with a publicly
   addressable rendezvous server, used for registration and peer
   discovery purposes. Pursuant to registering with rendezvous
   server, the application uses its private endpoint, public
   endpoint, or a combination thereof to establish peering sessions."

I don't think this is a strict requierment for a NAT-friendly P2P
application. It is rather an effect of being one of the simplest way of
accomplishing the rendezvous between two peers.

7. Section 2.9. I think one should be explicit that an EIM-NAT can have
any filtering behavior.

8. Section 3.1, last paragraph:

  "The obvious disadvantages of
   relaying are that it consumes the server's processing power and
   network bandwidth, and communication latency between the peering
   clients is likely to be increased even if the server is
   well-connected."

I think "well-connected" is the wrong word here. I think it is rather
topology wise correctly located.

9. Section 3.1, last paragraph:

"The TURN protocol [TURN] defines a method of
   implementing relaying in a relatively secure fashion."

I think there should be some expansion on what type of relay service
that TURN provides. For certain relay services a more application aware
relay may be the better choice rather then packet payload relaying.

10. Section 3.2, page 10:

"In the first case, traffic directed to IP address
   10.0.0.1 will simply be dropped by the network because 10.0.0.1 is
   not a publicly routable IP address."

I think, this sentence needs to be expanded to cover the issue that the
traffic might hit another host and any application listening on this port.

11. Section 3.3 or 3.3.1:

Somewhere here there need to be a description on why this fails with non
EIM-NATs.

12. Section 3.3.1:

"The application does
   not need to attempt to detect the kind of NAT device it is behind,
   as in [STUN], since the procedure above will establish peer-to-peer
   communication channels equally well if either or both clients do not
   happen to be behind a NAT device."

Well, in most usages of STUN you don't need to detect the bevior of the
NAT. I assume that you refer to the model of  using STUN to find the
external address and port and then advertise it. Not knowing the bevior
of the NAT only results in one knowing if it works or not. I think the
wording is a bit missfortunate, as it seems to say that STUN is really
bad, when it is only a specific usage that is problematic.

13. Section 3.3.2, Figure 4:

I think the example is strange. What I can see if A and B sends its
request starting with Registry, then try1 and then try2, try1 should
succed. Also these messages are not well connected to the text. I think
you should swap the order and then reference them a bit better in the text.

14. Section 3.3.2, last paragraph:
  "[ICE] protocol employs this technique effectively, in that
   multiple candidate endpoints (both private and public) are
   communicated between peering end hosts during offer/response
   exchange."

I think you should use either offer/answer or request/response, not mix it.

15. section 5.1, second paragraph:

"When the NAT device
   enroute is not EIM-NAT, the application is unable to reuse an
   already established endpoint mapping for communication with
   different external destinations and the technique would fail."

I think "enroute" is the wrong word. It is the outermost NAT that isn't
an EIM-NAT for it to matter.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM/M
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

_______________________________________________
Behave mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/behave

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Tue, 4 Sep 2007 15:28:13 +0300

> I think you should rewrite this considering that NAT-PT was deprecated.

I suppose some of "these issues" would still apply in presence of stateful 
firewall, which almost everybody in Chicago seemed to agree would be rampant 
in IPv6. I agree that the use of NAT-PT as an illustration is unfortunate 
though.

> onto your local network that people like, i.e. the "firewalling" aspect

Agreed (though I would argue that a NAT by itself does NOT block incoming 
requests - especially if it supports source route).

(...)
> an EIM-NAT for it to matter.

I think any non-EIM NAT en-route would break, not only the outermost one.

-- 
Rémi Denis-Courmont

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 04 Sep 2007 15:45:46 +0200

> in IPv6. I agree that the use of NAT-PT as an illustration is unfortunate 

Yes, I am not disputing the general motivation. It was simply that some
other formulation should be found that not uses NAT-PT as the reference.

> requests - especially if it supports source route).

Well, it is probably a matter of how you look on things. A NAT do not
translate and forward incomming packets unless there exist some mapping
for that port. Thus it has some blocking feature in that regards. Then
address and port dependent filtering may further prevent packets from
being forwarded to the internal side.

> I think any non-EIM NAT en-route would break, not only the outermost one.

Yes, you I think you are correct. Forgot about the issue with a inner
NAT which has address dependent mapping resulting in that the outer EIM-
NAT still ends up mapping two different flows onto different mappings.

Cheers

Magnus Westerlund

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Tue, 4 Sep 2007 16:54:54 +0300

Opening a parenthesis here:

Le Tuesday 04 September 2007 16:45:46 ext Magnus Westerlund, vous avez écrit :
> >> Isn't it the filtering behavior of

Does it not? If a NAT receives a packet with an "internal" address as 
destination IP from its "WAN" interface, why would it not forward it to the 
inside? That's totally implementation dependant. NAT != stateful firewall.

There are two ways to trigger this case. Either you are on the same link-layer 
segment as the NAT WAN port, or you use source route. Surely that will not 
work all the time, but I would not rely on that to secure my network.

-- 
Rémi Denis-Courmont

---

From: Pyda Srisuresh <[email-masked]>
Date: Tue, 18 Sep 2007 06:47:58 -0700 (PDT)

Magnus,

Thank you for the review. Apologize for my delay in responding. Please see my
responses inline.

regards,
suresh

> I think you should rewrite this considering that NAT-PT was deprecated.
[suresh] Would the following work for you? I believe, there might be NAT-PT
deployments, even as [NAT-PT] is deprecated.

     These issues are 
     likely to persist even into the IPv6 world and in deployments 
     using [NAT-PT].

> onto your local network that people like, i.e. the "firewalling" aspect
[suresh] The internal hosts have private IP addresses, which outsiders have no
knowledge of. This anonymity of IP addressing is considered as privacy by many
folks. In addition, a host behind NAT is not accessible to outsiders, unless a
session is initiated from inside. This inaccessibility is also considered as
privacy by many folks. 

You might say, the filtering behavior of NATs provides inaccessibility to
internal hosts; and mapping behavior of NATs provides anonymity to intenral
hosts.

> having a public IP address, or at least an NAT external address.
[suresh] No problem. I could add a sentence to that effect.

> clients are using addresses in the range 1025-2000 in the examples.
[suresh] Good catch. I will reword the first sentence to say that clients use
ports in the raneg of 1-2000. Thanks.

> communicate with other peers.
[suresh] Magnus - Would it work for you if the definition is expanded to say
that a P2P application may use multiple endpoints for P2P communication?  The
primary characteristic of a P2P applictaion is that the same endpoint is used
for initiating an outgoing connection as well to accept incoming connections.
All examples and deployment instances described in the document assume this
definition.

An application that uses one endpoint to receive incoming connections and a
different endpoint for outgoing connections is not a P2P application.

> accomplishing the rendezvous between two peers.
[suresh] Would the following rewording work for you? Thanks.

     One common way P2P applications establish peering sessions and 
     remain NAT friendly is by using a publicly addressable rendezvous
     server for registration and  peer discovery purposes.

> 7. Section 2.9. I think one should be explicit that an EIM-NAT can have
[suresh] Not a problem. That is the intent. I will state that explicitly.

> topology wise correctly located.
[suresh] By Well-connected, I was refering to having large bandwidth (say, in a
data center with GigE connectivity). This is required, as relay servers can be
in the path of many diverse, simultaneous sessions. The relay server ought to
have aggregate bandwidth to support the numerous parallel connections. I am not
refering to any topology-wise correctness.

> relay may be the better choice rather then packet payload relaying.
[suresh] I am referign to application agnostic, session specific packet relay
with TURN. I will state that explicitly.

> traffic might hit another host and any application listening on this port.

[suresh] In the specific example, the connection is initiated by a public
client. SO, there is no issue of private addresses beign in the same domain,
right?

> Somewhere here there need to be a description on why this fails with non

[suresh] OK, I will add description to that effect. When one of the hosts is
behind a NAT that is not EIM-NAT, the peering host cannot predictably know the
mapped endpoint to which to initiate connection. Further, the application on
the host behind non EIM-NAT would be unable to reuse an already established
endpoint mapping for communication with different external destinations and the
hole-punching technique would fail.

> bad, when it is only a specific usage that is problematic.

[suresh] I dont believe, the wording says that STUN is bad. If you like, I
could remove reference to [STUN] here.

> you should swap the order and then reference them a bit better in the text.

[suresh] You are right. Must have been a cut and paste error. I will swap the
try order in the diagram and reword accordingly. Thanks.

> I think you should use either offer/answer or request/response, not mix it.
[suresh] OK.

> an EIM-NAT for it to matter.
[suresh] As discussed with Remi on another thread, I believe, "enroute" is
proper usage here.

Thanks again, for your detailed comments. Once you are Ok with my responses, i
will go ahead and generate a new rev of the draft. 

regards,
suresh

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 19 Sep 2007 10:30:25 +0200

Hi,

See inline.

>      likely to persist even into the IPv6 world and in deployments 

Yes.

> internal hosts; and mapping behavior of NATs provides anonymity to intenral

I agree with NATs filtering behavior making hosts inaccessible in most
cases. But I don't they think they provide "privacy" in the meaning most
 people think about it. If I deploy a NAT in my home, it is still
possible to learn that what ever traffic was sent come from my home, but
maybe not which of the 5 computers in my home that sent it. But that I
don't call privacy. There are many aspects of privacy, maybe a more
precise description of what it really provides.

> [suresh] No problem. I could add a sentence to that effect.

Good

> ports in the raneg of 1-2000. Thanks.

ok.

> All examples and deployment instances described in the document assume this

I think that will resolve the main conflict in the definitions.

> different endpoint for outgoing connections is not a P2P application.

I don't think I agree with that characterisation. Isn't that a result of
the need for making NAT traversal work. My interpretation is more along
the following definition:

"Peer-to-peer is a communications model in which each party has the same
capabilities and either party can initiate a communication session."

>      server for registration and  peer discovery purposes.

Yes.

> refering to any topology-wise correctness.

Well, for "communication latency" the topologhy do matter. And clearly
it needs enough bandwidth to handle the number of clients it accept to
serve. However, that it necessirely to have very high bandwidth is in my
view wrong. One clearly can build a relaying system that builds on
whatever node that exist with a real public IP address. As long as one
keep the relaying bandwidth within what exist there should be no extra
delay due to lower bandwidth. The path latency will still be the major
issue.

> with TURN. I will state that explicitly.

Okay.

> client. SO, there is no issue of private addresses beign in the same domain,

Yes, my error.

> hole-punching technique would fail.

Good.

> could remove reference to [STUN] here.

I think removing the reference may be the best way of resolving this.

> try order in the diagram and reword accordingly. Thanks.

Ok.

> [suresh] As discussed with Remi on another thread, I believe, "enroute" is

I don't know which thread you are refering to. Well, enroute will not be
missunderstood. But isn't "on path" what is commonly used in this case.
But, this is really nit-picking. So lets ignore this.

Cheers

Magnus Westerlund

---

From: Pyda Srisuresh <[email-masked]>
Date: Wed, 19 Sep 2007 22:14:59 -0700 (PDT)

Magnus,

Please see my responses inline.

regards,
suresh

<... stuff deleted>

> precise description of what it really provides.

[suresh] As I said earlier, the privacy I am referign to is principally the
combination of private Ip address (anonymity) and inaccessibility from external
hosts. The mapping behavior of NATs provides anonymity and the filtering
behavior of NATs provides inaccessibility to internal hosts. Would the
following rewording work for you?

  "The
   anonymity (private IP addresses) and inaccessibility of the internal 
   hosts behind a NAT device is not a problem for applications such as
   web browsers, which only need to initiate outgoing connections. This
   anonymity and inaccessibility is sometimes perceived as a privacy
   benefit."

<... stuff deleted>

> I think that will resolve the main conflict in the definitions.
[suresh] Will do. 

> capabilities and either party can initiate a communication session."

[suresh] I see what you mean. However, the definition I provided is appropriate
for the document, I believe.

<... stuff deleted>

> delay due to lower bandwidth. The path latency will still be the major
[suresh] Would it it work for if I reworded this as follows? 

  "The obvious disadvantages of
   relaying are that it consumes the server's processing power and
   network bandwidth, and communication latency between the peering
   clients is likely to be increased even if the server has sufficient
   I/O bandwidth and is located correctly topology wise."

<.... stuff deleted>

> But, this is really nit-picking. So lets ignore this.
[suresh] I was refering to the e-mail exchange between you and Remi on this
item on 09/04/07.

Thank you for your comments.

regards,
suresh

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 20 Sep 2007 10:40:00 +0200

See inline

>    anonymity and inaccessibility is sometimes perceived as a privacy

I have some concerns about using "anonymity" in this context, because it
is mostly an illusion. In many deployements there are very few hosts
NATed behind a specific IP address (at least in sweden), thus NATs
provide with very little privacy or anonymity.

And this should be evident from how targeted commericals one do gets
even when websurfing behind a NAT. So I don't want to build on this. But
if you include the word "illusion of" prior to "anonymity" then I am fine.

> for the document, I believe.

Yes, that is okay, the basic issue was that conflict in the usage in
this case. So if you resolve that, then it is okay.

>    I/O bandwidth and is located correctly topology wise."

Yes, sound good.

> [suresh] I was refering to the e-mail exchange between you and Remi on this

Okay, I think that the focus of that discussion was my misstake in that
all NATs must be EIM-NATs, rather then if enroute or on path is the best
word. But both do work and I was being to nit picking.

Cheers

Magnus Westerlund

---

From: Pyda Srisuresh <[email-masked]>
Date: Thu, 20 Sep 2007 07:02:08 -0700 (PDT)

Magnus,

Thanks. I will bring out the next rev with your feedback folded in. 

regards,
suresh

--- Magnus Westerlund <[email-masked]> wrote:

> >>> [suresh] The internal hosts have private IP addresses, which outsiders
> have
> >> no
> >>> [suresh] By Well-connected, I was refering to having large bandwidth
> (say,
> >> in a
> >>> data center with GigE connectivity). This is required, as relay servers
> can
> >> be
> >>> in the path of many diverse, simultaneous sessions. The relay server
> ought
> >> to
> >>> have aggregate bandwidth to support the numerous parallel connections. I
> am
> >> not

---

From: james woodyatt <[email-masked]>
Date: Thu, 20 Sep 2007 11:46:39 -0700

>      likely to persist even into the IPv6 world and in deployments

It might also help to recognize that the IPv6 world will be plagued  
with stateful filtering firewalls with all the same basic filtering  
behaviors of NAT but without the address translation.  It's the  
filtering behavior more than anything else that interferes with P2P  
applications, and most of the considerations in this document apply  
for IPv6 as well as for IPv4/NAT.

--
james woodyatt <[email-masked]>
member of technical staff, communications engineering

---

From: james woodyatt <[email-masked]>
Date: Thu, 20 Sep 2007 15:24:01 -0700

On Sep 20, 2007, at 13:11, Michael Richardson wrote:
>
> Yes, but if you don't need any filtering, with IPv6, there is no  
> reason for your "router" to do anything other than routing.  That  
> eliminates *almost* all the situations where people are being  
> filtered in ways that they didn't ask for.

No, it does not.  Please see draft-ietf-v6ops-cpe-simple-security and  
the related discussion on V6OPS about the recommended deployment of  
stateful IPv6 packet filters by default in most consumer-grade  
routers.  These filters will be turned on in the factory default  
configuration, and in most cases will require uncommon networking  
expertise even to turn them off, much less customize them.  For all  
practical purposes, there will not be *ANY* situations where people  
are using IPv6 networks without being subjected to stateful filtering.

> Almost, because it doesn't get rid of wireless-cafe/hotel type  
> networks, where you are being filtered for payment reasons.
>
> However, in theory, "PANA" and "802.1x" are supposed to solve this  
> right?

Once again, the system works in theory, but how does it hold up in  
practice?

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 20 Sep 2007 15:57:22 -0700

As an individual, I suggest that there may be useful text in section 2 of
RFC3041 that could be incorporated into -behave-p2p-state around 'privacy'.

-d

> -----Original Message-----
> From: Pyda Srisuresh [mailto:[email-masked]] 
> Sent: Wednesday, September 19, 2007 10:15 PM
> To: Magnus Westerlund
> Cc: Bryan Ford; Behave WG; Dan Kegel
> Subject: [BEHAVE] Re: Ad comments on draft-ietf-behave-p2p-state-03
> 
> Magnus,
> 
> > > [suresh] The internal hosts have private IP addresses, 
> which outsiders have
> > no
> > > knowledge of. This anonymity of IP addressing is 
> considered as privacy by
> > many
> > > folks. In addition, a host behind NAT is not accessible 
> to outsiders,
> > unless a
> > > session is initiated from inside. This inaccessibility is 
> also considered
> > as
> > > privacy by many folks. 
> > > 
> > > [suresh] Magnus - Would it work for you if the definition 
> is expanded to
> > say
> > > that a P2P application may use multiple endpoints for P2P 
> communication? 
> > The
> > > primary characteristic of a P2P applictaion is that the 
> same endpoint is
> > used
> > > [suresh] By Well-connected, I was refering to having 
> large bandwidth (say,
> > in a
> > > data center with GigE connectivity). This is required, as 
> relay servers can
> > be
> > > in the path of many diverse, simultaneous sessions. The 
> relay server ought
> > to
> > > have aggregate bandwidth to support the numerous parallel 
> connections. I am
> > not

---

From: Pyda Srisuresh <[email-masked]>
Date: Thu, 20 Sep 2007 18:48:23 -0700 (PDT)

> for IPv6 as well as for IPv4/NAT.
[suresh] Agreed. I will include this text in the next rev of the draft. Thanks.

regards,
suresh

---

From: Pyda Srisuresh <[email-masked]>
Date: Thu, 20 Sep 2007 18:52:09 -0700 (PDT)

I will take a look. Thanks.

regards,
suresh

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 21 Sep 2007 10:59:04 +0200

> RFC3041 that could be incorporated into -behave-p2p-state around 'privacy'.

Yes, I think the information in Section 2.2 is very relevant to this
discussion and shows that SOHO nats really do not provide any "privacy"
feature, even if the general public may considered it providing something.

Cheers

Magnus Westerlund