Subject: Re: [pcp] WGLC: draft-ietf-pcp-port-set-03.txt comments due by NOV 5

From: Dave Thaler <[email-masked]>
Date: Wed, 30 Oct 2013 22:33:13 +0000

My comments are in the marked up copy at
http://research.microsoft.com/~dthaler/draft-ietf-pcp-port-set-03.pdf
(also a .docx version in same place)

Summary of main comments:

1) The claim that a port set makes code simpler needs an explanation to justify it.
E.g., if an app really needs 16 ports, and it fails to get 16 back in its first request, it still
has to handle that and say make multiple separate requests.  So if it already has to have
code to deal with multiple separate requests, why is it simpler to add port set functionality
to and implement both?  This seems counter-intuitive to a reader.

2) Text on overlapping ranges needs more detail.  Is it legal for a client to send requests for
overlapping ranges in parallel or not?  I ask because this was an attack vector for IP reassembly
so can imagine we need the precision here to avoid similar attacks.  This might have an impact
on the Security Considerations section.

3) The unstated assumption in section 5.3 seems to be that the client can reuse the same
mapping nonce in all independent requests that it wants to refresh as a block, is that right?
Let's say internal port 100 and 110 both have the same mapping nonce, and internal port 105
has a different mapping nonce (e.g., from a different PCP client on the same host).
If the first PCP client sends a refresh for port 100, Port Set Size = 11, what would the effect be
at the PCP server?

4) Section 4.1 says if the response does not include a PORT_SET, in a response it assumes
the server doesn't support it, and sends individual MAP requests for the rest of the ports it needs.
But section 4.2 says if the server does support PORT_SET but can only return 1 in its first response,
It must omit the PORT_SET option.  I think that's wrong since it will confuse the client as noted above.
If it's included with a Port Set Size of 1, the client knows it can keep trying using PORT_SET for subsequent
blocks, which might get more than 1 port in each response.

