Subject: [pcp] PCP MAP expiring connections

From: Norman Sardella <[email-masked]>
Date: Tue, 07 May 2013 09:12:59 -0400

The following section was updated in RFC 6887.

I understand the section as follows
    The MAP or PEER request with lifetime of 0 will only set the
    assigned lifetime to 0 (i.e., delete the mapping) if the internal
    host had not sent a packet using that mapping for the idle-timeout
    time, otherwise the assigned lifetime will be the remaining
    idle-timeout time.

Can someone clarify the meaning of idle-timeout?
How is it defined/configured and what does it mean to be "idle"? Is 
"idle" a new state in a mapping where the mapping exists but no packets 
have used it for this defined "idle-timeout" period?

Thanks

http://tools.ietf.org/html/rfc6887#section-15
>    When using NAT, the same external port may be assigned for use by
>    different internal hosts at different times.  For example, if an
>    internal host using an external port ceases sending traffic using
>    that port, then its mapping may expire, and then later the same
>    external port may be assigned to a new internal host.  The new
>    internal host could then receive incoming traffic that was intended
>    for the previous internal host.  This generally happens
>    inadvertently, and this reassignment of the external port only
>    happens after the current holder of the external port has ceased
>    using it for some period of time.  It would be unacceptable if an
>    attacker could use PCP to intentionally speed up this reassignment of
>    the external port in order to deliberately steal traffic intended for
>    the current holder, by (i) spoofing PCP requests using the current
>    holder's source IP address and mapping nonce to fraudulently delete
>    the mapping or shorten its lifetime, and then (ii) subsequently
>    claiming the external port for itself.

>    Therefore, in the simple security model, to protect against this
>    attack, PCP MUST NOT allow a PCP request (even a PCP request that
>    appears to come from the current holder of the mapping) to cause a
>    mapping to expire sooner than it would naturally have expired
>    otherwise by virtue of outbound traffic keeping the mapping active.
>    A PCP server MUST set the lifetime of a mapping to no less than the
>    remaining time before the mapping would expire if no further outbound
>    traffic is seen for that mapping.  This means a MAP or PEER request
>    with lifetime of 0 will only set the assigned lifetime to 0 (i.e.,
>    delete the mapping) if the internal host had not sent a packet using
>    that mapping for the idle-timeout time, otherwise the assigned
>    lifetime will be the remaining idle-timeout time.
>
>    Finally, to reduce unwanted traffic and data corruption for both TCP
>    and UDP, the assigned external port created by the MAP Opcode or PEER
>    Opcode SHOULD NOT be reused for an interval equal to the reuse time
>    limit enforced by the NAT for its implicit dynamic mappings
>    (typically, the maximum TCP segment lifetime of 2 minutes [RFC0793]).
>    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".

---

From: Simon Perreault <[email-masked]>
Date: Tue, 07 May 2013 15:20:53 +0200

> The following section was updated in RFC 6887.

Note that it's just a rewording. No behavioural change.

> have used it for this defined "idle-timeout" period?

The "idle-timeout time" is the time it takes for the NAT to delete a 
mapping on which there is no traffic. For example, a NAT could delete a 
UDP mapping after 60 seconds if there is no traffic.

Example: consider a mapping. That mapping's lifetime was initially set 
with PCP to 1000 seconds, and there are 900 seconds remaining. The last 
packet seen on this mapping was 15 seconds ago. The PCP server receives 
a lifetime=0 request to delete the mapping. It would set the mapping's 
lifetime to 45 seconds. That is, the idle-timeout time (60) minus the 
time since the last packet seen on the mapping (15).

Note that the idle-timeout time varies across NAT implementations, 
protocols, connection tracking states, time of day, current load, etc.

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: Wed, 8 May 2013 11:12:16 -0700

On May 7, 2013, at 6:20 AM, Simon Perreault <[email-masked]> wrote:

> The "idle-timeout time" is the time it takes for the NAT to delete a mapping on which there is no traffic. For example, a NAT could delete a UDP mapping after 60 seconds if there is no traffic.
> 
> Example: consider a mapping. That mapping's lifetime was initially set with PCP to 1000 seconds, and there are 900 seconds remaining. The last packet seen on this mapping was 15 seconds ago. The PCP server receives a lifetime=0 request to delete the mapping. It would set the mapping's lifetime to 45 seconds. That is, the idle-timeout time (60) minus the time since the last packet seen on the mapping (15).
> 
> Note that the idle-timeout time varies across NAT implementations, protocols, connection tracking states, time of day, current load, etc.

Some references,
  UDP NAT, http://tools.ietf.org/html/rfc4787#section-4.3
  TCP NAT, http://tools.ietf.org/html/rfc5382#page-11
  IPv6 simple CPE firewall, see REC-15 of http://tools.ietf.org/html/rfc6092

-d

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