[pcp] PCP MoM (THURSDAY, November 8, 2012)

["Reinaldo Penno (repenno)" <[e-mail]>]

PCP

THU 1510-1710 =============

Welcome, Agenda bashing                                 (5, Chairs)


Francis Dupont: Adopt DS-Lite document as WG document?  Dave Thaler: Will
post
question on mailing list


    WGLC Results                                        (30)
    draft-ietf-pcp-base                                 (Dan Wing)

Paul Selkirk: The restrictions about delete-all should only apply to the
simple
threat model, not the advanced threat model

Dan Wing: We don't have the text for advanced threat model written yet

Paul Selkirk: But the document still describes delete-all, and then says it
doesn't work

Dave Thaler: Document can reference what's allowed under advanced threat
model,
without specifying how advanced threat model will work

Paul Selkirk: Disallowing delete-all is a loss of functionality compared to
NAT-PMP

Stuart Cheshire: But we decided that functionality was not a good idea

Margaret Wasserman: Document should limit making educated guesses about
what
advanced threat model allows before we know how advanced threat model
works.

Dave Thaler: Document should explicitly state this explicitly, e.g. "If
simple
threat model, then nonce must match; advanced threat model is yet to be
defined"


    draft-ietf-pcp-upnp-igd-internetworking

Paul Selkirk: I have some minor editorial nits with this document, but
overall
it is complete, and has no wacky ideas.


    draft-ietf-pcp-dhcp                               (Mohamed Boucadair)


Stuart: Why name rather than IP address?

Ralph: Use RFC 1035 encoding for forward compatibility with changes to
DNS, e.g.
internationalization.  Dave: RFC 1035 restricts us to DNS names.  Strings
are
not DNS names, pass string to name resolver, not specifically DNS resolver.

Stuart: We should make a decision, should not accept non-fully qualified
domain
names (including trailing '.').

Stuart Cheshire: Should fit in with existing DHC conventions Mohamed
Boucadair:
This issue is closed; this WG and DHC have already approved this

Ralph Droms: Really? DHC discussed this only this morning.

Stuart Cheshire: Whatever it says, the document needs to be unambiguous

Pete Resnick: Is what the DHCP server hands out protocol, or is it
presentation
layer that gets translated into protocol? If it's protocol, define it
tightly.
If it's presentation layer, you have to deal with all kinds of translation
issues.

Dave: It's protocol.

Stuart: If we require the client to validate the name, we have to say how,
but
it's okay to remove the restriction in the first place.


Stuart: Happy to defer to DHC WG about how to convey multiple strings.
(e.g.
single option with null separators or space separators.)

Dan: Embedded nulls make me nervous, because poorly-written clients pass
strings
to things like strcpy().

Ralph: Multiple options or multiple sub-options are the norm in DHCP
(including
v6).

Dave Thaler: In DHCPv4, multiple options are concatenated, so even with
multiple
options a separator or length prefix is still necessary

Med to consult with Ted Lemon. If no objection, adopt Stuart's proposal for
length byte followed by string, optionally followed by more counted
strings?



Optimizing NAT and Firewall Keepalives Using PCP      (10, Markus Isomaki)
draft-reddy-pcp-optimize-keepalives

Keepalive Incentive Issues                            (10, Dave Thaler)
(draft-ietf-pcp-base, draft-reddy-pcp-optimize-keepalives)

Dave: Should we recommend that middleboxes give longer mapping timeout as a
result of using PCP than for connections without PCP?  If so, in which
doc?  If
not, what's the point of mentioning it in the spec?

Gang: Reducing keepalives beneficial not only to power, but to reducing
congestion on the air interface.

Stuart: Usefulness of timeout detection algorithms is unproven.  You're
assuming
the lifetime of two different mappings is the same.  You're assuming
there's a
stable lifetime in the first place.  PEER gives the client a defined,
committed
lifetime, so this gives you more reliability.

Markus: Timeout detection algorithms are known to fail. This may make them
more
reliable.

