Subject: [pcp] #52: More security considerations

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

#52: More security considerations

 Section 13.1 (Denial of Service) needs discussion of additional vectors.

 Another DOS vector is via spoofing a SERVER_OVERLOADED response and
 sending it to a victim, since per section 6.3:
 > If the result code is SERVER_OVERLOADED, clients SHOULD NOT send
 > *any* further requests to that PCP server for the indicated error
 > lifetime.

 Another DOS vector is by spoofing a victim’s IP and deleting all their
 mappings.

 Another vector is by spoofing a victim's IP and refreshing their mappings,
 thereby consuming bandwidth/CPU at the victim (or the next victim to get
 the same IP address).  The rule in section 8.6:
 > When a PCP client first acquires a new IP
 > address (e.g., reboots or joins a new network), it SHOULD remove
 > mappings that may already be instantiated for that new Internal
 > Address.
 would, if the SHOULD is followed, simply result in the "refresh" being a
 "recreate".  The "recreate" is mentioned in 13.2 but needs text in 13.1 to
 call it out as a DoS vector.

 Finally, section 13 says:
 > The MAP OpCode allows
 > creating a mapping so a host can receive incoming unsolicited
 > connections from the Internet in order to run a server.

 Should probably note that this is wider than what can be done with a TCP
 SYN and hence in some environments may be considered a security issue.
 It should probably be legal for such deployments to have a PCP server
 accept PEER but not MAP.  This allows some uses (Reducing NAT Keepalive
 Messages, Restoring Lost Implicit TCP Dynamic Mapping State) but not
 others (Operating a Server).

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

Ticket URL: <http://trac.tools.ietf.org/wg/pcp/trac/ticket/52>
pcp <http://tools.ietf.org/pcp/>

---

From: "pcp issue tracker" <[email-masked]>
Date: Tue, 07 Jun 2011 13:52:56 -0000

Comment(by dthaler@…):

 Stuart Cheshire writes:
 > 16. Saying that an "Ethernet switch needs to perform ingress filtering"
 seems
 > to be putting unreasonable demands on devices that know nothing about
 PCP, NAT,
 > or even IP.

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

---

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

Comment(by dthaler@…):

 Stuart:
 > 6. Security for the THIRD_PARTY option needs more detailed
 specification.

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

---

From: "pcp issue tracker" <[email-masked]>
Date: Tue, 07 Jun 2011 15:30:11 -0000

Comment(by dthaler@…):

 7 June:
 Dave - add mitigation that MAP can be disabled if admin chooses, since
 hole is wider than SYN can do, if SYN doesn't create EIF.
 Stuart - home gateway should only accept PCP on the internal interface

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

---

From: "pcp issue tracker" <[email-masked]>
Date: Thu, 23 Jun 2011 05:06:34 -0000

Comment(by cheshire@…):

 I've added text about ingress filtering, security for the THIRD_PARTY
 option, configuration options to disable MAP and PEER support, and only
 accepting PCP request on the internal interface.

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