Subject: [pcp] handling NONEXIST_PEER

From: "Dan Wing" <[email-masked]>
Date: Mon, 14 Mar 2011 15:51:47 -0700

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

As a reminder, NONEXIST_PEER is returned if a PEER request is issued and
there is not already a mapping.

He suggested that, instead of returning an error, to simply have PEER create
a mapping exactly like would have been created with an implicit dynamic
mapping (e.g., sending a TCP SYN).

Thoughts?

-d

---

From: Simon Perreault <[email-masked]>
Date: Mon, 14 Mar 2011 19:10:25 -0400

> mapping (e.g., sending a TCP SYN).

I like it. It eliminates an error case that would otherwise need to be 
handled by client code.

For TCP, be sure to specify the state of the session to be created. Is 
it going to be SYN-SENT or something else? Would it be more useful if it 
was ESTABLISHED instead?

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

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

In your previous mail you wrote:

   He suggested that, instead of returning an error, to simply have
   PEER create a mapping exactly like would have been created with an
   implicit dynamic mapping (e.g., sending a TCP SYN).
   
   Thoughts?
   
=> I have a concern about this: PEER was fine as it doesn't create
anything, now it is no longer true so it could be used to bypass
security constraints.
IMHO we should keep the current behavior: PEER can't do more
than a "standard" packet.

Regards

[email-masked]

---

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

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Simon Perreault
> Sent: Monday, March 14, 2011 4:10 PM
> To: [email-masked]
> Subject: Re: [pcp] handling NONEXIST_PEER
> 
> it going to be SYN-SENT

That's pretty short-lived...  Which brings up another question:  
if the mapping didn't exist and was just created by the PEER
request, what Lifetime should be returned?

For example, a lot of NATs have two timers for UDP -- a short
timer (30 seconds) for a simple inside->outside UDP packet,
and a longer timer (3 minutes) if there was a response packet.
Similar things are done for TCP.

If the PEER created the mapping, it seems the PEER response needs
to indicate the short timer; afterall, nothing else has caused
the NAT to get very comfortable with a longer timeout.  That
will self-correct, if a successful connection is made to the
server.

> or something else? Would it be more useful if
> it was ESTABLISHED instead?

I don't think so.  Should be SYN-SENT or something very much
like SYN-SENT -- but without sending a SYN, of course.

-d

> _______________________________________________
> pcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pcp

---

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

It eliminates an error case that would otherwise need to be 
   handled by client code.
   
=> BTW a correct client should never get it.

Regards

PS: to remove this error has another side effect: if the implicit
dynamic mapping was removed for any reason the new mapping created
by the PEER has no reason to get the same external address and port,
so you miss to detect an error condition by hiding it...

---

From: Simon Perreault <[email-masked]>
Date: Mon, 14 Mar 2011 20:04:39 -0400

On 03/14/2011 07:38 PM, Dan Wing wrote:
> That's pretty short-lived...

I was assuming that the session's lifetime would be set to the lifetime 
contained in the PEER message, no matter what state it is set to.

> Which brings up another question:

I would find anything other than the lifetime contained in the PEER 
message to be really bizarre. We need some uniformity here.

Simon

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 14 Mar 2011 17:14:44 -0700

> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, March 14, 2011 4:20 PM
> To: Dan Wing
> Cc: [email-masked]; 'Stuart Cheshire'

How would this proposal allow PEER to bypass security constraints?  What
could occur that's new?

-d

---

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

> Francis Dupont
> Sent: Monday, March 14, 2011 4:39 PM
> To: Simon Perreault
> Cc: [email-masked]

Agreed.  But not all code is written correctly.

> so you miss to detect an error condition by hiding it...

Yes, good point.

-d

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 14 Mar 2011 17:17:21 -0700

> From: Simon Perreault [mailto:[email-masked]]
> Sent: Monday, March 14, 2011 5:05 PM
> To: Dan Wing
> Cc: [email-masked]

Let me ask my question differently:  if the requested-lifetime in
the PEER message was really long (e.g., 24 hours), and we allow 
PEER to create a mapping, should we [ encourage | discourage | 
be silent ] on what lifetime the PCP server should use in the 
PEER response.

-d

---

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

> anything, now it is no longer true so it could be used to bypass
   
   How would this proposal allow PEER to bypass security constraints?

=> this way:
 1- do you agree a TCP packet can't create an implicit dynamic mapping
  if it is not a SYN from the internal side?
 2- with the proposal PEER can create an implicit dynamic mapping
 3- so either all the security constraints for the creation of
  implicit dynamic mapping, including packets which can create one
  as a side effect, etc, are to be adapted and applied to PEER messages;
  or you provide a way to bypass these security constraints.

   What could occur that's new?

=> creation of implicit dynamic mapping by a new way.
   
In conclusion this proposal makes PEER no longer neutral from
a security point of view, IMHO this con is far bigger than the pro
which is to allow a client to initiate a flow or to send a PEER
in any order.

Regards