Reinaldo: This could give us a way to detect not just the first middlebox,
but
other on-path middleboxes as well.

Simon: We don't have any operational experience with this, so making a
recommendation may be premature.  Dave: There are documents in the IESG
that are
requiring use of PCP for power saving.

Q1: Should there be a statement in some document? Strong hum in favor, none
opposed.  

Q2: Should this statement be in pcp-base? Strong hum in favor, none
opposed.

Ask on list for objections.


Using PCP to control NAT and Firewalls in Multihoming (10, Tiru Reddy)
    draft-patil-pcp-multihoming-00

PCP Server Selection                                  (10, Mohamed
Boucadair)
    draft-boucadair-pcp-server-selection

Tiru Reddy: Propose merging the two documents

Dave: draft-boucadair-pcp-server-selection is a new non-WG document, but
all the
text is from a prior version of the dhcp document, which was accepted as a
WG
document, so the assumption is that this will be accepted as a WG document.

Dave: We could choose to combine these two documents, or say that server
selection stands on its own, and the multihoming draft just covers use
cases.
Prashanth: In favor of merging documents.

Will call on list for objection to adopting as WG document.


Retrieving the Capabilities of a PCP-controlled Device
draft-boucadair-pcp-capability                        (10, Tiru Reddy)

Dave Thaler: Yes, this is a valid problem. Clients may need to tailor
behavior
depending on whether server is NAT or Firewall

Margaret Wasserman: Question is not as simple as "NAT or Firewall?" Things
are
not strictly NATs or firewalls, and the lines can be blurred so much that
you
can't give a meaningful answer.  Very seldom in favor of any
capability-discovery mechanism because they cause unnecessary failures.

Stuart Cheshire: Problem is interesting, but we need to get some
operational
experience before we can say what is the right answer Dan Wing: Agree that
capability discovery is fragile. Taxonomy of NAT vs. Firewall is too
simplistic.


Learn NAT64 PREFIX64s using PCP                       (10, Mohamed
Boucadair)
    draft-boucadair-pcp-nat64-prefix64-option

Dave Thaler: BEHAVE WG has a heuristic for this, which may not work in all
cases

Dan Wing: Should we ask BEHAVE WG to reference this solution?

Dan Wing: Have you done a comparison of the BEHAVE heuristic compared to
the PCP
message?

Mohamed Boucadair: Haven't done a detailed comparison with heuristic.
People
agree PCP is better

Dave Thaler: If DHCP and PCP answers differ, then trust the PCP server --
it
ought to know

Tiru Reddy: PCP version also gives you the lifetime

Dave Thaler: Call for adoption: strong hums in favor, none against.



Analysis of PCP in Mobile Networks draft-chen-pcp-mobile-deployment
(10, Mohamed Boucadair)

Margaret Wasserman: Why would we run PCP differently in mobile networks?
What
makes mobile networks different?

Mohamed Boucadair: It's guidance for network operators Reinaldo: Server
discovery may be different, may not be your default gateway.  Gang Chen:
Mobile
networks are different Margaret Wasserman: What makes PCP server discovery
different

Stuart Cheshire: 3GPP does not use DHCPv4, so it's not that "mobile" is
different, it's that we have to define how to do PCP server discovery on
3GPP

Stuart Cheshire: Apple Airport will act on any PCP request it sees,
regardless
of destination addr/port. So the solution may be anycast.



Using PCP To Coordinate Between the CGN and Home Gateway Via Port
Allocation
draft-tsou-pcp-natcoord-08                            (10, Simon Perreault)


Alain Durand: Is this for PEER or only MAP?  Simon Perreault: Only MAP
Alain: I
don't buy the no-DHCP argument. Also, is this idempotent?  Simon: If you
retransmit the same request with the same nonce, you get the same port
set. If
you transmit a new request with a new nonce, you get a different port set.

Dave: Is this only for NAT44, or can it be extended to NAT64?  Simon: This
works
the same for NAT44, NAT64, NAT66, etc.

Call on list for adoption.

Dave: Thanks to Alain for his service.


=== END ===