Subject: [pcp] hoping to eliminate IMPLICIT_MAPPING_EXISTS

From: "Dan Wing" <[email-masked]>
Date: Mon, 14 Mar 2011 16:24:13 -0700

During Stuart Cheshire's review, he pointed out a potential issue with the
IMPLICIT_MAPPING_EXISTS error result code.

As a reminder, the IMPLICIT_MAPPING_EXISTS is returned if a MAP request
is received by the PCP server, and there is already an implicit dynamic
mapping from that same port, and the NAT cannot create a new mapping.

The problem he pointed out (which is what is discussed in pcp-base
already) is that this could be caused also by the previous owner of that 
IP address having a (lingering) dynamic mapping in the NAT, or because
of a dynamic mapping from this same client -- forcing the the server to
be moved from its perfectly-legitimate port (e.g., TCP/22, TCP/80) to
some other port.  This is really awkward, to say the least.

I certainly agree with him on that.  I don't like the 
IMPLICIT_MAPPING_EXISTS error at all.

I mean, consider if you have a server listening on port "Y", and it
is running just fine for a week while you're troubleshooting and
getting it working fine.  And then, when you want listening on
the Internet, you have to move it to port "F" because PCP said
port "Y" is being used by an ephemeral connection across the
NAT.  That's really awkward.

Thinking of ways to avoid this error, he came up with an idea:

  Instead of returning this error, the NAT simply create a 
  new mapping.

To do this, I believe this requires the NAT acquire some aspects of 
endpoint-dependent mapping.  Specifically, the NAT would need to continue to

use the existing external port for outgoing packets that are using the 
existing implicit dynamic mapping, and would need to use the new 
external port for other packets.  I believe this wouldn't be possible 
with a lot of NATs.    The way I model this on paper is that a TCP
SYN arrives from the Internet, hits the NAT and then hits the server, 
which generates a SYNACK, and that SYNACK needs to be NATted using
the same mapping as used by the inbound SYN.

More importantly than a thread of "that won't work", I am hoping
this will kindle some other ideas.

-d

---

From: Francis Dupont <[email-masked]>
Date: Tue, 15 Mar 2011 00:59:52 +0100

In your previous mail you wrote:

=> no, in such a case it has just to wait the conflicting
implicit mapping to expire. And BTW as you insist to associate
a lifetime to errors the client knows when it can retry.
BTW there is no responding application on the client side
so this timeout should be short (reseted TCP, etc).

=> ephemeral connections use ephemeral ports, and you already have
this awkwardness today, this is why you can set SO_REUSEADDR.

   
   To do this, I believe this requires the NAT acquire some aspects of
   endpoint-dependent mapping.

=> you ask something about NAT behavior...

=> the alternative to the error is awkward: it is to delete
the conflicting implicit dynamic mapping.
BTW this means PCP provides a way to delete any implicit dynamic
mapping...

Regards

[email-masked]

---

From: <[email-masked]>
Date: Tue, 22 Mar 2011 16:15:21 +0800

|
|During Stuart Cheshire's review, he pointed out a potential 
|issue with the IMPLICIT_MAPPING_EXISTS error result code.
|
|As a reminder, the IMPLICIT_MAPPING_EXISTS is returned if a 
|MAP request is received by the PCP server, and there is 
|already an implicit dynamic mapping from that same port, and 
|the NAT cannot create a new mapping.
|
|The problem he pointed out (which is what is discussed in pcp-base
|already) is that this could be caused also by the previous 
|owner of that IP address having a (lingering) dynamic mapping 
|in the NAT, or because of a dynamic mapping from this same 
|client -- forcing the the server to be moved from its 
|perfectly-legitimate port (e.g., TCP/22, TCP/80) to some other 
|port.  This is really awkward, to say the least.
|
|I certainly agree with him on that.  I don't like the 
|IMPLICIT_MAPPING_EXISTS error at all.
|
|I mean, consider if you have a server listening on port "Y", 
|and it is running just fine for a week while you're 
|troubleshooting and getting it working fine.  And then, when 
|you want listening on the Internet, you have to move it to 
|port "F" because PCP said port "Y" is being used by an 
|ephemeral connection across the NAT.  That's really awkward.
|
|
|Thinking of ways to avoid this error, he came up with an idea:
|
|  Instead of returning this error, the NAT simply create a
|  new mapping.