PS: BTW to apply security constraints to PEER requests is not
something a client wants to happen as it is prepare to never
get an error for a PEER about an established connection...
(This to argue about the proposal makes the client simpler)

---

From: Francis Dupont <[email-masked]>
Date: Tue, 15 Mar 2011 01:54:19 +0100

=> we should first agree this proposal is a good idea and
I think it is *not*.

Regards

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 14 Mar 2011 18:01:52 -0700

> Sent: Monday, March 14, 2011 5:54 PM
> To: Dan Wing
> Cc: 'Simon Perreault'; [email-masked]

Let's first discuss all of the pros/cons.

  > so you miss to detect an error condition by hiding it...

enough to kill the idea:  namely, that the error is useful to tell
the client that no mapping exists, which tells it something is awry.
I'm interested in hearing more from others, though.

-d

---

From: Stuart Cheshire <[email-masked]>
Date: Tue, 15 Mar 2011 05:34:10 -0700

> than a "standard" packet.

That's what I was proposing: That a PEER request should be treated exactly the *same* as "standard" packet. A PEER request should be treated exactly the same as a TCP SYN for the same five-tuple. Either it makes a mapping or it doesn't, just like a TCP SYN. The difference between a SYN and a PEER request is that the PEER request also returns an explicit reply telling the client the lifetime of the mapping.

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

---

From: <[email-masked]>
Date: Tue, 15 Mar 2011 14:19:12 +0100

Hi all,

Putting aside how to set the lifetime, we need to maintain a CLEAR separation between MAP and PEER Opcodes. 

PEER has been defined to control an existing mapping and not to create it; hence I vote for returning the error code.

Cheers,
Med 

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Dan Wing
Envoyé : lundi 14 mars 2011 23:52
À : [email-masked]
Cc : 'Stuart Cheshire'
Objet : [pcp] handling NONEXIST_PEER

Thoughts?

-d

---

From: Stuart Cheshire <[email-masked]>
Date: Mon, 21 Mar 2011 15:56:22 -0700

> PEER has been defined to control an existing mapping and not to create it; hence I vote for returning the error code.

A clear separation is fine.

I think PEER should work just like a TCP SYN -- make a mapping if necessary; return existing mapping if it's already there.

If we added a "suggested port" field, this would have the nice property that it could also recover lost outbound mappings after a reboot. So... you could reboot your NAT gateway and not lose all your outbound ssh connections.

If we do this we'd have the nice result that you could reboot your NAT gateway and not lose inbound *or* outbound connections.

---

From: Francis Dupont <[email-masked]>
Date: Tue, 22 Mar 2011 00:32:28 +0100

If we added a "suggested port" field, this would have the nice
   property that it could also recover lost outbound mappings after a
   reboot.
   
=> or from the security point of view provides to attacker a nice
way to steal your implicit dynamic mappings too (today they are
hard to steal because the assigned external port is not under
control, in fact it is in general unpredictable and often even
randomized, so cryptographically unpredictable).

   If we do this we'd have the nice result that you could reboot your
  NAT gateway
   
=> PCP is not a replacement to NAT-PMP (or to UPnP IGD 1.0 which
already has its own improved version, 2.0) so you should no
longer assume the device it controls is the NAT home gateway...

Regards

---

From: Stuart Cheshire <[email-masked]>
Date: Mon, 21 Mar 2011 16:36:38 -0700

> randomized, so cryptographically unpredictable).

I didn't say any particular NAT was obliged to honor the "suggested port" field -- just that the protocol be able to express it, for those that do.

> => PCP is not a replacement to NAT-PMP

That's your opinion. I'd be interested to hear what others think.

Why have two different protocols when we could have one?

---

From: Francis Dupont <[email-masked]>
Date: Tue, 22 Mar 2011 12:42:37 +0100

> => PCP is not a replacement to NAT-PMP
   
=> BTW this is a partial quote

   
=> do you mean we should use UPnP IGD 2.0? It does the job,
is already standardized, handles security, IPv6 firewalls, etc.
Yes, why two different protocols?

Regards

---

From: Stuart Cheshire <[email-masked]>
Date: Tue, 22 Mar 2011 11:35:14 -0700

> Yes, why two different protocols?

If IGD 2 did what we wanted, then I'd advocate using it instead of inventing something new.

It doesn't, so we can't.

Given that we therefore are forced to design a new protocol that does do what we want, let's at least try to make it good.

It should encompass all of the desired properties of NAT-PMP, IGD 1 and IGD 2, so that it could be a viable replacement for all of them.

