Subject: [v6ops] PCP server in draft-ietf-v6ops-6204bis

From: "Dan Wing" <[email-masked]>
Date: Fri, 27 Jan 2012 11:59:12 -0800

v6ops,

I was reading over draft-ietf-v6ops-6204bis today and have a 
suggestion.

Background:  RFC6092 is v6ops's Simple CPE Security document, which 
recommends that a protocol be used to allow a passive listener (e.g., 
web camera) to open a pinhole.  In that document, James Woodyatt's 
ALD was suggested as a possible candidate protocol for that function.

But I see that both the old RFC6204 and draft-ietf-v6ops-6204bis-05
say this (I added uppercase for emphasis):	

   S-1:  The IPv6 CE router SHOULD support [RFC6092].  In particular,
         the IPv6 CE router SHOULD support functionality sufficient for
         implementing the set of recommendations in [RFC6092],
         Section 4.  This document takes no position on whether such
         functionality is enabled by default OR MECHANISMS BY WHICH 
         USERS WOULD CONFIGURE IT.

I would like draft-ietf-v6ops-6204bis to take the position that 
Port Control Protocol (PCP) be the protocol for the uppercased function.

Stated more clearly, I would like the above paragraph to read:

   S-1:  The IPv6 CE router SHOULD support [RFC6092].  In particular,
         the IPv6 CE router SHOULD support functionality sufficient for
         implementing the set of recommendations in [RFC6092],
         Section 4.  This document takes no position on whether such
         functionality is enabled by default.  The IPv6 CE router 
...............................................^^^^^^^^^^^^^^^^^^
         SHOULD implement a PCP server [I-D.ietf-pcp-base] so that
.........^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
         hosts can configure this functionality.
.........^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

If you need more background, please be sure to read both REQ-48 and REQ-49
of RFC6092.  PCP would be a specific protocol that fulfills REQ-49.

In anticipation of one of the earlier objections that making PCP a normative
requirement would delay draft-ietf-v6ops-6204bis,
https://datatracker.ietf.org/doc/draft-ietf-pcp-base shows the document
status is Publication Requested because the PCP working group finished its
WGLC on the document.

-d

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Fri, 27 Jan 2012 20:18:01 +0000

I disagree. 
I believe the marketplace should determine the winning technology in this case, if there is to be a winning technology. RFC6204bis needs to continue to take no position. 

Just because other solutions weren't created by IETF doesn't mean they are any less good. 
Barbara

