Subject: [pcp] Clarification to Section 15 of RFC 6887

From: Ben McCann <[email-masked]>
Date: Mon, 20 May 2013 11:30:17 -0400

I'm finding the discussion in section 15 of the RFC confusing because 
the use of 'mapping' in Section 15 is ambiguous to me. (Yes, 'mapping' 
is  defined in the terminology section of the RFC but it's still 
ambiguous in Section 15).

My problem is that the RFC states a MAP opcode creates a 'mapping' but 
then it doesn't really discuss the difference between an explicit 
mapping created by PCP and and other implicit mappings created, on 
demand, by the PCP created explicit mapping. The following points 
attempt to use the terminology in RFC 6887:

  * An 'implicit dynamic outbound' mapping defines the transformation of
    *one* TCP or UDP flow from a client behind the NAT to a server
    outside the NAT. This mapping is created implicitly when the client
    connects to the server. Typically the client's source address and
    port are rewritten by the NAT to some other source address and port
    owned by the NAT. Most importantly, *both* endpoints of the flow are
    known.
  * In contrast, an 'explicit dynamic inbound' mapping created by the
    PCP MAP opcode only defines *one* endpoint. A server behind the NAT
    defines its listening endpoint and the NAT provides a corresponding
    listening endpoint on the outside of the NAT. The IP address and
    port of clients outside the NAT are unknown, at this time, because
    all we've created is a 'listener'.
  * When a client outside the NAT connects to a server behind the NAT
    via the 'explicit dynamic inbound' mapping then another 'mapping' is
    created. This 'mapping' has *two* endpoints, like an implicit
    dynamic outbound mapping, and it is created implicitly using the
    'explict dynamic inbound' mapping defined by the PCP MAP opcode. I
    don't think the RFC does a good job of labeling or describing this
    kind of mapping. I *think* the RFC also uses the term 'explicit
    mapping' for this kind of mapping but I find that misleading. This
    mapping is created implicitly when a TCP SYN packet from a client
    outside the NAT was transmitted to a server *behind* the NAT. For
    now, I'm calling this an 'IMPLICIT INBOUND MAPPING'.

Note that inbound and outbound IMPLICIT mappings have an 'idle-timeout 
time' which describes when the mapping can be destroyed due to lack of 
traffic. That timeout must (I think) be at least 2 minutes for UDP and 
124 minutes for TCP. (The exact timeout limits aren't critical to this 
discussion).

The discussion in Section 15 about 'mapping lifetime and deletion' can 
(I think) be interpreted in different ways depending on the definition 
of 'mapping'. When a MAP request arrives with a zero lifetime then we 
have to clean up some inbound mapping but, I argue, that cleanup varies 
depending on whether the mapping is explicit (created by PCP MAP) or 
implicit (created implicitly on behalf ofsome *other* explicit inbound 
mapping).

Specifically:

  * The 'explicit dynamic inbound' mapping created by the PCP MAP opcode
    must be deleted *immediately*. The server behind the NAT wants no
    *new* inbound connections. It is no longer 'listening'.
  * The 'implicit dynamic inbound' mappings, that are TCP and UDP flows
    connecting two distinct endpoints, must be deleted at the end of
    their NAT idle-timeout time. I.e. if a packet has been received
    within the NAT idle-timeout time then the 'implicit dynamic inbound'
    mapping CANNOT be deleted because a flow is still active between two
    endpoints. If the 'implicit dynamic inbound' mapping has been idle
    for longer than the NAT idle-timeout time then it can be deleted, if
    it hasn't been already.

The RFC seems to imply that its OK to delete 'implicit dynamic mapping's 
that were idle for more than the NAT idle timeout when a PCP MAP opcode 
is received with a lifetime of zero. That doesn't make sense to me 
because why wasn't it ALREADY deleted? It's idle.