XH: If the NAT runs endpoint independent mapping, it can simply create
a new mapping and assign a new external port for the PCP request 
without impacting on the dynamic flow.

|
|To do this, I believe this requires the NAT acquire some 
|aspects of endpoint-dependent mapping.  Specifically, the NAT 
|would need to continue to
|
|use the existing external port for outgoing packets that are 
|using the existing implicit dynamic mapping, and would need to 
|use the new external port for other packets.  I believe this 
|wouldn't be possible 

XH: If the NAT runs endpoint dependent mapping,how could it create 
a new mapping with new external port without introducing ambiguity
to the existing implicit mapping?

|with a lot of NATs.    The way I model this on paper is that a TCP
|SYN arrives from the Internet, hits the NAT and then hits the 
|server, which generates a SYNACK, and that SYNACK needs to be 
|NATted using the same mapping as used by the inbound SYN.

XH: When NAT runs endpoint dependent mapping, It is possible to inform
the client to reuse the existing implicit dynamic mapping to expect
inbound sessions. It will work as long as the NAT does *not* run 
endpoint dependent filtering.

Thanks,
Xiaohong
opensource A+P: http://opensourceaplusp.weebly.com/

|
|
|More importantly than a thread of "that won't work", I am 
|hoping this will kindle some other ideas.
|
|-d
|
|
|
|

---

From: Stuart Cheshire <[email-masked]>
Date: Tue, 22 Mar 2011 16:55:48 -0700

> without impacting on the dynamic flow.

The problem is not the external port, it's the *internal* port.

The problem scenario is this:

1. Client runs sshd on port 22.
2. Client requests an external port from the NAT gateway.
3. NAT gateway returns "IMPLICIT_MAPPING_EXISTS", which means, "You can't listen on internal port 22. Reconfigure your machine to run sshd on a different internal port and then try again."

This seems like an error code that *no* client will bother to try to handle. And it's rare enough that they will usually get away with not handling it. So if it's implausible to expect clients to handle this then it's a mistake to have it in the protocol at all.

Right now today, on Mac (or Windows with Bonjour installed) if you have sshd listening on port 22, you can type "dns-sd -X tcp 22" in a terminal window and get an external port mapped. (If you have iTunes or Safari on your Windows machine, you already have this command.) What we're talking about is adding an error code that now says, "No, you can't use internal port 22 on your own machine."

Note that this problem will *only* happen on EDM NATs, in the very rare case where two internal hosts are "sharing" the same external port, and then one of them does a MAP request which would require "promoting" its existing outbound mapping to an in/out mapping (which can't be done because it can't get exclusive use of that external port).

For EIM NATs this *cannot* happen, because with EIM NAT two internal hosts cannot "share" the same external port in the first place, so there can never be a case where the NAT gateway is unable to "promote" an existing outbound mapping to an in/out mapping.

Stuart Cheshire <[email-masked]>
* Wizard Without Portfolio, Apple Inc.
* www.stuartcheshire.org

---

From: <[email-masked]>
Date: Wed, 23 Mar 2011 18:15:58 +0800

|On 22 Mar 2011, at 1:15, [email-masked] wrote:
|
|> XH: If the NAT runs endpoint independent mapping, it can 
|simply create 
|> a new mapping and assign a new external port for the PCP request 
|> without impacting on the dynamic flow.
|
|The problem is not the external port, it's the *internal* port.

I understood the problem is about the *internal* port.

|
|The problem scenario is this:
|
|1. Client runs sshd on port 22.
|2. Client requests an external port from the NAT gateway.
|3. NAT gateway returns "IMPLICIT_MAPPING_EXISTS", which means, 
|"You can't listen on internal port 22. Reconfigure your 
|machine to run sshd on a different internal port and then try again."
|
|This seems like an error code that *no* client will bother to 
|try to handle. And it's rare enough that they will usually get 
|away with not handling it. So if it's implausible to expect 
|clients to handle this then it's a mistake to have it in the 
|protocol at all.
|
|Right now today, on Mac (or Windows with Bonjour installed) if 
|you have sshd listening on port 22, you can type "dns-sd -X 
|tcp 22" in a terminal window and get an external port mapped. 
|(If you have iTunes or Safari on your Windows machine, you 
|already have this command.) What we're talking about is adding 
|an error code that now says, "No, you can't use internal port 
|22 on your own machine."