----- Original Message -----
From: Dan Wing [mailto:[email-masked]]
Sent: Friday, January 27, 2012 02:59 PM
To: 'v6ops' <[email-masked]>
Cc: [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Subject: [v6ops] PCP server in draft-ietf-v6ops-6204bis

v6ops,

-d

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

---

From: Simon Perreault <[email-masked]>
Date: Fri, 27 Jan 2012 15:49:56 -0500

> Just because other solutions weren't created by IETF doesn't mean they are any less good.

<outrageous>
Right. They are less good because PCP is better.
</outrageous>

Sorry, couldn't resist. ;)

Seriously: We already have consensus on a "SHOULD implement a PCP 
server" in draft-ietf-behave-lsn-requirements. I think we should also 
have it on the CPE. Having only one protocol to support would make it so 
much easier for application developers!

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

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 27 Jan 2012 12:54:36 -0800

> -----Original Message-----
> From: STARK, BARBARA H [mailto:[email-masked]]
> Sent: Friday, January 27, 2012 12:18 PM
> To: [email-masked]'; [email-masked]'
> Cc: [email-masked]'; [email-masked]'
> Subject: Re: [v6ops] PCP server in draft-ietf-v6ops-6204bis
> 
> I disagree.
> I believe the marketplace should determine the winning technology in
> this case, if there is to be a winning technology. RFC6204bis needs to
> continue to take no position.
> 

I suppose you are referring to UPnP IGD 2, which added IPv6 firewall
support (among other things of less interest to v6ops).

If it said "or UPnP IGD 2", would you still object or would that be 
acceptable?

Right now, the text allows any sorts of thing -- including a web portal
operated by the ISP, Web UI on the CPE itself, CLI on the CPE (accessed
via ssh or telnet), holding a little red button in the back for 3 
seconds to allow port 80 or 30 seconds to allow port 443, or whatever 
someone wants to design and claim compliance.  This sort of free-for-all
seems incongruent with Internet and IPv6 going into billions of 
homes and businesses and a standards-making organization such as the
IETF.

-d

> Cc: [email-masked] <[email-masked]>; draft-ietf-v6ops-
> [email-masked] <[email-masked]>

---

From: Mark Baugher <[email-masked]>
Date: Fri, 27 Jan 2012 12:57:47 -0800

On Jan 27, 2012, at 12:18 PM, STARK, BARBARA H wrote:

> I disagree. 
> I believe the marketplace should determine the winning technology in this case, if there is to be a winning technology.

There really is no marketplace but rather a situation where different sets of vendors ship different solutions on products that are not differentiated by how well they open up firewalls.  This has been the case for sometime now, and I don't expect to see a winning technology.  PCP also does more than IGD or NAT-PMP that is of interest to IPv6.

Mark

> RFC6204bis needs to continue to take no position. 
>

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 27 Jan 2012 16:41:57 -0600

Dan,

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Dan Wing (dwing)
Sent: Friday, January 27, 2012 2:59 PM
To: 'v6ops'
Cc: [email-masked]; [email-masked]
Subject: [v6ops] PCP server in draft-ietf-v6ops-6204bis

>         functionality is enabled by default.  The IPv6 CE router 

The plan of record for rfc6204bis was indeed to add a PCP requirement if
during the progression of the rfc6204bis document to the IESG, PCPbase
became an RFC or is pending publication.   "PCPbase pending publication"
has happened - good.  Now the specific req related to PCP we had agreed
upon with v6ops during the last discussion was to include a PCP client
in the CPE router, not a server.  We had not agreed to a server because
for one, one large host OS vendor is Microsoft does not have PCP support
yet or least not as of a few months back.  I have cced to Dave Thaler
who had also agreed at the time to not include a server.  Why can't the
user of the CPE router manually provision a pinhole port and the PCP
client in the CPE router sends a request to the DS-Lite AFTR.

Hemant

---

From: Randy Bush <[email-masked]>
Date: Sat, 28 Jan 2012 07:41:54 +0900

> continue to take no position.

perhaps the users would like interoperability between their toys and
their border?

as far as the market deciding, i suspect less than .001 of the users
even know there is a protocol used to make this work, let alone care.

randy

---

From: Francis Dupont <[email-masked]>
Date: Sat, 28 Jan 2012 16:05:01 +0100

In your previous mail you wrote:

>  I disagree. 
>  I believe the marketplace should determine the winning technology
>  in this case, if there is to be a winning technology. RFC6204bis
>  needs to continue to take no position.
>

=> +1: if we want to recommend a protocol there is no reason to
forget UPnP IGD v2 (to take a solution similar to PCP) or the
zillion of other ways to control NAT/Fireall.

Regards

[email-masked]

---

From: "Ole Troan (otroan)" <[email-masked]>
Date: Sat, 28 Jan 2012 16:52:44 +0100

The proposal here is for the protocol between the cpe and the cgn. I wasn't aware of other proposals than pcp for that. 

On the LAN side I expect we need to support all alternatives. The cpe will then have a whatever to pcp proxy. 

Cheers,
Ole

---

From: Francis Dupont <[email-masked]>
Date: Sun, 29 Jan 2012 17:08:50 +0100

In your previous mail you wrote:

>  The proposal here is for the protocol between the cpe and the
>  cgn. I wasn't aware of other proposals than pcp for that.

=> there are already plenty of (far too many according to some :-)
protocols providing the control so I believe you'd like to limit
the way they work: the CPE-CGN case disqualifies NAT-PMP but
UPnP IGD v2 does the job, it was just published after the PCP effort
beginning.

> On the LAN side I expect we need to support all alternatives. The
> cpe will then have a whatever to pcp proxy.

=> this can raise some security issue when an intermediate node
(e.g., a cpe) embeds a NAT and there are more than one, so IMHO
we should first determine if the best solution is to put the
intelligence in intermediate nodes or to manage arbitrary complexity
in end nodes/hosts?

Regards

---

From: james woodyatt <[email-masked]>
Date: Sun, 29 Jan 2012 09:51:52 -0800

On Jan 29, 2012, at 08:08 , Francis Dupont wrote:
> 
> UPnP IGD v2 does the job, it was just published after the PCP effort beginning.

Was it published under terms that permit IETF to cite it in a standards track document as a normative requirement?  This has, in the past, been a problem with UPnP IGDv1.

--
j h woodyatt <[email-masked]>

---

From: Wuyts Carl <[email-masked]>
Date: Mon, 30 Jan 2012 09:03:38 +0100

+ 1 on Barbara's statement.  V6ops should take no position to select a mechanism here.  PCP seems to get the most attention but it should not make v6ops to decide to take it along explicitly in RFC6204bis.

Regs
Carl

From: [email-masked] [mailto:[email-masked]] On Behalf Of james woodyatt
Sent: zondag 29 januari 2012 18:52
To: Francis Dupont
Cc: [email-masked]; [email-masked]; Ole Troan (otroan); [email-masked]
Subject: Re: [v6ops] PCP server in draft-ietf-v6ops-6204bis

--
j h woodyatt <[email-masked]<mailto:[email-masked]>>

---

From: james woodyatt <[email-masked]>
Date: Mon, 30 Jan 2012 11:16:24 -0800

On Jan 30, 2012, at 24:03 , Wuyts Carl wrote:

> + 1 on Barbara’s statement.  V6ops should take no position to select a mechanism here.  PCP seems to get the most attention but it should not make v6ops to decide to take it along explicitly in RFC6204bis.

I vigorously disagree with the reasoning in these statements.

If IETF cannot bring itself, in RFC 6204bis, to "require" its own standard protocol, which was intended for meeting REC-48 in RFC 6092, then I don't see why we should keep S-1 at all.

Put another way: if we believe there should be no standard mechanism in IPv6 CE routers for "host applications to solicit inbound traffic without advance knowledge of the addresses of exterior nodes with which they expect to communicate" then why do we believe that IPv6 CE routers should implement RFC 6092?

I am NOT just ranting here.  This is a very serious question, and I would like the working group to address it.  I would very much like to see serious answers given.

---

From: Francis Dupont <[email-masked]>
Date: Mon, 30 Jan 2012 20:36:14 +0100

In your previous mail you wrote:

>  Was it published under terms that permit IETF to cite it in a
>  standards track document as a normative requirement?  This has, in
>  the past, been a problem with UPnP IGDv1.

=> I am not a lawyer so I can't say... but the text of the standard
is freely available (in all meanings of the word 'free') so at least
one can make its own opinion.

Regards

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Mon, 30 Jan 2012 19:58:40 +0000

To come at this from a procedural angle, then...

With the advent of the homenet WG, I thought we agreed that we would not make any attempt to address new additional LAN technology recommendations in a 6204bis document. We said 6204bis would only try to deal with WAN-side transition technologies, and other "fix existing 6204 recommendations, because now we know better" changes.

Recommending PCP as a LAN technology is, IMO, a homenet issue. It has no place in 6204bis.

PCP as a WAN technology that some want to see used in conjunction with IPv4/IPv6 transition mechanisms that put an IPv4 CGN in the access network, is, IMO, a reasonable addition to 6204bis (as a SHOULD, which I think is what proposed verbiage has). 

Barbara

> Of Francis Dupont
> Sent: Monday, January 30, 2012 2:36 PM
> To: james woodyatt

---

From: james woodyatt <[email-masked]>
Date: Mon, 30 Jan 2012 12:17:13 -0800

> Recommending PCP as a LAN technology is, IMO, a homenet issue. It has no place in 6204bis.

This reasoning applies just as well to the recommendation of RFC 6092 Simple Security, which is about protecting LAN hosts according to local network policy.

If recommending a PCP server is for HOMENET to do, and it has no place in RFC 6204bis from V6OPS, then recommending RFC 6092 Simple Security neither has any place in RFC 6204bis and it should therefore be removed, and a notice inserted into RFC 6204bis to explain why the previous document was in error and to note that forthcoming documents from HOMENET will address the issue properly.

I would very much like to get a better understanding of how you are reasoning on this issue.

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Mon, 30 Jan 2012 20:59:46 +0000

The reference to RFC 6092 is in RFC 6204, which was published prior to homenet's creation.

Unless the reference to 6092 is truly an error, then we don't need to be discussing changes to its recommendation (removal, updates, enhancements) in 6204bis. It continues as it was. 6204bis has tried to leave LAN elements of 6204 untouched. They were fully and appropriately discussed with consensus agreement to include them, at the time of 6204. And so they remain, unless there is a problem.

If you believe that inclusion of 6092 as a "SHOULD" is truly an error, then I would like to understand why you think that. If there exists proof that it's harmful (I've heard some people say that having it enabled by default has caused some problems, so perhaps there is such proof), then maybe we should reconsider its inclusion. If you're suggesting its removal because the topic is no longer under the charter of v6ops, then I disagree. We didn't say that we wanted to pull out LAN elements when doing 6204bis. We said we didn't want to do anything with them, at all (unless they have proven to be a true mistake). Removing the reference to 6092 would be inconsistent with an attempt to make no "LAN functionality" changes to 6204, when creating 6204bis. I would only support it if it were shown to be truly harmful.

