Subject: [v6ops] Review of draft-ietf-v6ops-transition-ipv4aas-05

From: <[email-masked]>
Date: Fri, 20 Jul 2018 17:02:39 +0000

Fred, Jordi, all,

As requested yesterday during the v6ops session, please find below a review to the latest version of the document fwiw:

*         pdf : https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/draft-ietf-v6ops-transition-ipv4aas-05-rev%20Med.pdf

*         doc : https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/draft-ietf-v6ops-transition-ipv4aas-05-rev%20Med.doc

Cheers,
Med

---

From: Richard Patterson <[email-masked]>
Date: Fri, 20 Jul 2018 13:50:55 -0400

Hi Med,

Let me address your comments around the UPnP section, as it uses
wording that I suggested.

> UPnP SHOULD be disabled by DEFAULT on the IPv6 Transition CE Router when using an IPv4aaS transition mechanism.

Your comment:
"What is the rationale for this one? In order to allow for service
continuity, I would maintain any default behavior is used for IPv4.
Given that we don’t have one for IPv4, I tend to suggest to delete
this and be silent."

The rationale is that without additionally functionality such as your
UPnP-PCP IWF, or another mechanism to detect IPv4aaS, a UPnP
AddPortMapping() request will always succeed even when configured with
an IPv4aaS using IPv4 overloading.   The end application sees this
AddPortMapping() success and incorrectly assumes it can now use that
port for inbound connectivity.  This will be more detrimental to
end-to-end connectivity, than if the UPnP agent was disabled, or
rejected the mapping request.

> the UPnP agent MUST reject any port mapping requests for port numbers outside of the port set allocated to the IPv6 Transition CE Router

Your comment:
"This is contradictory to how IGD:2 would work if supported. Instead
of rejecting the request, a port within the port set will be
returned."

This is only true if the application request used AddAnyPortMapping()
instead of AddPortMapping().  We do reference this new function
specifically in a paragraph further down however I do agree with you
that this paragraph is ambiguous.
Perhaps this paragraph should be altered to reference the
AddPortMapping() function specifically:

"If UPnP is enabled on an IPv6 Transition CE Router, the UPnP agent
MUST reject any AddPortMapping() requests for port numbers outside of
the port set allocated to the IPv6 Transition CE Router."

and also be moved below the paragraph that references the alternative
AddAnyPortMapping().  Do you think that covers it?

-Rich

On Fri, 20 Jul 2018 at 13:03, <[email-masked]> wrote:
> ·         pdf : https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/draft-ietf-v6ops-transition-ipv4aas-05-rev%20Med.pdf
>
> ·         doc : https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/draft-ietf-v6ops-transition-ipv4aas-05-rev%20Med.doc
>
>
>
> Cheers,
>
> Med
>
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: <[email-masked]>
Date: Fri, 20 Jul 2018 18:31:12 +0000

Hi Richard,

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : Richard Patterson [mailto:[email-masked]]
> Envoyé : vendredi 20 juillet 2018 13:51
> À : BOUCADAIR Mohamed IMT/OLN
> Cc : Fred Baker; [email-masked] list
> Objet : Re: [v6ops] Review of draft-ietf-v6ops-transition-ipv4aas-05
> 
> Hi Med,
> 

[Med] I hear that. The issue is that there is no "IPv6 transition CE router" as such, but routers which are designed to be deployed in a variety of schemes (even for a single provider): IPv4 only, DS, and IPv6-only. 

Mandating a default behavior for UPnP independently of the actual CPE activation mode is questionable. 

I would be fine if the wording is changed to restrict the behavior as a function of the activated connectivity mode. 

> 
> > the UPnP agent MUST reject any port mapping requests for port numbers
> outside of the port set allocated to the IPv6 Transition CE Router
> 
> Your comment:

[Med] Works for me. I would update the text for more accuracy as follows: 

s/ the port set allocated to the IPv6 Transition CE Router/the port set allocated to the IPv6 Transition CE Router when an A+P mechanism is enabled.

> AddAnyPortMapping().  Do you think that covers it?

[Med] Yes, thanks.

> > As requested yesterday during the v6ops session, please find below a review
> to the latest version of the document fwiw:
> >
> >
> >
> > ·         pdf : https://github.com/boucadair/IETF-Drafts-
> Reviews/blob/master/draft-ietf-v6ops-transition-ipv4aas-05-rev%20Med.pdf
> >
> > ·         doc : https://github.com/boucadair/IETF-Drafts-
> Reviews/raw/master/draft-ietf-v6ops-transition-ipv4aas-05-rev%20Med.doc
> >
> >
> >
> > Cheers,
> >
> > Med
> >

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Fri, 20 Jul 2018 18:11:48 +0000

> > UPnP SHOULD be disabled by DEFAULT on the IPv6 Transition CE Router
> when using an IPv4aaS transition mechanism.

I don't have a problem with the intent of this, but I do have a problem with the way it's worded. This needs to be very specific to the UPnP IGD WANIPConnection service and not a general requirement to disable all UPnP services the CE router may be running.
Barbara

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Fri, 20 Jul 2018 21:18:31 +0000