Understood.

|Note that this problem will *only* happen on EDM NATs, in the 
|very rare case where two internal hosts are "sharing" the same 
|external port, and then one of them does a MAP request which 
|would require "promoting" its existing outbound mapping to an 
|in/out mapping (which can't be done because it can't get 
|exclusive use of that external port).

What if *not* "promoting" its existing outbound mapping (keeping it) and
creating a
new in/out mapping on a new external port?

|For EIM NATs this *cannot* happen, because with EIM NAT two 
|internal hosts cannot "share" the same external port in the 
|first place, so there can never be a case where the NAT 
|gateway is unable to "promote" an existing outbound mapping to 
|an in/out mapping.

Not sure if "promote" an existing outbound mapping to an in/out mapping
will cause 
no problem to existing dynamic connections. Considering the exsiting
outbound mapping
has an endpoint dependent filtering policy, how to keep that work?

I was thinking that for EIM NAT (sorry, in the last mail when I wanted
to say EIM I said EDM),
if it is possible to inform the client to reuse the existing implicit
dynamic
mapping to expect inbound sessions, but it will  not work if NAT run
both EIM and EDF
(endpoint dependent filtering).

Thanks,
Xiaohong

|
|Stuart Cheshire <[email-masked]>
|* Wizard Without Portfolio, Apple Inc.
|* www.stuartcheshire.org
|
|

---

From: Francis Dupont <[email-masked]>
Date: Wed, 23 Mar 2011 13:52:37 +0100

=> note it is a design choice: you can either have a dedicated
error code for any error, including for corner cases, or have
a 'catch all error' which says 'it fails and you should retry
later'. Of course, you can add useful error cases later
even you'll never know if there will be properly handled...

   What if *not* "promoting" its existing outbound mapping (keeping it) and
   creating a new in/out mapping on a new external port?

=> raise another error ('not authorized' or 'unspecified').
As I said it is a design choice.

   
=> in an EIM NAT the promotion will remove the filter (in the case
there is one, i.e., not yet EIF).

Regards

---

From: Stuart Cheshire <[email-masked]>
Date: Wed, 23 Mar 2011 10:42:08 -0700

On 23 Mar 2011, at 3:15, [email-masked] wrote:

> Not sure if "promote" an existing outbound mapping to an in/out mapping will cause no problem to existing dynamic connections. Considering the exsiting outbound mapping has an endpoint dependent filtering policy, how to keep that work?

The concept makes no sense. The *point* of a MAP request is that the client is saying "Do no filtering for this port". It makes no sense to ask how you both filter and do not filter at the same time.

An outbound connection may be subject to filtering. A MAP request is how you tell the NAT gateway "don't do that."

---

From: Stuart Cheshire <[email-masked]>
Date: Wed, 23 Mar 2011 11:32:29 -0700

On 23 Mar 2011, at 5:52, Francis Dupont wrote:

> a 'catch all error' which says 'it fails and you should retry later'.

I'm not debating what error code to use when it fails.

I'm saying it shouldn't fail.

If a client makes a valid request to the NAT gateway, then the NAT gateway should do it, not randomly fail sometimes.

Every failure we throw back at the client is a burden on the PCP client software, and we should only do that when there's truly no alternative. Cases like NO_RESOURCES are valid because the NAT gateway can't magically make itself more memory. I don't believe that cases like IMPLICIT_MAPPING_EXISTS or NONEXIST_PEER should be thrown back for the client to deal with. The NAT gateway should just work out what is the right thing to do, and do it, without troubling the client.

At least in the case of NO_RESOURCES the user has some hope of understanding what it means (too many NAT mappings) and what to do to fix it (buy a new NAT gateway that has more memory and can support more mappings). What is the end user supposed to do to fix an IMPLICIT_MAPPING_EXISTS error?

---

From: <[email-masked]>
Date: Thu, 24 Mar 2011 19:58:02 +0800

