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

[Dave Thaler <[e-mail]>]

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:[e-mail]]
> Sent: Thursday, September 20, 2012 11:36 AM
> To: [e-mail]
> Cc: [e-mail]
> 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.
> 
> 
> 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