Barbara

From: james woodyatt [mailto:[email-masked]]
Sent: Monday, January 30, 2012 3:17 PM
To: STARK, BARBARA H
Cc: PCP; IPv6 Operations; [email-masked]
Subject: Re: [v6ops] PCP server in draft-ietf-v6ops-6204bis

---

From: james woodyatt <[email-masked]>
Date: Mon, 30 Jan 2012 14:08:53 -0800

On Jan 30, 2012, at 12:59 , STARK, BARBARA H wrote:

> The reference to RFC 6092 is in RFC 6204, which was published prior to homenet’s creation.
>  
> Unless the reference to 6092 is truly an error, then we don’t need to be discussing changes to its recommendation (removal, updates, enhancements) in 6204bis. It continues as it was. 6204bis has tried to leave LAN elements of 6204 untouched. They were fully and appropriately discussed with consensus agreement to include them, at the time of 6204. And so they remain, unless there is a problem.
>  
> If you believe that inclusion of 6092 as a “SHOULD” is truly an error, then I would like to understand why you think that. If there exists proof that it’s harmful (I’ve heard some people say that having it enabled by default has caused some problems, so perhaps there is such proof), then maybe we should reconsider its inclusion. If you’re suggesting its removal because the topic is no longer under the charter of v6ops, then I disagree. We didn’t say that we wanted to pull out LAN elements when doing 6204bis. We said we didn’t want to do anything with them, at all (unless they have proven to be a true mistake). Removing the reference to 6092 would be inconsistent with an attempt to make no “LAN functionality” changes to 6204, when creating 6204bis. I would only support it if it were shown to be truly harmful.

