PCP Working Group

IETF 82, Friday 18 November 2011, 9:00

chairs: Alain Durand, Dave Thaler

notes: Paul Selkirk


PCP Base Protocol status (Dan Wing)

1. Try forever (while you still care): some hums in favor, none opposed


2. Remove UNPROCESSED Option

Francis: this is ambiguous because it doesn't flag the bad option

Dave: in an error, you don't process any option

Stuart: doc should say unambiguously what to do (agree with Francis)

a number of hums in favor, none opposed


3. PEER Delete a Mapping -> can't shorten lifetime below default for implicit mapping

Francis: propose that PEER can't reduce lifetime, full stop; would like clear semantics for querying


PCP Rapid Recovery and other post-WGLC topics (Stuart Cheshire)

1. terminology clarification: implicit/explicit, inbound/outbound

many hums in favor, none opposed


2. clarification of PEER interaction with implicit operation

Dave: intent is that the PEER can't lower lifetime below NAT default

Francis: agree with the slide but not the explanation - NAT should have only one timer per mapping

Stuart: that was an example of how you might implement this behavior

Francis: I agree with the text on the slide

no clear consensus on whether to include example in the doc

Francis: PEER can't extend lifetime beyond NAT default for outbound traffic

Stuart: good that we're having this conversation, because we need to come to an understanding on what PEER does

Dmititri: this can be done with one timer

Senthil: clarification needed about 2-timer example

Dan: need an encouragement in the draft that max be longer than default

Andrew McGregor: draft shouldn't overly constrain implementation

Stuart: PEER should do no harm, and not produce worse result than normal operation

Alain: suggest that we state that time can only flow in one direction: PEER can't reduce lifetime

Dave: two options on the table

a. PEER can't reduce lifetime ever: one objection

b. PEER can't reduce lifetime below NAT default: 4 objections

consensus decision: PEER can only increase lifetime, never decrease it [FIN/RST will still kill mapping]


3. Epoch timing tolerances

Francis: NTP was designed for better computers than commodity devices, propose to loosen timing

Stuart: going by gut instinct without data is risky; we need to cite a reference

Andrew: see 802.3 and 802.15, because they've got the worst clocks in current use

Alain: keep current language until we get countervailing expert advice

many hums in favor, none opposed


4. Rapid Recovery

Francis: this is limited to link-local multicast; would be better if this followed the common header layout (too many too-short checks in packet processing)

Tim Chown: is this purely link-local, or do you want to use a larger-scope multicast?

Stuart: if there's some prospect of site-local doing something useful, then we might consider it

Dan: until we have a DHCP server discovery mechanism, we have no way for this to work on non-link-local

Dave: a future extension document could extend this beyond link-local

Francis: should not be limited to multicast, could have a list of unicast client addresses

Stuart: rapid recovery section is informational normative

Tim: need Homenet WG to advise

Dave: for base spec, doc specifies packet format, SHOULD multicast on a link-local address on a link on which it may have unknown clients

Alain: multicast link-local as described today, could do more: number of hums in favor, none opposed

Alain: 12-byte padding to align to common header format: most people don't care, so rough consensus for padding


Authentication Mechanism (Margaret Wasserman)

Paul: simple threat model is too restrictive

Francis: there is already a NOT_AUTHORIZED result code, bring this doc in line with base spec

Sam: if you implement the authentication option, then you're allowed to accept unauthenticated requests

Sam: either mandatory-to-implement security, or make security no worse than if PCP was not present

Margaret: this is aimed mostly at enterprise deployments, or the coffee shop scenario, not the home network

Sam: EAP scales all the way down to web password, up to existing enterprise infrastructure

Alper: why not use PANA as-is?

Dave: are people convinced that base spec Security Considerations doesn't need changes before sending to IESG?

many hums in favor, none opposed


Francis: not convinced it's a good idea to return NOT_AUTHORIZED to attempt to delete a static mapping - this is the only way a delete request can fail, and it complicates implementations - expensive on the server side, and client won't know what to do with it; suggest changing MUST to MAY

Dan: we already have to look in the static mapping table to return all-ones lifetime

Andrew: that's a SHOULD


Text "

   If the PCP client attempts to delete a single static mapping (i.e., a

   mapping created outside of PCP itself), the error NOT_AUTHORIZED is

   returned. "

should be made aligned with SHOULD/MAY with:

   "If a PCP client sends a PCP MAP request to create a mapping that

   already exists as a static mapping, the PCP server will return a

   successful result, confirming that the requested mapping exists.  The

   lifetime the PCP server returns for such a static mapping SHOULD be

   4294967295 (0xFFFFFFFF)."

   


Alain: authors will update text, publish -18 ASAP, and we'll send it on to the IESG