Subject: Re: [pcp] base #9 (assigned): Are PCP-created mappings different from TCP SYN-created ones

From: "pcp issue tracker" <[email-masked]>
Date: Tue, 08 Feb 2011 18:20:06 -0000

#9: Are PCP-created mappings different from TCP SYN-created ones

Comment(by dwing@…):

 In -03, different OpCodes were created for incoming connections versus
 extending the lifetime of an existing session.  In -03, they were called
 PIN and PEER.  In -04, PIN was renamed to MAP (and simplified).

 The PEER OpCode is exactly like a normal TCP SYN -- in that sense, it is
 exactly the same as a dynamically-created mapping, the only difference is
 learning the timeout of the mapping.  No new or exciting security exposure
 with PEER.

 The MAP OpCode, however, is different.  The PCP request describes the port
 on the local host for the mapping.  It might include the THIRD_PARTY
 option to describe another host belonging to the same subscriber.  In both
 cases, this is different from a normal dynamic connection.

-- 
--------------------------------+-------------------------------------------
 Reporter:  dwing@…             |       Owner:  dwing@…        
     Type:  defect              |      Status:  assigned       
 Priority:  major               |   Milestone:                 
Component:  base                |     Version:                 
 Severity:  Active WG Document  |    Keywords:                 
--------------------------------+-------------------------------------------

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

---

From: Francis Dupont <[email-masked]>
Date: Wed, 09 Feb 2011 13:46:46 +0100

>   cases, this is different from a normal dynamic connection.

=> IMHO the main difference is if the NAT doesn't implement EIM/EIF then
the security properties are critically different, i.e., it is far easy for
an attacker to (ab)use a PCP mapping (called explicit dynamic mapping in
base-04) than a (implicit) dynamic mapping.

Regards

[email-masked]

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 9 Feb 2011 08:01:38 -0800

> base-04) than a (implicit) dynamic mapping.

An attacker, running a PCP client on the victim host, to open NAT
(or firewall) mappings, so that the attacker can send packets from
the Internet to the victim host?

-d

---

From: Francis Dupont <[email-masked]>
Date: Thu, 10 Feb 2011 00:04:08 +0100

In your previous mail you wrote:

   > it is far easier for an attacker to (ab)use a PCP mapping (called
   > explicit dynamic mapping in base-04) than a (implicit) dynamic
   > mapping.
   
   An attacker, running a PCP client on the victim host,

=> no, an attacker in the Internet.

   so that the attacker can send packets from the Internet to the
   victim host?

PS: I don't understand why I have to discuss about it:
it is in the EIF specs (in the reason of not requiring
unconditionally EIF).

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 9 Feb 2011 19:32:28 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, February 09, 2011 3:04 PM
> To: Dan Wing
> Cc: 'pcp issue tracker'; [email-masked]
> Subject: Re: [pcp] base #9 (assigned): Are PCP-created mappings
> different from TCP SYN-created ones
> 
> 

Because I don't understand the attack vector.  Maybe someone
else understands the attack vector you're describing. 

-d

---

From: Francis Dupont <[email-masked]>
Date: Thu, 10 Feb 2011 14:41:27 +0100

=> from RFC 4787:

      Filtering independently of the external
      endpoint is not as secure: An unauthorized packet could get
      through a specific port while the port was kept open if it was
      lucky enough to find the port open.  In theory, filtering based on
      both IP address and port is more secure than filtering based only
      on the IP address (because the external endpoint could, in
      reality, be two endpoints behind another NAT, where one of the two
      endpoints is an attacker).
   
This explicitely states EIF is less secure than APDF.

Regards

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 10 Feb 2011 09:03:04 -0800

> Sent: Thursday, February 10, 2011 5:41 AM
> To: Dan Wing

*Nodding agreement*.

So you're saying that a PCP-created mapping, because it allows any
host on the Internet to send a packet to the host, creates a security
vulnerability.

But that is what happens when a host wants to run a server, on
today's Internet (without a CGN and without PCP):  the host has to
accept incoming connections from hosts on the Internet.  That is,
after all, the definition of "running a server".

PCP's MAP OpCodes are intended to support that.  That's their job,
that is why they exist, and that's why we have those PCP OpCodes.

I hope to have time, today, to craft some text for the Security
Considerations section so that instead of going back and forth
in email we can have straw man text to discuss.  That's the only
way to make forward progress.

-d

---

From: Francis Dupont <[email-masked]>
Date: Thu, 10 Feb 2011 19:24:28 +0100

*Nodding agreement*.

=> when a NAT is not EIM/EIF, an explicit dynamic mapping is
more vulnerable than an implicit dynamic mapping, just from
the different filtering. (*)

=> yes, I don't say explicit dynamic mappings are bad from
the security point of view (but some argued this at the last IETF),
just when a NAT is not EIM/EIF...

   
=> I updated my security model so you should get some material
(and take benefit of your timezone :-).

Regards

PS: (*) port randomization is another point. It can be considered
as a needed security feature (in fact it is as soon as one understands
what is it), is not very compatible with EIM and of course doesn't
make a lot of sense for explicit dynamic mappings (and no sense
at all for static mappings).

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 10 Feb 2011 10:43:49 -0800

> Sent: Thursday, February 10, 2011 10:24 AM
> To: Dan Wing

Agreed.

But how else to run a server, other than to accept connections
from anywhere?  

And there is the REMOTE_PEER_FILTER option, if the PCP client 
wants to offload some of its filtering to the PCP-controlled 
device.  But that of course requires the PCP client to know
the IP address(es) (or, in -05, the prefix(es)) of the remote
peer(s).  Which of course is not always possible.
 
> (and take benefit of your timezone :-).

Yeah, I'm reading through it now.  Thanks.
-d

---

From: "pcp issue tracker" <[email-masked]>
Date: Tue, 01 Mar 2011 01:08:21 -0000

Changes (by dwing@…):

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

Comment:

 Tried to walk a line here.  Strawman text is as follows:

 new text in the Server Processing section:
 {{{
       Note: it is implementation-specific if the PCP-controlled device
       destroys the mapping when the lifetime expires, or if
       inside->outside traffic keeps the mapping alive.
 }}}

 and new text in the Client Processing section:

 {{{
    If the PCP client wishes to keep this mapping alive beyond the
    indicated lifetime, it SHOULD issue a new PCP request prior to the
    expiration.  That is, inside->outside traffic is not sufficient to
    ensure the mapping will continue to exist.  It is RECOMMENDED to send
    a single renewal request packet when a mapping is halfway to
    expiration time, then, if no positive response is received, another
    single renewal request 3/4 of the way to expiration time, and then
    another at 7/8 of the way to expiration time, and so on, subject to
    the constraint that renewal requests MUST NOT be sent less than four
    seconds apart (a PCP client MUST NOT send an infinite number of ever-
    closer-together requests in the last few seconds before a mapping
    expires).
 }}}

-- 
--------------------------------+-------------------------------------------
 Reporter:  dwing@…             |        Owner:  dwing@…        
     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/9#comment:4>
pcp <http://tools.ietf.org/pcp/>