If I were to make a technical argument about the harmfulness of RFC 6092, I would start with a lengthy review of its Security Considerations, in section 6.

I think it's a debatable question of procedure, whether it was an error at the time for V6OPS to publish RFC 6204 with its S-1 "requirement" to recommend implementation of RFC 6092.  There was a clamor for the timely publication of a document, and neither HOMENET nor PCP were remotely close to usable when RFC 6204 was in WGLC.

I do think it shouldn't be controversial *now* to say that HOMENET is the venue where any further IETF recommendations about the implementation of RFC 6092 in IPv6 CE routers should originate.  If you disagree, then once again, I have to ask for an explanation of your reasoning.  I'm very interested to know.

If V6OPS wishes to continue stepping on HOMENET's charter, on the grounds that it already has its footprints there from before HOMENET was launched, then I suppose that's fine— but, if so, then I don't see why V6OPS shouldn't also take this opportunity to revise RFC 6204 to recommend a PCP server to meet REC-48 in RFC 6092.  Again, as a purely technical matter— I know, technical matters are so boring— IETF has a standards-track protocol for ""host applications to solicit inbound traffic without advance knowledge of the addresses of exterior nodes with which they expect to communicate" as RFC 6092 recommends.  We did not have this protocol when either RFC 6092 or RFC 6204 were ready for publication, but we do now.  I fail to see any technical basis for leaving this unspecified in RFC 6204bis.  Is there one?

Alternatively, if this is primarily a procedural dispute, then we could open RFC6092bis in order to update REC-48 accordingly, then cite the RFC6092bis in RFC6204bis with a publication in lockstep.  Which would you prefer?

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Mon, 30 Jan 2012 22:36:47 +0000

I quite agree that any and all discussions around changes to or further recommendations around 6092 should be held in homenet. That is exactly why I'm trying to avoid such discussions now in v6ops. I think there should be a very high bar set around changing any of the LAN-side recommendations in 6204, as we work on 6204bis. Certainly nothing should be added. But at this point, I'm opposed to any modification to those recommendations, without a very good justification, and without homenet expressing the need for the change (after having discussed and reached consensus). When those recommendations were put in 6204, they were in scope for v6ops. Since they are no longer in v6ops' scope, v6ops needs to just leave them alone. Would you like v6ops to ask homenet if they want to see any of the language in 6204 changed? If so, then I would prefer for there to be a very quick turn-around; and there needs to be strong consensus in homenet for a change. Just a couple of vocal people shouldn't be considered a consensus. If you think there might be consensus to request a change, then perhaps there should be a hum to see if the majority of homenet feel strongly enough to force a change to any of the 6204 LAN-side functionality language? I don't really know the proper procedure. Perhaps someone else should say what the proper procedure would be.
Barbara

---

From: james woodyatt <[email-masked]>
Date: Mon, 30 Jan 2012 14:47:46 -0800

everyone—

I'm addressing the chairs now.

I'm still waiting to see a technical basis for recommending a filtering scheme that blocks unsolicited incoming traffic, and which itself recommends the implementation of a protocol for "host applications to solicit inbound traffic without advance knowledge of the addresses of exterior nodes with which they expect to communicate," with no accompanying recommendation to implement the forthcoming IETF standards-track protocol for doing it.

Is this a case of procedural matters unduly having precedence over technical matters?  If so, then I'd like to ask that RFC 6204 be held back so that we can revise RFC 6092 to update REC-48 accordingly and publish both simultaneously.

---

From: james woodyatt <[email-masked]>
Date: Mon, 30 Jan 2012 14:49:37 -0800

everyone—

Or I would have been addressing the chairs if I had filled out the headers correctly.  I am now.

Begin forwarded message:

> From: james woodyatt <[email-masked]>
> Date: January 30, 2012 14:47:46 PST
> To: [email-masked]
> Cc: IPv6 Operations <[email-masked]>
> 
> everyone—
>