I think this can be boiled down to a simpler description of 'lifetime' 
and 'timeouts':

  * Servers behind a NAT use the PCP MAP opcode to start listening for
    incoming connections from clients outside the NAT. The 'lifetime'
    within the PCP MAP opcode declares how long the server wants to
    listen for new connections. This must be refreshed (with another
    MAPopcode) before the lifetime expires if the server wishes to
    continue listening.
  * An 'implicit dynamic inbound' mapping is created when clients
    connect to the server that declared its intent to listen for
    connections via the PCP MAP request. The 'idle-timeout' time of that
    mapping is defined by TCP or UDP protocol and the policy of the NAT
    box. If neither client nor server transmits packets within this
    'idle-timeout' time then the 'implicit dynamic inbound' mapping will
    be automatically destroyed.
  * Any 'implicit dynamic inbound' mappings created by an 'explicit
    inbound mapping' created by PCP MAP that are still active when the
    'explicit inbound mapping' is destroyed SHALL NOT be destroyed as a
    side-effect of destroying the PCP mapping. The 'implicit dynamic
    inbound' mappings shall be destroyed when the peers either close the
    connection or when the idle-timeout expires.

Is this 'simpler description' consistent with the behavior of PCP 
lifetimes as intended by Section 15 of RFC 6887?

-Ben McCann

---

From: Dan Wing <[email-masked]>
Date: Tue, 21 May 2013 12:58:33 -0700

On May 20, 2013, at 8:30 AM, Ben McCann <[email-masked]> wrote:

> I'm finding the discussion in section 15 of the RFC confusing because the use of 'mapping' in Section 15 is ambiguous to me. (Yes, 'mapping' is  defined in the terminology section of the RFC but it's still ambiguous in Section 15).
> 
> My problem is that the RFC states a MAP opcode creates a 'mapping' but then it doesn't really discuss the difference between an explicit mapping created by PCP and and other implicit mappings created, on demand, by the PCP created explicit mapping. The following points attempt to use the terminology in RFC 6887:
> An 'implicit dynamic outbound' mapping defines the transformation of *one* TCP or UDP flow from a client behind the NAT to a server outside the NAT. This mapping is created implicitly when the client connects to the server. Typically the client's source address and port are rewritten by the NAT to some other source address and port owned by the NAT. Most importantly, *both* endpoints of the flow are known.
> In contrast, an 'explicit dynamic inbound' mapping created by the PCP MAP opcode only defines *one* endpoint. A server behind the NAT defines its listening endpoint and the NAT provides a corresponding listening endpoint on the outside of the NAT. The IP address and port of clients outside the NAT are unknown, at this time, because all we've created is a 'listener'.
> When a client outside the NAT connects to a server behind the NAT via the 'explicit dynamic inbound' mapping then another 'mapping' is created.
That depends on the implementation of the NAT; in some NATs, that incoming packet will create an additional data structure within the NAT, whereas in some other NATs, no additional datastructure is created (thus now new mapping is created).

> This 'mapping' has *two* endpoints, like an implicit dynamic outbound mapping, and it is created implicitly using the 'explict dynamic inbound' mapping defined by the PCP MAP opcode. I don't think the RFC does a good job of labeling or describing this kind of mapping.

On purpose, because this gets into detail of how a NATP44 is implemented.  IETF was late to that party, and the best that was done was BEHAVE which skirted around a lot of the details because there was no chance of influencing existing NAT44 behavior.

> I *think* the RFC also uses the term 'explicit mapping' for this kind of mapping but I find that misleading. This mapping is created implicitly when a TCP SYN packet from a client outside the NAT was transmitted to a server *behind* the NAT. For now, I'm calling this an 'IMPLICIT INBOUND MAPPING'.

Well, okay.  But for NATs that don't create any additional datastructure or state when such a packet arrives, they won't have that concept.

