[pcp] IETF 81 WG minutes

[Dave Thaler <[e-mail]>]

It appears that the minutes from IETF 81 hadn't been posted to the list yet.
However, better late than never, so here they are (notetakers were Paul Selkirk
and Stuart Cheshire).

Notably, we agreed to adopt draft-bpw-pcp-dhcp and draft-bpw-pcp-upnp-igd-interworking
as WG documents.

-Dave

PCP Working Group
IETF 81, Quebec City, July 2011

Tuesday, 13:00-15:00, 208 AB
(conflicts: paws, dnsop, netmod, rtcweb, pim, emu, alto)

Chairs: Alain Durand [e-mail], Dave Thaler [e-mail]

Jabber room:  xmpp:[e-mail]?join


Chairs
------
Dave Thaler gave plan for meeting: Wrap up base spec before getting to 
other documents

Issued WGLC on -12, got comments, issued -13, got more comments.
Chairs and authors worked through those comments, would like to rev -14 
ASAP.

Aside from the working group: there is a PCP demo in the terminal room, 
Monday and Wednesday at 8 AM.

Security Considerations (Margaret Wasserman)
--------------------------------------------

Margaret presented new Security Considerations Section, which was emailed to
    the list last night (see "Re: [pcp] #52: More security considerations",
    Tue, 26 Jul 2011 02:56:13 -0400)

Existing text was a collection of considerations, but not an overall framework.
Security goal is to limit new threats that don't exist with implicit mappings.
Added a section on attacks against server discovery.
Dave: we don't define discovery mechanisms in the base spec, so we can 
    put specific language in the DHCP/etc doc to address threat model 
    identified in the base spec.

PCP Base spec issues (Dan Wing)
-------------------------------
1. Keep MAP and PEER opcodes separate

No objection from room

2. No explicit op for just getting an address without a mapping

Francis: suggested partial solution is to set external addr field in all 
    responses, if there is a known external addr.
Stuart: would make sense for small-scale nats, but not for large-scale 
    nats with address pool
Alain: make two cases - one addr, multiple addrs
Simon: suggest set lifetime to remaining lifetime in the nat
Francis: iwf needs to know public address asap
Dan: you can learn that by creating a mapping
Alain: this is germane to the iwf, not the base spec
Stuart: standard nat-pmp library does external address lookup concurrently 
    with requesting a mapping
Dan: cgn with address pool has to return 0
Simon: if the cgn has already bound the subscriber to a specific public 
    address, it can return it
Alain: it's okay to always return 0, or public address if available 
James Woodyatt: if the cgn always returns 0, client implementors will 
    make a dummy mapping for e.g. port 9.  would rather have the spec 
    say that server should only return 0 if it doesn't have an assigned 
    external address.
Stuart: if i'd already made a port request, i'd know the external address; 
    if not, i wouldn't have an assigned external address
Alain: could have nat mapping state from outgoing traffic
Dave: given that this operation is not something we want to encourage, 
    we shouldn't put it in the base spec, but leave it to the iwf doc 
    to specify how the compatibility function works.
Keith Moore: had a suggestion in this space a couple years ago.
    There are some kinds of NAT for which asking for the external 
    address is a meaningless question
Dave: there isn't a use case for this beyond IWF 
Dan will summarize for the doc.

Consensus: Every response should include an external address field, and 
    return it in the case that exactly one external IP address is configured 
    on the PCP server.

3. Client MUST have exclusive use of Internal Port before using MAP

Francis: "map is a subset of implicit mappings" is a wish, not true in 
    the real world.  Also, there is no way to enforce that the client 
    has exclusive use of a port, so server should be prepared for collisions.
Simon: this scenario is that client needs to accept inbound connections, 
    but previously made an outbound connection; should be rare, so a 
    kludgy solution is okay.
Dave: implementation decision how to handle collisions; applicability statement
Stuart: we don't need to care about this, because this can happen 
    without NAT or PCP
Dave: you're actually agreeing

Consensus: Okay, this is good guidance for clients.

4. PEER opcode implies PREFER_FAILURE

Francis Dupont: Error code in this case should be the "cannot allocate 
    external port" error
Stuart: CANNOT_PROVIDE_EXTERNAL_PORT

5. Clarify: MAP is EIM/EIF; PEER is implementation dependent

No objection

6. Clarify Implicit/Explicit/Static 

Static > MAP > PEER > implicit

No objection