> [Med] I hear that. The issue is that there is no "IPv6 transition CE router" as
> such, but routers which are designed to be deployed in a variety of schemes
> (even for a single provider): IPv4 only, DS, and IPv6-only.
>

Thinking more about it, I think Med is quite right on this point. I seem to recall that DS-Lite specifically wants UPnP IGD to be running to the LAN if it is doing PCP to the WAN. Since DS-Lite is one of the IPv4aas technologies mentioned, I think the blanket recommendation to disable UPnP IGD is a bad idea.
Barbara

---

From: Richard Patterson <[email-masked]>
Date: Fri, 20 Jul 2018 17:37:56 -0400

> Thinking more about it, I think Med is quite right on this point. I seem to recall that DS-Lite specifically wants UPnP IGD to be running to the LAN if it is doing PCP to the WAN. Since DS-Lite is…

Yes you're quite right, the wording is a bit misleading.  It's not
intended to shadow the other requirements of the document, for example
the DSLITE-2 requirement referencing the use of RFC6970.  We need to
make sure the wording is such that it recommends disabling UPnP for
port forwarding *unless* there's support for 6970, filtering of
assigned port sets, or another mechanism to allow specific validation.

-Richard

---

From: Fred Baker <[email-masked]>
Date: Fri, 20 Jul 2018 17:44:34 -0600

Thanks much

Sent using a machine that autocorrects in interesting ways...

> On Jul 20, 2018, at 11:50 AM, Richard Patterson <[email-masked]> wrote:
> 
> Hi Med,
>

---

From: Richard Patterson <[email-masked]>
Date: Sat, 21 Jul 2018 17:52:24 -0400

> Thinking more about it, I think Med is quite right on this point. I seem to recall that DS-Lite specifically wants UPnP IGD to be running to the LAN if it is doing PCP to the WAN. Since DS-Lite is…

Hi Barbara, Med,

I think we're all aligned on how we want things to behave, so it's
just a matter on getting the wording correct.
I've drafted up this alternative, more specific Section 5 for UPnP
which hopefully more accurately defines the behaviour that we want. If
you could please review it and see what you think?

5. UPnP Support

 By default, an IPv6 Transition CE Router running a UPnP agent, SHOULD
reject UPnP port mapping requests for a WANIPConnection that is
configured with an IPv4aaS transition mechanism.

 UPnP port mapping requests MAY succeed when an IPv6 Transition CE
Router is configured to use a stateless mechanism that allows
unsolicited inbound packets through to the CE, such as MAP or lw4o6,
or when configured with a port set containing all 65535 ports, e.g.,
with an IPv4 address sharing ratio of 1.

 An IPv6 Transition CE Router configured for an IPv4aaS mechanism that
supports PCP [RFC6887],  such as DS-Lite, SHOULD support IGD-PCP IWF
[RFC6970]. UPnP port mapping requests MAY then succeed as outlined in
[RFC6970].

 An IPv6 Transition CE Router that implements a UPnP agent, SHOULD
support the Open Connectivity Foundation's IGD:2 specification,
especially the AddAnyPortMapping() function.

 If the IPv6 Transition CE Router is configured for an IPv4aaS
mechanism that assigns port sets, the UPnP agent MUST reject any
AddPortMapping() requests for port numbers outside of the port set
allocated to the IPv6 Transition CE Router.
 If the IPv6 Transition CE Router receives an AddAnyPortMapping()
request for a port outside of the port set allocated to the the IPv6
Transition CE Router, the request SHOULD succeed, offering an
alternative port from within the port set.

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 23 Jul 2018 12:49:48 +0200

Hi Richard, all,

Thanks for the detailed text. I fully agree with this version.

If everyone is happy which Richard proposal, I will update that text in a few days in the document, together with other inputs from the reviewers that volunteered during the meeting.

Regards,

Jordi

-----Mensaje original-----

De: v6ops <[email-masked]> en nombre de Richard Patterson <[email-masked]>

Fecha: sábado, 21 de julio de 2018, 23:53

Para: <[email-masked]>

CC: "[email-masked] list" <[email-masked]>

Asunto: Re: [v6ops] Review of draft-ietf-v6ops-transition-ipv4aas-05

    

    Hi Barbara, Med,

    

    5. UPnP Support

    [RFC6970].

    v6ops mailing list

    [email-masked]

**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Mon, 23 Jul 2018 17:09:41 +0000

I think the proposed text is confusing and self-contradictory, needs to be more precise in language used around UPnP capabilities, and isn't the correct recommendation. Inline indication of where I see these problems, and proposed text at the bottom.

> I think we're all aligned on how we want things to behave, so it's just a
> matter on getting the wording correct.
> I've drafted up this alternative, more specific Section 5 for UPnP which
> hopefully more accurately defines the behaviour that we want. If you could
> please review it and see what you think?
> 
> 5. UPnP Support
> 