5) If we want this to go to RFC soon, we need to remove normative references to non-RFCs
(and this is easy, I suggested text), but I think we should also remove informative references to 
individual drafts (i.e., drafts that aren't currently WG drafts in any WG), and instead only reference
in the reverse direction; those other drafts should reference this one instead of the other way around.

-Dave

> -----Original Message-----
> From: Dave Thaler
> Sent: Monday, October 21, 2013 4:52 PM
> To: [email-masked]
> Subject: WGLC: draft-ietf-pcp-port-set-03.txt comments due by NOV 5
> 
> This email initiates a two-week Working Group Last Call on
> draft-ietf-pcp-port-set-03 to conclude on Tuesday, November 5th.
> 
> Please send comments to the list.
> 
> -Dave
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On Behalf Of
> > Simon Perreault
> > Sent: Monday, October 21, 2013 5:33 AM
> > To: [email-masked]
> > Subject: Re: [pcp] I-D Action: draft-ietf-pcp-port-set-03.txt
> >
> > WG,
> >
> > This revision addresses comments received at IETF 87 in Berlin, namely:
> >
> > - The "Port Set Offset" field has been replaced by a filed named
> > "First Internal Port".
> >
> > - A new section "Examples" shows various usage examples.
> >
> > To this editor's knowledge there are no open issues left.
> >
> > Simon
> >
> > Le 2013-10-21 12:56, [email-masked] a écrit :
> > >
> > > A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> > >  This draft is a work item of the Port Control Protocol Working
> > > Group of the
> > IETF.
> > >
> > > 	Title           : Port Control Protocol (PCP) Extension for Port Set
> > Allocation
> > > 	Author(s)       : Qiong Sun
> > >                           Mohamed Boucadair
> > >                           Senthil Sivakumar
> > >                           Cathy Zhou
> > >                           Tina Tsou
> > >                           Simon Perreault
> > > 	Filename        : draft-ietf-pcp-port-set-03.txt
> > > 	Pages           : 15
> > > 	Date            : 2013-10-21
> > >
> > > Abstract:
> > >    This document defines an extension to PCP allowing clients to
> > >    manipulate sets of ports as a whole.  This is accomplished by a new
> > >    MAP option: PORT_SET.
> > >
> > >
> > > The IETF datatracker status page for this draft is:
> > > https://datatracker.ietf.org/doc/draft-ietf-pcp-port-set
> > >
> > > There's also a htmlized version available at:
> > > http://tools.ietf.org/html/draft-ietf-pcp-port-set-03
> > >
> > > A diff from the previous version is available at:
> > > http://www.ietf.org/rfcdiff?url2=draft-ietf-pcp-port-set-03
> > >
> > >
> > > Please note that it may take a couple of minutes from the time of
> > > submission until the htmlized version and diff are available at
> tools.ietf.org.
> > >
> > > Internet-Drafts are also available by anonymous FTP at:
> > > ftp://ftp.ietf.org/internet-drafts/
> > >
> > > _______________________________________________
> > > pcp mailing list
> > > [email-masked]
> > > https://www.ietf.org/mailman/listinfo/pcp

---

From: Simon Perreault <[email-masked]>
Date: Thu, 31 Oct 2013 10:24:13 -0400

Dave,

Thanks a lot for the review! I'll be sure to incorporate your comments 
into a new revision shortly after the gates reopen.

Le 2013-10-30 18:33, Dave Thaler a écrit :
> has to handle that and say make multiple separate requests.

Two observations:

- Wouldn't that behaviour be a tiny bit evil? It reminds me of 
applications that create multiple flows in an attempt to trick an 
SFQ-based QoS into allocating them more bandwidth.

- Often, apps that ask for N ports don't really need N ports. Ideally 
they would like to get N ports, but they can live with <N ports. No need 
for single-port fallback in that case.

> So if it already has to have

That would only apply to apps that absolutely need N ports to function, 
and don't need them to be contiguous. Those apps need to fall back on 
single-port requests as you describe. But I would argue that these apps 
are really quite rare.

We can add text describing these concerns in the next revision.

> on the Security Considerations section.

Hmmm... interesting. I see now that those requests would not be 
idempotent, contrary to single-port MAP requests. The first one to be 
processed by the server would "win". Responses to each request would 
depend on which one has won.

I don't see an attack here, but the lack of idempotence bugs me. I don't 
quite know what action to take here except describe the situation in the 
next revision.

> mapping nonce in all independent requests that it wants to refresh as a block, is that right?

Right.

> If the first PCP client sends a refresh for port 100, Port Set Size = 11, what would the effect be

Assuming the request nonce matches the nonce of the mapping at port 100, 
then:

- The mapping at port 100 would be refreshed.

- The mapping at port 110 would not be refreshed, but its remaining 
lifetime would be returned by the server, as described in 
draft-cheshire-pcp-unsupp-family. The response's nonce would be copied 
from the request's nonce.

If you agree that this is how it should be, I'll add this to the example 
section. However, that would depend on keeping the normative reference 
to unsupp-family (see point 5 below).

> blocks, which might get more than 1 port in each response.

Agreed. I'll modify the draft accordingly unless others disagree.

> in the reverse direction; those other drafts should reference this one instead of the other way around.

AFAIK, informative references don't prevent publishing as an RFC. So 
I'll focus on normative references.

I'll remove the reference to draft-boucadair-pcp-failure unless others 
disagree.

About draft-cheshire-pcp-unsupp-family: we could remove the reference 
and let the document stand on its own. The new example showing the 
effect of nonce checking multiple mappings with differing nonces would 
be added to draft-cheshire.

As an aside: the example in section "5.2 Stateless Mapping Discovery" is 
not specific to draft-tsou-stateless-nat44. It is intended to illustrate 
how discovery is done generically without the client knowing the kind of 
stateless NAT it is speaking to. In fact, if the NAT in that example had 
been one implementing draft-tsou, the numbers would have been different. 
Therefore I suggest keeping the example.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca