Subject: [pcp] draft-ietf-pcp-base-00

From: "Dan Wing" <[email-masked]>
Date: Fri, 3 Dec 2010 14:24:57 -0800

I just posted draft-ietf-pcp-base-00, 
http://tools.ietf.org/html/draft-ietf-pcp-base-00,
which has very small changes from draft-wing-pcp-base-01,
such as removing most text discussing using same port as
NAT-PMP (I didn't fix all occurrences), 

Side-by-side diffs between them are at:
http://tools.ietf.org//rfcdiff?url1=http://tools.ietf.org/id/draft-wing-pcp-
base-01.txt&url2=http://tools.ietf.org/id/draft-ietf-pcp-base-00.txt
or http://tinyurl.com/2byejy3

Changes I intend to make for -01 include the following, which are
my understanding of the consensus from the face-to-face meeting
at IETF79, mostly from my presentation at 
http://www.ietf.org/proceedings/79/slides/pcp-2.pdf and chair's
presentation at http://www.ietf.org/proceedings/79/slides/pcp-4.pdf

If there are suggestions / objections / comments to the above, please
share them now.  

  * 'mandatory' semantic.  I plan to define a PCP option which
    requires the server to map to the requested-external-port (but not
    IP address?), or else return an error.  This is primarily to
    optimize server operation when some device within the subscriber's
    network is interworking from UPnP IGD to PCP.

  * ICMP, for the associated flow, will be opened as a side-effect of
    using PCP to permit inbound TCP/UDP.

  * defer firewall until later, or to a separate document.  (I would
    like to discuss this on the list.)

  * If PCP lifetime expires while there is still inside->outside data,
    the mapping is not abruptly terminated.  Instead, it continues to
    live on.  This is part of the "a PCP mapping is identical to a
    normal mapping" philosophy.

  * multihoming is deferred to later, or to another document

  * will not add support to request multiple ports

  * Add EVEN_PLUS_ONE functionality, primarily for RTP+RTCP. This will
    be done with a PCP option ("IE"; see below for reasons why I am
    considering renaming "IE" to "Option").

  * PCP server discovery:  I don't recall a meaningful consensus.  We
    should discuss on the list.

  * PCP encapsulation for DS-Lite (over IPv6 versus over UDP): I don't
    recall a meaningful consensus.  We should discuss on the list.

non-technical editing:
  * incorporate feedback (against draft-wing-pcp-base-01) received
    from Francis Dupont, Dave Thaler, and Mohamed Boucadair.

  * solidifying request/response behavior for client and server, to
    more clearly separate the behavior from the currently-defined
    OpCodes.  This will make it clearer how new OpCodes can be
    defined, and help client and server implementations not get
    tied into the operation of the currently-defined OpCodes.

  * rename IE (Informational Elements) to Options.  This is because
    they are not purely informational -- they change behavior.  DHCP,
    IP, and TCP all use "options", so this term seems a reasonably 
    generic and also well-understood.

-d

---

From: Dave Thaler <[email-masked]>
Date: Fri, 3 Dec 2010 22:38:13 +0000

Some comments...

[...]
>     like to discuss this on the list.)
[...]

Unless this is resolved prior to the upcoming interim call,
I would like to spend a bit of time on this on the call.

>From the raw minutes (thanks Paul, we will post the combined minutes
from Paul/Stuart shortly):

    requesting multiple ports
    rtp only? likes even/odd ports
    proposed - IE called EVEN_PLUS_ONE

    alain: asked how important this is
    current apps can use other than even/odd

My recollection (perhaps faulty) of the last point was that the conclusion
was we didn't need to define anything.  Perhaps an RTP expert on this
thread can restate the conclusion?

>     should discuss on the list.

We did not call the consensus in Beijing or get into a deep discussion.
We just said we'd like to narrow the list to a small number, perhaps 2.
So yes we need more discussion.

[...]

-Dave

---

From: Francis Dupont <[email-masked]>
Date: Sat, 04 Dec 2010 23:00:07 +0100

In your previous mail you wrote:

=> IMHO there is no reason to not add the (requested-external) IP
address here. This makes the option more useful than for UPnP IGD 1.0
IWF only.

   
=> as I explained during the Beijing meeting, this is about the NAT
internals so is more in the scope of BEHAVE. BTW if there is a reference
(it should be :-) I prefer to get only a pointer.

     * If PCP lifetime expires while there is still inside->outside data,
       the mapping is not abruptly terminated.

=> I deeply object: if someone wants to keep the entry (s)he should
simply renew it.

       This is part of the "a PCP mapping is identical to a
       normal mapping" philosophy.
   
=> this philosophy is based on the fact mappings are EIM/EIF but
this fact is not true in the real world, so I don't buy the philosophy
(or its consequences).

Thanks

[email-masked]

PS: have you a plan to publish an updated version before the interim
meeting?

---

From: Reinaldo Penno <[email-masked]>
Date: Mon, 6 Dec 2010 18:59:09 -0500

> this fact is not true in the real world, so I don't buy the philosophy

I do not see the connection between inside->outside mappings not expire and
whether they are EIM/EIF.

BTW, why do you say mappings are not EIM/EIF in the real world?

---

From: Tina Tsou <[email-masked]>
Date: Mon, 06 Dec 2010 16:38:38 -0800

I reviewed the draft-ietf-pcp-base-00.
Comments are inline.

Best Regards,
Tina TSOU
http://tinatsou.weebly.com/contact.html

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dan
Wing
Sent: Friday, December 03, 2010 2:25 PM
To: [email-masked]
Subject: [pcp] draft-ietf-pcp-base-00

  * 'mandatory' semantic.  I plan to define a PCP option which
    requires the server to map to the requested-external-port (but not
    IP address?), or else return an error.  This is primarily to
    optimize server operation when some device within the subscriber's
    network is interworking from UPnP IGD to PCP.
[Tina: I understand that UPnP IGD and NAT-PMP don't support requested
external IP, so the request packet from the user should not carry the
external IP.
But I don't quite understand why to define a new option. It seems to me the
old option can work.]

  * will not add support to request multiple ports
[Tina: I did not see related discussion. Why? I'm curious to know how you
consider it.]

non-technical editing:

-d

_______________________________________________
pcp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pcp

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 6 Dec 2010 17:20:42 -0800

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Tina Tsou
> Sent: Monday, December 06, 2010 4:39 PM
> To: [email-masked]
> Subject: Re: [pcp] draft-ietf-pcp-base-00
> 
> But I don't quite understand why to define a new option. It seems to me
> the old option can work.]

I believe you are referring to my parenthetical comment "but not
IP address?".  It's true, that when sending the first PCP request
the PCP client will not know the public IPv4 address the PCP server
will allocate.  There are at least two ways to deal with that
situation:

  1. Allow a Mandatory mapping to include an external-ip-address
     with a sentinel value to mean "any public address".  For
     example, the requested-ip-address of 0.0.0.0 could be that
     sentinel value.
  2. Don't worry about this problem.

(1) is slightly more complex, as it creates yet another sentinel
value in the protocol (we have one for "delete mapping" (lifetime=0),
another for "any port" (port=0), and another for 'delete all
mappings' (external-port=0 and internal-port=0 and lifetime=0).  But 
a value of all zero's for requested-external-ip address is 
pretty straight forward.

> [Tina: I did not see related discussion. Why? I'm curious to know how
> you consider it.]

http://tools.ietf.org/html/draft-wing-softwire-port-control-protocol-02
included the ability to request multiple ports.  Requesting multiple
mappings is an optimization to reduce PCP request/response messages.
PCP is trying to stay as simple as possible to finish the specification
soon and to keep implementations as simple as possible to meet the
basic needs for port mapping -- and keeping it similar to how TCP
and UDP create mappings in NATs (which is done one port at a time) 
goes a long ways towards that goal.

I haven't found many protocols that would have much benefit from
this optimization, though.  Web servers need two ports (HTTP and 
HTTPS), IMAP and POP servers also need two ports (for their 
unencrypted and encrypted variants) -- but getting a webserver 
or mail server running is not time- or bandwidth-critical.  RTP
needs two ports (RTP+RTCP; separate issue if they need to 
be adjacent) and it is time critical.  However, an application
using RTP can pre-allocate its ports (at application startup)
using PCP so this is not important, either.  And the 4 PCP
messages (to allocate two ports at application startup) are not 
significant compared to the RTP traffic (when a call is active) 
or to the application-level SIP (or Skype) keepalive traffic.

Is there an application protocol that would benefit from the
ability to get 2, 3 or 10 ports in one PCP message?  If so,
let's talk about that application protocol and understand how
it could benefit.

-d

---

From: Francis Dupont <[email-masked]>
Date: Wed, 08 Dec 2010 16:25:13 +0100

=> the connection is the philosophy "a PCP mapping is identical to a
normal mapping". From a security point of view this is true only for
EIM/EIF mappings.

=> because there are not in general according to studies (EIM/EIF is
between 20 and 40%, so is not even the majority).
IMHO this comes from 3 reasons:
 - NAT implementors just ignore BEHAVE recommendations
 - Linux netfilter (very common in home NATs) is not EIM/EIF
 - awared users/implementors prefer security over NAT traversal
BTW you can argue CGNs could be different but I am afraid port
randomization will be required for CGNs so again security will be
prefered over NAT traversal.

Regards

PS: as an implementor I have a neutral opinion: EIM/EIF is marginally
simpler but experiences have shown NAT traversal works well for
important applications with any kind of NATs.
PPS: about the termination issue IMHO the best is to not specify something.
BTW I'll object if the current option will be required or recommended.