Subject: [pcp] pcp-base-27: Mapping Nonce change

From: "Dan Wing" <[email-masked]>
Date: Thu, 20 Sep 2012 11:35:41 -0700

Based on IESG feedback and coordinating these changes with
draft-ietf-behave-lsn-requirements, an updated version of pcp-base has been
posted.  The proposed change to Mapping Nonce was announced on August 17,
"strengthening PCP with Mapping Nonce",
http://www.ietf.org/mail-archive/web/pcp/current/msg02229.html.

The significant changes are:

1. Once a MAP or PEER opcode is processed by the PCP server, subsequent
changes to that mapping have to use the same Mapping Nonce.  This closes the
attack that led to REQ-9-A in draft-ietf-behave-lsn-requirements-09.  

However, this change has a side-effect of disabling two previous MAP
features:  (a) the ability of a PCP client to delete (clear) PCP mappings
created by a previous PCP client using the same IP address, and (b) ability
for a PCP client to delete all of the mappings it created by sending one MAP
message.  To accommodate the loss of (a), pcp-base-27 recommends that when a
host joins a network, the network device that allowed the device to join the
network should flush PCP-created mappings and non-PCP-created mappings
(e.g., DHCP, 802.1x, PPPoE).  Towards that end, Stuart has written
draft-cheshire-pcp-expire, and there are many other ways to clear PCP and
implicit mapping state in NATs and firewalls when a device joins a network.
(b) was just an optimization; the PCP client can delete MAP created mappings
by issuing separate requests, similar to how it issued separate MAP requests
to create the mappings.

2. Clarified that PEER can reduce a mapping lifetime to the same lifetime as
active, bi-directional traffic.  This allows PEER to extend lifetime of a
mapping, then later using the same Mapping Nonce, PEER can rescind (revert)
that lifetime extension so the mapping is treated as if PEER was never used.

Another significant change, unrelated to Mapping Nonce, is that Mapping
Update is now required.  This means the PCP server now MUST inform the PCP
client of any changes to a mapping; earlier versions of the specification
said this was merely a SHOULD.  This change makes PCP a more reliable
protocol.

There are a lot of other minor changes from IESG feedback and from other
reviewers.  See the changelog in Section B.1, or the side-by-side diffs.

URL:
http://www.ietf.org/internet-drafts/draft-ietf-pcp-base-27.txt
Status:          http://datatracker.ietf.org/doc/draft-ietf-pcp-base
Htmlized:        http://tools.ietf.org/html/draft-ietf-pcp-base-27
Diff:            http://www.ietf.org/rfcdiff?url2=draft-ietf-pcp-base-27

-d

---

From: Dave Thaler <[email-masked]>
Date: Thu, 20 Sep 2012 23:37:03 +0000

Thanks Dan for the nice summary.   Hopefully we can have a good discussion
on the call tomorrow, primarily on #1 (the security point).

-Dave

> -----Original Message-----
> From: Dan Wing [mailto:[email-masked]]
> Sent: Thursday, September 20, 2012 11:36 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: pcp-base-27: Mapping Nonce change
> 
> Based on IESG feedback and coordinating these changes with draft-ietf-
> behave-lsn-requirements, an updated version of pcp-base has been posted.
> The proposed change to Mapping Nonce was announced on August 17,
> "strengthening PCP with Mapping Nonce", http://www.ietf.org/mail-
> archive/web/pcp/current/msg02229.html.
> 
> 
> changes to that mapping have to use the same Mapping Nonce.  This closes
> the attack that led to REQ-9-A in draft-ietf-behave-lsn-requirements-09.
> 
> created by a previous PCP client using the same IP address, and (b) ability for
> a PCP client to delete all of the mappings it created by sending one MAP
> message.  To accommodate the loss of (a), pcp-base-27 recommends that
> when a host joins a network, the network device that allowed the device to
> join the network should flush PCP-created mappings and non-PCP-created
> mappings (e.g., DHCP, 802.1x, PPPoE).  Towards that end, Stuart has written
> mapping, then later using the same Mapping Nonce, PEER can rescind
> (revert) that lifetime extension so the mapping is treated as if PEER was
> never used.
> 
> 
> Update is now required.  This means the PCP server now MUST inform the
> PCP client of any changes to a mapping; earlier versions of the specification