|> Not sure if "promote" an existing outbound mapping to an 
|in/out mapping will cause no problem to existing dynamic 
|connections. Considering the exsiting outbound mapping has an 
|endpoint dependent filtering policy, how to keep that work?
|
|The concept makes no sense. The *point* of a MAP request is 
|that the client is saying "Do no filtering for this port". It 
|makes no sense to ask how you both filter and do not filter at 
|the same time.

It is certain that MAP request implies no filtering, But what I was
assuming is that existing outbound mapping was created by 
another app (not the one using PCP to request a MAP), which 
is using the same internal ip and internal port as the PCP one does.
Please correct me if I assumed wrong.

|An outbound connection may be subject to filtering. A MAP 
|request is how you tell the NAT gateway "don't do that."

It's ture if it's the same app and it wants to remove filtering. Still 
not sure if there is a security concern.

Thanks,
Xiaohong,

|

---

From: <[email-masked]>
Date: Thu, 24 Mar 2011 20:00:26 +0800

| In your previous mail you wrote:
|
|   |This seems like an error code that *no* client will bother to 
|   |try to handle. And it's rare enough that they will usually get 
|   |away with not handling it. So if it's implausible to expect 
|   |clients to handle this then it's a mistake to have it in the 
|   |protocol at all.
|
|=> note it is a design choice: you can either have a dedicated 
|error code for any error, including for corner cases, or have 
|a 'catch all error' which says 'it fails and you should retry 
|later'. Of course, you can add useful error cases later even 
|you'll never know if there will be properly handled...
|
|   |Note that this problem will *only* happen on EDM NATs, in the 
|   |very rare case where two internal hosts are "sharing" the same 
|   |external port, and then one of them does a MAP request which 
|   |would require "promoting" its existing outbound mapping to an 
|   |in/out mapping (which can't be done because it can't get 
|   |exclusive use of that external port).
|   
|   What if *not* "promoting" its existing outbound mapping 
|(keeping it) and
|   creating a new in/out mapping on a new external port?
|
|=> raise another error ('not authorized' or 'unspecified').
|As I said it is a design choice.

Would you please explain why 'not authorized'?

|   
|   |For EIM NATs this *cannot* happen, because with EIM NAT two 
|   |internal hosts cannot "share" the same external port in the 
|   |first place, so there can never be a case where the NAT 
|   |gateway is unable to "promote" an existing outbound mapping to 
|   |an in/out mapping.
|   
|   Not sure if "promote" an existing outbound mapping to an 
|in/out mapping
|   will cause 
|   no problem to existing dynamic connections. Considering the exsiting
|   outbound mapping
|   has an endpoint dependent filtering policy, how to keep that work?
|   
|=> in an EIM NAT the promotion will remove the filter (in the 
|case there is one, i.e., not yet EIF).

Isn't there a security concern?

Thanks,
Xiaohong

|
|Regards
|
[email-masked]
|

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 24 Mar 2011 08:10:54 -0700

> -----Original Message-----
> From: [email-masked] [mailto:xiaohong.deng@orange-
> ftgroup.com]
> Sent: Thursday, March 24, 2011 4:58 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: RE: [pcp] hoping to eliminate IMPLICIT_MAPPING_EXISTS
> 
> 

Let's take NAT and PCP out of the picture for the moment, and
consider the same two applications running on the same host you
are describing above.  One of those applications does an outgoing
connection to some server on the Internet, using a certain source
port.  The other application starts to listen on that same 
source port as the first application.  I don't see a security
concern -- the host operating system will pass unsolicited
incoming traffic (TCP connections, or UDP packets) to the
listening application, which will never be sent to the 
first application.  

Add NAT and PCP, and no new security concern is created.

-d

---

From: <[email-masked]>
Date: Fri, 25 Mar 2011 17:01:17 +0800

|> It's ture if it's the same app and it wants to remove 
|filtering. Still 
|> not sure if there is a security concern.
|
|Let's take NAT and PCP out of the picture for the moment, and 
|consider the same two applications running on the same host 
|you are describing above.  One of those applications does an 
|outgoing connection to some server on the Internet, using a 
|certain source port.  The other application starts to listen 
|on that same source port as the first application.  I don't 
|see a security concern -- the host operating system will pass 
|unsolicited incoming traffic (TCP connections, or UDP packets) 
|to the listening application, which will never be sent to the 
|first application.  

