Subject: [pcp] #51: Mapping vs Filtering effect confusion

From: "pcp issue tracker" <[email-masked]>
Date: Tue, 07 Jun 2011 00:18:09 -0000

#51: Mapping vs Filtering effect confusion

 RFC 4787 defines mapping and filtering state to be separate.  Currently
 the PCP draft seems to confuse them into one piece of state and only
 explicitly mentions the mapping state.

 Section 3:
 > Mapping, Port Mapping, Port Forwarding:
 >    A NAT mapping creates a relationship between an internal IP
 >    address, protocol, and port and an external IP address, protocol,
 >    and port.  More specifically, it creates a translation rule where
 >    packets destined to the external IP and port are translated to the
 >    internal IP and port, and vice versa.  In the case of a pure
 >    firewall, the "Mapping" is the identity function, translating an
 >    internal port number to the same external port number, and this
 >    "Mapping" indicates to the firewall that traffic to and from this
 >    internal port number is permitted to pass.

 Last phrase above confuses mapping state with filtering state.

 Somewhere in this doc needs to explain that MAP results in EIF.  PEER
 (without MAP) only needs APDF to support uses 7.2 (Reducing NAT Keepalive
 Messages) and 7.3 (Restoring Lost Implicit TCP Dynamic Mapping State).

 Section 8.6:
 > If the PCP client attempts to delete an implicit dynamic
 > mapping (e.g., created by a TCP SYN), the PCP server deletes  the
 > mapping and responds with the SUCCESS result code.

 This is confusing with respect to mapping vs filtering.   On a TCP SYN, it
 will create an implicit dynamic mapping, and also an implicit dynamic
 filtering hole for the specific Remote Host.   What would MAP remove?
 Both?   What if the client wants to stop accepting *new* connections but
 wants existing connections to continue until it can close them gracefully
 (e.g. at the end of a data transfer)?

 Section 9.1 (PEER format):
 > Remote Peer  IP Address: [...]  Note
 >    this field has no bearing whatsoever on any filtering associated
 >    with the mapping.

 Why not?  You can’t use this to refresh state for TCP as in section 7.3?
 To do that you have to re-create the filtering state somehow.

-- 
-----------------------------------+----------------------------------------
 Reporter:  dthaler@…              |       Owner:  draft-ietf-pcp-base@…             
     Type:  defect                 |      Status:  new                               
 Priority:  major                  |   Milestone:                                    
Component:  base                   |     Version:                                    
 Severity:  Active WG Document     |    Keywords:                                    
-----------------------------------+----------------------------------------

Ticket URL: <http://zinfandel.levkowetz.com/wg/pcp/trac/ticket/51>
pcp <http://tools.ietf.org/pcp/>

---

From: "pcp issue tracker" <[email-masked]>
Date: Tue, 07 Jun 2011 14:43:34 -0000

Comment(by dthaler@…):

 June 7 webex call:
 Q1) Dan - MAP does EIM and EIF.  PEER uses whatever filtering NAT does
 today.
 Will add new text.
 Q2) Stuart - agree there is no way to stop accepting new connections
 without closing own.
 Dan - app could use FILTER for this.
 Dave - UDP generally uses 1 socket, so doesn't arise.  Closing TCP listen
 socket without accept can happen, but listen socket isn't a BW sink we
 care about.
 No new text needed

Ticket URL: <http://trac.tools.ietf.org/wg/pcp/trac/ticket/51#comment:1>
pcp <http://tools.ietf.org/pcp/>

---

From: "pcp issue tracker" <[email-masked]>
Date: Wed, 22 Jun 2011 15:41:08 -0000

Comment(by cheshire@…):

 Added text stating that all MAP mappings are EIM+EIF

Ticket URL: <http://trac.tools.ietf.org/wg/pcp/trac/ticket/51#comment:2>
pcp <http://tools.ietf.org/pcp/>

---

From: "pcp issue tracker" <[email-masked]>
Date: Wed, 22 Jun 2011 15:57:21 -0000

Changes (by cheshire@…):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 Added text stating that PEER mappings may be EIM or EDM, and EIF or EDF.

-- 
-----------------------------------+----------------------------------------
 Reporter:  dthaler@…              |        Owner:  draft-ietf-pcp-base@…             
     Type:  defect                 |       Status:  closed                            
 Priority:  major                  |    Milestone:                                    
Component:  base                   |      Version:                                    
 Severity:  Active WG Document     |   Resolution:  fixed                             
 Keywords:                         |  
-----------------------------------+----------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/pcp/trac/ticket/51#comment:3>
pcp <http://tools.ietf.org/pcp/>

---

From: Reinaldo Penno <[email-masked]>
Date: Wed, 22 Jun 2011 18:37:39 -0400

Meaning that all MAP requests install and delete both EIM+EIF?

On 6/22/11 8:41 AM, "pcp issue tracker" <[email-masked]> wrote:

> Comment(by cheshire@Š):

---

From: Stuart Cheshire <[email-masked]>
Date: Thu, 23 Jun 2011 22:05:01 -0700

> Meaning that all MAP requests install and delete both EIM+EIF?

Yes:

   Note that all mappings created by PCP MAP requests are, by
   definition, Endpoint Independent Mappings with Endpoint Independent
   Filtering (unless the FILTER Option is used), even on a NAT that
   usually creates Endpoint Dependent Mappings or Endpoint Dependent
   Filtering for outgoing connections, since the purpose of an
   (unfiltered) MAP mapping is to receive inbound traffic from any
   remote endpoint, not from only one specific remote endpoint.

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