> Note that inbound and outbound IMPLICIT mappings have an 'idle-timeout time' which describes when the mapping can be destroyed due to lack of traffic. That timeout must (I think) be at least 2 minutes for UDP and 124 minutes for TCP. (The exact timeout limits aren't critical to this discussion).
> 
> The discussion in Section 15 about 'mapping lifetime and deletion' can (I think) be interpreted in different ways depending on the definition of 'mapping'. When a MAP request arrives with a zero lifetime then we have to clean up some inbound mapping but, I argue, that cleanup varies depending on whether the mapping is explicit (created by PCP MAP) or implicit (created implicitly on behalf of some *other* explicit inbound mapping). 

When a MAP with lifetime=0 arrives -- or, really, any other lifetime -- it will not cause a deletion unless the mapping has not been used for a while.  The exact text is at the bottom of Section 15:

   Furthermore, to reduce port stealing attacks, the assigned external
   port also SHOULD NOT be reused for an interval equal to the time the
   PCP- controlled device would normally maintain an idle (no traffic)
   implicit dynamic mapping (e.g., 2 minutes for UDP [RFC4787] and 124
   minutes for TCP [RFC5382]).  However, within these time windows, the
   PCP server SHOULD allow an external port to be reclaimed by the same
   client, where "same client" means "same internal IP address, internal
   port, and mapping nonce".

> Specifically:
> The 'explicit dynamic inbound' mapping created by the PCP MAP opcode must be deleted *immediately*. The server behind the NAT wants no *new* inbound connections. It is no longer 'listening'.
> The 'implicit dynamic inbound' mappings, that are TCP and UDP flows connecting two distinct endpoints, must be deleted at the end of their NAT idle-timeout time. I.e. if a packet has been received within the NAT idle-timeout time then the 'implicit dynamic inbound' mapping CANNOT be deleted because a flow is still active between two endpoints. If the 'implicit dynamic inbound' mapping has been idle for longer than the NAT idle-timeout time then it can be deleted, if it hasn't been already.
> The RFC seems to imply that its OK to delete 'implicit dynamic mapping's that were idle for more than the NAT idle timeout when a PCP MAP opcode is received with a lifetime of zero. That doesn't make sense to me because why wasn't it ALREADY deleted? It's idle.

I believe you are saying MAP with Lifetime=0 is always useless.  The case where it is useful is if a MAP request is made for a long time (let's say, 24 hours) and the response indicates the assigned lifetime is a long time (let's say, 12 hours).  Then, an hour later, the client decides it doesn't want that mapping so it sends a new MAP with lifetime=0.  As long as the client never sent any traffic using that mapping, the mapping can be immediately destroyed.  If the client did send traffic using that mapping, the last paragraph of Section 15 says the mapping SHOULD persist until the NAT would have normally timed it out from that client activity.

> 
> I think this can be boiled down to a simpler description of 'lifetime' and 'timeouts':
> Servers behind a NAT use the PCP MAP opcode to start listening for incoming connections from clients outside the NAT. The 'lifetime' within the PCP MAP opcode declares how long the server wants to listen for new connections. This must be refreshed (with another MAP opcode) before the lifetime expires if the server wishes to continue listening.

Sounds good.

> An 'implicit dynamic inbound' mapping is created when clients connect to the server that declared its intent to listen for connections via the PCP MAP request. The 'idle-timeout' time of that mapping is defined by TCP or UDP protocol and the policy of the NAT box. If neither client nor server transmits packets within this 'idle-timeout' time then the 'implicit dynamic inbound' mapping will be automatically destroyed.

I don't see a need to define 'implicit dynamic inbound', especially considering a NAT does not necessarily need to create state because of that incoming packet.  The only thing that should keep the mapping open is activity by the client -- sending data on that mapping or refreshing the mapping with a PCP MAP request.  Specifically, activity from the Internet is not sufficient to keep the mapping open (which is the same as existing behavior of NATs and firewalls, and conforms to BEHAVE's TCP and UDP RFCs on NAT and firewall behavior).

> Any 'implicit dynamic inbound' mappings created by an 'explicit inbound mapping' created by PCP MAP that are still active when the 'explicit inbound mapping' is destroyed SHALL NOT be destroyed as a side-effect of destroying the PCP mapping. The 'implicit dynamic inbound' mappings shall be destroyed when the peers either close the connection or when the idle-timeout expires.
> Is this 'simpler description' consistent with the behavior of PCP lifetimes as intended by Section 15 of RFC 6887?

Yes, by my read of what you said.

-d

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