Yes, OS will differentiate apps.

|
|Add NAT and PCP, and no new security concern is created.

As filtering policies is usually applied on subscribers, it is decided
by deployment scenario. Consider the first app( does not run PCP) 
is under EDF policy because subscriber is under EDF, which may 
protect the app from attacking. We do note PCP app does not care 
filter policy,  but I wonder if it is reasonable that a PCP app 
has the right to remove filter policy for other apps. It looks like
lowering security policy for a subscriber. That's my concern.

Thanks,
Xiaohong

|
|-d
|
|
|> Thanks,
|> Xiaohong,
|> opensource A+P: http://opensourceaplusp.weebly.com/
|> 
|> 
|> |
|> |Stuart Cheshire <[email-masked]>
|> |* Wizard Without Portfolio, Apple Inc.
|> |* www.stuartcheshire.org
|> |
|> |
|
|

---

From: Francis Dupont <[email-masked]>
Date: Fri, 25 Mar 2011 14:10:56 +0100

=> so you want to restrict the way a NAT can be implemented?

BTW I don't really understand your logic: do you mean by removing
error codes you are removing error cases too?

Regards

---

From: Francis Dupont <[email-masked]>
Date: Fri, 25 Mar 2011 14:22:20 +0100

=> why not? BTW I prefer 'unspecified' as it doesn't suggest
a permanent error (as it suggests nothing at all :-).

   
=> it could be if it was not by an explicit client request.

Regards

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 25 Mar 2011 09:07:40 -0700

> Sent: Friday, March 25, 2011 2:01 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: RE:[pcp] hoping to eliminate IMPLICIT_MAPPING_EXISTS
> 
> protect the app from attacking.

If I understand correctly, you are suggesting that because there
is a NAT, the OS will completely abdicate its responsibilities.

My point is that the OS is still present, and the OS still
validates the incoming packets exactly as it does without a NAT.

Thus, the application which caused an implicit dynamic mapping
to be created in the NAT (e.g., by sending a TCP SYN) is _not_
at any additional or different risk if that port is modified
with MAP than today, where the application is not behind 
any sort of NAT at all.

-d

> We do note PCP app does not care

---

From: Stuart Cheshire <[email-masked]>
Date: Fri, 25 Mar 2011 15:54:52 -0700

> Please correct me if I assumed wrong.

Can you describe a scenario where two different applications could be using the same internal ip and internal port?

---

From: Francis Dupont <[email-masked]>
Date: Sat, 26 Mar 2011 16:52:13 +0100

Can you describe a scenario where two different applications could
   be using the same internal ip and internal port?
   
