Subject: [pcp] NAT behavior: dangerous slope

From: Francis Dupont <[email-masked]>
Date: Fri, 17 Dec 2010 00:55:05 +0100

IMHO the WG is on a dangerous slope about NAT behavior:
 - first as far as I know the WG is not chartered to change or even
  specify NAT behavior
 - second it is clear the real world doesn't always follow IETF
  recommendations and simply ignore our dreams
so I'd like to no longer read things like:
      [Ed.  Note: The following text needs discussion.  Keep it or
      discard it?]  When a mapping is destroyed as a result of its
      lifetime expiring or for any other reason, if the NAT gateway's
      internal state indicates that there are still active TCP
      connections traversing that now- defunct mapping, then the NAT
      gateway SHOULD send appropriately- constructed TCP RST (reset)
      packets both to the local client and to the remote peer on the
      Internet to terminate that TCP connection.
(i.e., my position is a MAY is already arguable, and a SHOULD clearly
not acceptable)
or worse (as it can be correct only for UDP):
   ... As a consequence of dropping the
   packet, an ICMP port unreachable error SHOULD be generated, as long
   as it does not violate the security policy of the NAT/firewall.

The only thing we may assume about the NAT controlled by a PCP server
is it provides a way (e.g., API) to create and delete Port Forwarding
entries (with the base-01 definition of Port Forwarding).

Regards

[email-masked]

---

From: Simon Perreault <[email-masked]>
Date: Thu, 16 Dec 2010 20:45:06 -0500

> entries (with the base-01 definition of Port Forwarding).

+1

We should only refer to BEHAVE's documents for NAT behaviour.

Simon

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 20 Dec 2010 08:52:24 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Francis Dupont
> Sent: Thursday, December 16, 2010 3:55 PM
> To: [email-masked]
> Subject: [pcp] NAT behavior: dangerous slope
> 

Um, yes.  That's why I included the "Ed. Note".

>    as it does not violate the security policy of the NAT/firewall.

That text was meant to apply to TCP, and should reference to REQ-4 of
RFC5382 (TCP requirements).  I adjusted it to now read:

  If the dropped packet was a TCP packet and the controlled device 
  is a NAT, REQ-4 of <xref target="RFC5382"></xref> SHOULD be 
  followed.

-d

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

---

From: Francis Dupont <[email-masked]>
Date: Mon, 20 Dec 2010 20:14:58 +0100

In your previous mail you wrote:

   
=> REQ-4 is about TCP SYN so you removed a major part of the context...
BTW in this case I can't see how this can be critical so IMHO
this is only a spurious requirement about NAT behavior (i.e., exactly
what I've considered as a dangerous slope).

Regards

---

From: Simon Perreault <[email-masked]>
Date: Mon, 20 Dec 2010 14:19:21 -0500

> what I've considered as a dangerous slope).

Since RFC5382 already contains the necessary normative text, how about
instead:

    Note: See also REQ-4 of [RFC5382].

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: "Dan Wing" <[email-masked]>
Date: Mon, 20 Dec 2010 11:21:39 -0800

> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, December 20, 2010 11:15 AM
> To: Dan Wing
> Cc: [email-masked]
> Subject: Re: [pcp] NAT behavior: dangerous slope
> 
> 

Text removed.

-d