I think "UPnP port mapping requests" and "UPnP agent" are loose terminology (imprecise). 
I've been looking more closely at the relevant UPnP spec (http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v2-Service.pdf) and the IPv4aas RFCs and have decided I disagree that the correct recommendation is always to reject (i.e., reply with an error to) AddPortMapping() or AddAnyPortMapping() requests. The only cases where I think v6ops should be recommending replying with an error are:
 - if (DS-Lite or 464XLAT) AND ((PCP not enabled) OR (UPnP WANIPConnection service does not interwork with PCP)) 
 - if (MAP-T, MAP-E, or lw4o6) AND ((port set information configured) AND (UPnP WANIPConnection service does not interwork with configured port set information) [note that if an entire IPv4 address (or IPv4 prefix) is assigned, port set information is not configured.]
I don't quite know what it means for a WANIPConnection to be "configured with an IPv4aaS transition mechanism". I'm thinking this is talking about a WANIPConnection service instance associated with an IPv4 interface established by an IPv4aas transition mechanism.

> Router is configured to use a stateless mechanism that allows unsolicited
> inbound packets through to the CE, such as MAP or lw4o6, or when
> configured with a port set containing all 65535 ports, e.g., with an IPv4
> address sharing ratio of 1.

It's very confusing to say it MAY succeed after a blanket recommendation that it SHOULD be rejected.
 
> [RFC6970]. UPnP port mapping requests MAY then succeed as outlined in

DSLITE-2 requirement already handles this recommendation.
464XLAT-2 handles this recommendation for 464XLAT (which this proposed text didn't mention).
This proposed paragraph is completely unnecessary, and I don't think it's quite right, anyway.

> support the Open Connectivity Foundation's IGD:2 specification, especially
> the AddAnyPortMapping() function.

"UPnP agent" is a very generic term used for any implementation of any UPnP device or service. I don't think it's appropriate to recommend that all UPnP agents in CE routers implement IGD:2. The vendor may have a UPnP agent there for a completely different reason, and IETF doesn't need to be second-guessing that decision.
It is correct that if the WANIPConnection service is implemented such that it can be properly associated with an IPv4 interface supplied by a IPv4aas mechanism, the AddAnyPortMapping() action should work. Note that OCF has deprecated IGD:1. Implementation of IGD:2 requires implementation of WANConnectionDevice:2, which requires implementation of WANIPConnection:2, which requires implementation of the AddAnyPortMapping(). So any compliant IGD:2 implementation will include the AddAnyPortMapping() action. I would prefer to point out that IGD:1 was deprecated by OCF, so the recommendations in this IETF draft assume IGD:2.

>  If the IPv6 Transition CE Router is configured for an IPv4aaS mechanism that
> assigns port sets, the UPnP agent MUST reject any
>  If the IPv6 Transition CE Router receives an AddAnyPortMapping() request
> for a port outside of the port set allocated to the the IPv6 Transition CE
> Router, the request SHOULD succeed, offering an alternative port from
> within the port set.

This is recommending the opposite from the blanket recommendation to reject in the first proposed paragraph. It is also basically saying that IGD:2 MUST be implemented correctly according to the IGD:2 specification. Which I think is obvious for any implementation of any specification. It's like advising people not to deploy broken implementations. Or telling them they MUST read the specification and MUST implement the specification correctly.

Here is what I would recommend:

If the [UPnP WANIPConnection:2] service is enabled on a CE router, but cannot be associated with an IPv4 interface established by an IPv4aas mechanism or cannot interwork with PCP or a configured port set, an AddPortMapping() or AddAnyPortMapping() action MUST be rejected with error code 729 "ConflictWithOtherMechanisms". Note that IGD:1 and its WANIPConnection:1 service have been deprecated by OCF.

I think that's all that needs to be said. Any properly interworked WANIPConnection:2 service can be expected to behave properly according to UPnP specs.
Then add informative reference to [UPnP WANIPConnection:2] that points to http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v2-Service.pdf.
Barbara

---

From: Richard Patterson <[email-masked]>
Date: Tue, 24 Jul 2018 11:07:29 +0100

Hi Barbara,

> I think the proposed text is confusing and self-contradictory, needs to be more precise in language used around UPnP capabilities, and isn't the correct recommendation. Inline indication of where I…

Fair enough, I won't then try to justify any of my proposed text, but
rather focus on your recommended text instead.
I will say that the conflict/confusion was probably because it was
intended to be read linearly as: "By default reject, unless......."

> Then add informative reference to [UPnP WANIPConnection:2] that points to http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v2-Service.pdf.

"interwork with [...]  a configured port set" is too vague for my
liking.  It's not clear that this means it should reject
AddPortMapping() requests for a port outside of the port set, or
provide an alternative port when requested with AddAnyPortMapping().
I'd like to see this elaborated a bit more on.

Whilst IGD:1 is deprecated, it is what's out there so we need to make
sure to capture the AddPortMapping() behaviour correctly.  Even when
newer CPEs start supporting IGD:2 (most are still dragging their heals
IME), it requires applications to also alter their behaviour to make
use of the new AddAnyPortMapping() function.

I do agree that the more concise wording is better, and that sections
of the previously suggested wording were superfluous when read in
context with the rest of the document.  Apologies for that.

-Richard