=> easy: two independent (poor) programmers peak the same port number
and try to run at the same time two applications:
 - the first one bind() the port number in order to be sure to use
  this port (I don't believe there are many good reasons to do that)
 - the second one is a service so set SO_REUSEADDR and bind() its
 service to the same port (note the "second" is important)
If you believe it is impossible just try to guess why BIND and UNBOUND
provides a configuration for the pool of UDP ports where they take
randomized ports.

I agree it is unlikely but it is not impossible.

Regards

---

From: <[email-masked]>
Date: Mon, 28 Mar 2011 20:12:12 +0800

|
|If I understand correctly, you are suggesting that because 
|there is a NAT, the OS will completely abdicate its responsibilities.
|
|My point is that the OS is still present, and the OS still 
|validates the incoming packets exactly as it does without a NAT.
|
|Thus, the application which caused an implicit dynamic mapping 
|to be created in the NAT (e.g., by sending a TCP SYN) is _not_ 
|at any additional or different risk if that port is modified 
|with MAP than today, where the application is not behind any 
|sort of NAT at all.

I'm not suggesting that  OS will abdicate its responsibilities.

My point is that if the MAP removes filter, the application that 
caused an implicit dynamic mapping is likely to receive 
unwanted (destined to this app instead of PCP client app but still 
unwanted) inbound packets.

|
|-d
|
|> We do note PCP app does not care
|> filter policy,  but I wonder if it is reasonable that a PCP app has 
|> the right to remove filter policy for other apps. It looks like 
|> lowering security policy for a subscriber. That's my concern.
|> 
|> Thanks,
|> Xiaohong
|> opensource A+P: http://opensourceaplusp.weebly.com/
|> 
|> 
|> |
|> |-d
|> |
|> |
|> |> Thanks,
|> |> Xiaohong,
|> |> opensource A+P: http://opensourceaplusp.weebly.com/
|> |>
|> |>
|> |> |
|> |> |Stuart Cheshire <[email-masked]>
|> |> |* Wizard Without Portfolio, Apple Inc.
|> |> |* www.stuartcheshire.org
|> |> |
|> |> |
|> |
|> |
|
|

---

From: <[email-masked]>
Date: Mon, 28 Mar 2011 20:13:19 +0800

| In your previous mail you wrote:
|
|   |=> raise another error ('not authorized' or 'unspecified').
|   |As I said it is a design choice.
|   
|   Would you please explain why 'not authorized'?
|   
|=> why not? BTW I prefer 'unspecified' as it doesn't suggest a 
|permanent error (as it suggests nothing at all :-).
|
|   |=> in an EIM NAT the promotion will remove the filter (in the
|   |case there is one, i.e., not yet EIF).
|   
|   Isn't there a security concern?
|   
|=> it could be if it was not by an explicit client request.

Yes, that's what I concerned.

|
|Regards
|

---

From: <[email-masked]>
Date: Mon, 28 Mar 2011 20:14:57 +0800

| In your previous mail you wrote:
|
|   Can you describe a scenario where two different applications could
|   be using the same internal ip and internal port?
|   
|=> easy: two independent (poor) programmers peak the same port 
|number and try to run at the same time two applications:
| - the first one bind() the port number in order to be sure to use
|  this port (I don't believe there are many good reasons to do that)
| - the second one is a service so set SO_REUSEADDR and bind() 
|its  service to the same port (note the "second" is important) 
|If you believe it is impossible just try to guess why BIND and 
|UNBOUND provides a configuration for the pool of UDP ports 
|where they take randomized ports.
|
|I agree it is unlikely but it is not impossible.

Exactly.

BR,
Xiaohong

|
|Regards
|

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 28 Mar 2011 14:22:43 +0200

> Sent: Monday, March 28, 2011 2:12 PM

My point is that, without a NAT and without PCP, that same application
(and TCP stack, if the application is running TCP) would be receiving
the exact same unwanted inbound packets.  The application, TCP stack,
or host-based firewall already needs to be defensive against such 
inbound packets -- irrespective of the existence of the NAT or the
behavior of PCP.

-d

---

From: Francis Dupont <[email-masked]>
Date: Mon, 28 Mar 2011 15:16:14 +0200

=> this is an argument in favor to use IMPLICIT_MAPPING_EXISTS even
the condition can be handled by the NAT...
As I argue to keep IMPLICIT_MAPPING_EXISTS I won't say you are not right
but someone (else) could answer the client should not do that first.

Regards

PS: the IMPLICIT_MAPPING_EXISTS definition includes an implicit MAY
be returned.

---

From: Francis Dupont <[email-masked]>
Date: Mon, 28 Mar 2011 15:18:39 +0200

=> what I meant is the security concern is internal to the client.

Regards

---

From: Stuart Cheshire <[email-masked]>
Date: Tue, 29 Mar 2011 01:42:06 -0700

> provides a configuration for the pool of UDP ports where they take

I'm not good at guessing games. Can you explain to the rest of us why BIND and Unbound do this, and how it relates to PCP?

---

From: <[email-masked]>
Date: Tue, 29 Mar 2011 17:59:46 +0800

|> |created in the NAT (e.g., by sending a TCP SYN) is _not_ at any 
|> |additional or different risk if that port is modified with MAP than 
|> |today, where the application is not behind any sort of NAT at all.
|> 
|> I'm not suggesting that  OS will abdicate its responsibilities.
|> 
|> My point is that if the MAP removes filter, the application that 
|> caused an implicit dynamic mapping is likely to receive unwanted 
|> (destined to this app instead of PCP client app but still
|> unwanted) inbound packets.
|
|My point is that, without a NAT and without PCP, that same 
|application (and TCP stack, if the application is running TCP) 
|would be receiving the exact same unwanted inbound packets.  
|The application, TCP stack, or host-based firewall already 
|needs to be defensive against such inbound packets -- 
|irrespective of the existence of the NAT or the behavior of PCP.

Sure, host can drop packets it doesn't want. But with the existence
of the NAT and the EDF, some unwanted inbound packets would
be filtered on NAT, which not only make host's life easier but also 
 off the burden of  NAT and network (more importantly).  That's why
 we configured EDF on NAT.

My argument is that I don't think PCP client has the right to remove
NAT filter on behalf of another app.

BR,
Xiaohong

|
|-d
|
|> 
|> 
|> |
|> |-d
|> |
|> |> We do note PCP app does not care
|> |> filter policy,  but I wonder if it is reasonable that a 
|PCP app has 
|> |> the right to remove filter policy for other apps. It looks like 
|> |> lowering security policy for a subscriber. That's my concern.
|> |>
|> |> Thanks,
|> |> Xiaohong
|> |> opensource A+P: http://opensourceaplusp.weebly.com/
|> |>
|> |>
|> |> |
|> |> |-d
|> |> |
|> |> |
|> |> |> Thanks,
|> |> |> Xiaohong,
|> |> |> opensource A+P: http://opensourceaplusp.weebly.com/
|> |> |>
|> |> |>
|> |> |> |
|> |> |> |Stuart Cheshire <[email-masked]>
|> |> |> |* Wizard Without Portfolio, Apple Inc.
|> |> |> |* www.stuartcheshire.org
|> |> |> |
|> |> |> |
|> |> |
|> |> |
|> |
|> |
|
|

---

From: <[email-masked]>
Date: Tue, 29 Mar 2011 18:13:04 +0800

| In your previous mail you wrote:
|
|   I'm not suggesting that  OS will abdicate its responsibilities.
|   
|   My point is that if the MAP removes filter, the application that 
|   caused an implicit dynamic mapping is likely to receive 
|   unwanted (destined to this app instead of PCP client app but still 
|   unwanted) inbound packets.
|   
|=> this is an argument in favor to use IMPLICIT_MAPPING_EXISTS 
|even the condition can be handled by the NAT...
|As I argue to keep IMPLICIT_MAPPING_EXISTS I won't say you are 
|not right but someone (else) could answer the client should 
|not do that first.

I don't argue to keep it; instead I argue how to eliminate it
gracefully, 
but unfortunately, it dependents on NAT behaviors, according to what
we've discussed in this thread.

BR,
Xiaohong

|
|Regards
|
[email-masked]
|
|PS: the IMPLICIT_MAPPING_EXISTS definition includes an 
|implicit MAY be returned.
|

---

From: Francis Dupont <[email-masked]>
Date: Tue, 29 Mar 2011 13:28:30 +0200

> provides a configuration for the pool of UDP ports where they take
   
   Can you explain to the rest of us why BIND and Unbound do this,

=> because of the Kaminsky's bug, DNS caching servers including
BIND and Unbound had to perform aggressive UDP port randomization
(the exact requirement was to make the used UDP port as unpredictable
as possible). As soon as the corresponding code became to be used,
we (ISC, the BIND provider, but I believe it was the same thing for
NLnet Labs with Unbound) received a lot of complains about
"my application XXX logs it receives many malformed messages",
despite both have in their configuration file permit and avoid
port lists to specify what UDP ports to (not) use.

   and how it relates to PCP?
   
=> this is an real world example of massive interference between
applications about "same internal address and port" (the thing I said
to be unlikely but possible :-).

Regards

---

From: Stuart Cheshire <[email-masked]>
Date: Tue, 29 Mar 2011 04:48:25 -0700

> port lists to specify what UDP ports to (not) use.

And what scenario leads to application XXX receiving malformed messages? Was it just a foolish programming mistake? What was the solution?

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 29 Mar 2011 13:58:28 +0200

> Sent: Tuesday, March 29, 2011 12:00 PM

If an application on the host wants to receive incoming packets,
we cannot take any burden off the network.  Because, in order to 
receive those incoming packets, the network has to send those packets 
to the host.

> NAT filter on behalf of another app.

My argument is that it does not matter.  The first application (which
is a pure UDP or TCP client) sent a packet to the Internet, and has
_no reasonable expectation_ that the network does any filtering.  
You're saying that, on your network, it gets some filtering.  That's
great.  That's fine.  

The next application, listening on the same port, wants to receive
incoming packets.

So, the filtering gets removed from that first application.

I don't see a problem, because that first application had (and has)
no reasonable expectation of the network doing filtering on its
behalf.

-d

---

From: Francis Dupont <[email-masked]>
Date: Tue, 29 Mar 2011 14:46:39 +0200

And what scenario leads to application XXX receiving malformed messages?
  Was it just a foolish programming mistake? What was the solution?
   
=> to put the port(s) used by application XXX in a BIND/Unbound/etc
permit list and not in any avoid list (i.e., to say to BIND/Unbound/etc
to use the same port(s)). And the solution is to not put it any permit list
or to put it in an avoid list (i.e., to say to BIND/Unbound/etc to not use
the same port(s)).
 And, yes, we have to stay polite with customers...

Regards

PS: BTW as I type this on a MacBook I looked at the included BIND:
 - it is a BIND 9.6.0-APPLE-P2 (so not a home made one)
 - I expect it is post-Kamininsky version (I updated software before
  coming here)
 - its config file (/private/etc/named.conf) has no use-v4-udp-ports
 or avoid-v4-udp-ports clause (i.e., defaults are used)
So it should be very easy to trigger the interference problem I described.

---

From: Stuart Cheshire <[email-masked]>
Date: Tue, 29 Mar 2011 15:59:25 -0700

> So it should be very easy to trigger the interference problem I described.

Why should the user have to manually manage port lists? That's why the lists are empty on the Mac, because making the user manage this is stupid. It's the kernel's job to manage system resources.

Why doesn't BIND get a "port in use" error when it tries to bind to a port that's already in use?

---

From: Francis Dupont <[email-masked]>
Date: Wed, 30 Mar 2011 11:20:08 +0200

Why should the user have to manually manage port lists?

=> because it is the user who has the information.

  That's why the lists are empty on the Mac,

=> they are not empty: they are set to a default (a real empty use list
means no port can be used). BTW the default is OS dependent so I can't
say what is used on MacOS without looking at the sources.

   because making the user manage this is stupid.

=> no comment.

   It's the kernel's job to manage system resources.

=> if you mean the kernel should provide the service it was not the case
when Kaminsky published his "bug" and to get such a thing in a uniform/
usable way for all OSes is IMHO a dream.
   
   Why doesn't BIND get a "port in use" error when it tries to bind to
   a port that's already in use?
   
=> you mean EADDRINUSE? it is a matter of SO_REUSEADDR in fact...
BTW the randomization loop loops (:-) when bind() returns EADDRINUSE,
i.e., it tries another port at random.

Regards

PS: I am not here to defend the BIND design, just to explain in a real
world example than two different codes with the same UDP port randomization
requirement provide very similar configurations to avoid "same address
and port" interference.
(BTW this *is* in the scope of PCP)

---

From: Stuart Cheshire <[email-masked]>
Date: Thu, 31 Mar 2011 05:22:20 -0700

> i.e., it tries another port at random.

Are you saying that it will not in fact use a port that is already in use by another client; it will keep looping until the kernel doesn't return the EADDRINUSE error?

---

From: Francis Dupont <[email-masked]>
Date: Thu, 31 Mar 2011 14:43:52 +0200

> i.e., it tries another port at random.
   
   Are you saying that it will not in fact use a port that is already
   in use by another client; it will keep looping until the kernel
   doesn't return the EADDRINUSE error?
   
=> if the kernel returns this particular error it will keep looping
(but not for ever, it tries only 64 times. And to avoid to lock iself
it sets SO_REUSEADDR when it already uses the port, and *only* in this
case).
And I agree with your conclusion: it tries to avoid interferences

but obviously this can be at 100% efficient only with the collaboration
of the other parties, i.e., this feature must be implemented in the
kernel to be really correct

Regards

PS: I consider to remove the Cc: [email-masked]...