I, for one, hope to see NAT-PMP entirely replaced by PCP within a few years because (if we're successful) PCP is better. There's no reason for client developers to cling to old inferior protocols like NAT-PMP IGD if something better and more capable exists.

---

From: Francis Dupont <[email-masked]>
Date: Tue, 22 Mar 2011 22:51:57 +0100

If IGD 2 did what we wanted, then I'd advocate using it instead of
  inventing some thing new.
   
   It doesn't, so we can't.
   
=> what things we (?) want and is not provided by IGD 2
in such a way a new protocol has to be designed from scratch.
(this is not against PCP: the decision to develop PCP
and the WG charter were taken before the publication of IGD 2).

   There's no reason for client developers to cling to old inferior
   protocols like NAT-PMP IGD if something better and more capable
   exists.
   
=> I would have written 'no technical reason' (:-).

Regards

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 22 Mar 2011 15:18:23 -0700

> Sent: Tuesday, March 22, 2011 2:52 PM
> To: Stuart Cheshire
> Cc: [email-masked]

http://trac.tools.ietf.org/wg/pcp/trac/wiki says:

    2. UPnP IGD:2 (
http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v2-Service.pdf)

    * no support for NAT64, NAT46, or NAT66
    * data model assumes host has complete control of the NAT (e.g., client
dictates mapping duration)
    * discovery uses multicast
    * XML over TCP is heavy

-d

---

From: Francis Dupont <[email-masked]>
Date: Tue, 22 Mar 2011 23:59:55 +0100

2. UPnP IGD:2 (

=> NAT66 (I am not sure of the name to use) doesn't need
control as it is an algorithmic address translator nor is
handled by current PCP BTW...

       * data model assumes host has complete control of the NAT
   (e.g., client dictates mapping duration)

=> this is a real difference but I am not sure it is not what
users want in fact.

=> but doesn't rely on multicast?
(my miniupnpc client says:
  -u url : bypass discovery process by providing the XML root
   description url.)

       * XML over TCP is heavy
   
=> this is an opinion (what I share) not a missing feature.
   
So the remaining points are NAT64/NAT46, aren't they?

Regards

---

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

> handled by current PCP BTW...

The client needs to be able to learn its external IPv6 address.

> => this is a real difference but I am not sure it is not what users want in fact.

Users may *want* complete control of a shared Large-Scale NAT, but they can't have it.

>  -u url : bypass discovery process by providing the XML root

I updated the page to clarify this.

---

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

=> something which is not provided by current PCP.

About NATxy where at least one of x or y is not 4, UPnP IGD
has the needed flexibility in address attributes (one can even say
it has too much flexibility as it accepts FQDNs too :-).

   > => this is a real difference but I am not sure it is not what
   
   Users may *want* complete control of a shared Large-Scale NAT, but
   they can't have it.
   
=> my comment was about the example.

=> if you can add more convincing arguments please do.
I've just reread the wiki and I can't find something in the charter
which can't be done (re)using IGD 2.

Regards

PS: BTW I don't understand "no way for client to provide a suggested
external port to the NAT gateway, for state recovery after reboot"
(AddAnyPortMapping() has the NewExternalPort IN attribute).

---

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

> => something which is not provided by current PCP.

What are you talking about?

draft-ietf-pcp-base-08:

   If the PCP-controlled device is stateless (that is, it does not
   establish any per-flow state, and simply rewrites the address and/or
   port in a purely algorithmic fashion), the PCP server simply returns
   an answer indicating the external IP address and port yielded by this
   stateless algorithmic translation.  This allows the PCP client to
   learn its external IP address and port as seen by remote peers.
   Examples of stateless translators include stateless NAT64 and 1:1
   NAT44, both of which modify addresses but not port numbers.

> which can't be done (re)using IGD 2.

Are you advocating that Large Scale NATs adopt IGD 2 instead?

If not, then what point are you making?

---

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

draft-ietf-pcp-base-08:
   
=> I've checked: there is no 08 in I-D repositories?

=> it is not the same thing as this does not give the indication
the NAT is an address translator only but:
 - the NAT66 (with its last/current name) is known to perform
  address only translation
 - there should be a dedicated I-D solving the getexternalip()
  issue as it is needed for IWFs too.
This is why I said *current* PCP.

   
   
=> I have some feelings:
 - I am not sure IGD 2 was declared as not being able to provide
  what is described in the PCP charter on the technical ground,
  i.e., it seems it is a case of NIH (Not Invented Here)
 - if there will be a competition in the market between IGD 2
  and PCP I am afraid to know the winner
BTW only an ISP can answer: perhaps IGD 2 has some problems for
an ISP? And I don't work for an ISP so I can't tell.

Regards

---

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

draft-ietf-pcp-base-08:

   

   
   
=> I have some feelings:

Regards

---

From: <[email-masked]>
Date: Mon, 28 Mar 2011 09:47:09 +0200

Dear Stuart,

Please see inline.

Cheers,
Med 

-----Message d'origine-----
De : Stuart Cheshire [mailto:[email-masked]] 
Envoyé : lundi 21 mars 2011 23:56
À : BOUCADAIR Mohamed OLNC/NAD/TIP
Cc : Dan Wing; [email-masked]
Objet : Re: [pcp] handling NONEXIST_PEER

Med: Ok, this means it applies only for existing mappings; it the mappings does not exist return an error.

Med: This contradicts the assumptions under which PEER has been defined. 

Med: What prevents the application to use MAP in that case? 

Med: You can use GET/NEXT for this; why not?