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

["Dan Wing" <[e-mail]>]

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