Francis: for static mappings, return lifetime UINT32_MAX
Francis: can PEER delete mappings?
Dave: that's reducing lifetime to 0, which is not allowed
Francis: if we allow deleting implicit mappings, then it must be done with PEER
Dan: no use case

7. Multiple PCP Servers
"pick one"
Dan: may be a follow-on document with specific use cases and approaches

Dave: please send any further review comments ASAP


Further issues:

1. Make a generic error code meaning "resource exhaustion or some other 
    unspecified but temporary failure -- try again in while"

   Resurrect PROCESSING_ERROR.


2. Show example of v6-only client using NAT64

    Margaret: do we still need separate opcodes for v4 and v6?
    Dan: industry has a poor history of dealing with NAT64, etc.
    V6-only host might be behind a v6 firewall and a NAT64, want to specify 
        whether it's opening a firewall hole or nat mapping
    Margaret: AF is implied in the address format; even zero address is 
        AF-specific
    Stuart: I like margaret's suggestion; willing to make that change in the 
        doc, by friday next week.
    Alain: 1-week WGLC will begin then

    Francis: want an example for setting client's address in DS-lite 
        plain ipv6 mode


3. Clarify "not authorized for third-party" error code generation -- if 
    there's some other error with the request *and* it's also "not 
    authorized for third-party" then return "not authorized for 
    third-party" so as not to information.

   Keep NOT_AUTHORIZED and UNAUTH_THIRD_PARTY_INTERNAL_ADDRESS as separate 
   result codes, shorten the textual name, explain precedence.


DHCP and DHCPv6 Options for PCP (Dan Wing)
------------------------------------------
draft-bpw-pcp-dhcp-04

FQDN instead of address option for a variety of reasons
Is PCP name strictly an FQDN, or a general string such as can be passed 
to getaddrinfo? e.g. is "10.0.0.1" address literal allowed?

Dave: shouldn't be overspecified as a "DNS name", which restricts how it 
    can be resolved
Simon: should be a string that can be passed to getaddrinfo()
Keith: getaddrinfo behavior is undefined or underdefined
Alain: there's a precedent: DS-lite tunnel discovery option
Stuart: in reality, implementations will call getaddrinfo also make it 
    explicit that a dotted-decimal string is acceptable
Dan: softwire option is underspecified, and we shouldn't use it as a model
Maragaret: we should give guidance, but not specify how resolution happens
James: if you specify that this must be resolved with DNS, then you have 
    to require that the client use the configured servers
Francis: just say hostname, which is an ASCII string
Dave: key question is not the internationalization problem, but whether it 
    is constrained to just DNS

Consensus: Yes, general strings such as can be passed to getaddrinfo, 
    including address literals.

No one opposed to taking this as a working group item; at least half the 
    room in favor

Francis requests a DS-lite document be accepted; Alain requests that one 
    be written.


UPnP-IGD IWF (Francis Dupont)
-----------------------------
draft-bpw-pcp-upnp-igd-interworking-02

Open question #1: how to support GetListOfPortMappings
Dave: 2 cases you might be in: iwf has full knowledge of mappings, or it 
    doesn't; if not, then is there harm in returning only the local table?
Stuart: doesn't matter if the information isn't correct at all times, 
    because it's not an atomic information, can change between query and 
    taking some action

Open question #2: how to support DeletePortMappingRange

Open question #3: reboot/resynchronization suggest GET/NEXT
Dave: how is this different from a local UPnP server crashing?
Francis: local UPnP servers is colocated with NAT, so all state is lost 
    on crash, but CGN still has state, and only IWF has lost state
Stuart: seems like we're doing a lot of work to make IGDv1 more reliable 
    than it is today, where it would be less work to use IGDv2 or PCP
Alain: no reason to try for a perfect solution or a solution that's 
    better than what we have today
Dave: at IETF80, we decided that the application is authoritative about 
    whether mapping state is needed, so push state refresh from client, 
    rather than pull from server

Open question #4: UPnP creates longer mappings than PCP allows
Stuart: we don't do anything today, so we don't need to do anything
Xiaohong: today's UPnP client does a get request to find out if last port 
    used is still available, then request a new one
Margaret: a lot of these issues are because PCP doesn't handle these 
    cases; apps have to deal with failures
Alain: sense of the working group is to do nothing


Alain asked for WG consensus on adopting this document

No hands for "NO"

10 hands for "YES"

-- END