Subject: [v6ops] PCP and I-D.ietf-v6ops-mobile-device-profile

From: james woodyatt <[email-masked]>
Date: Mon, 09 Sep 2013 08:59:04 -0700

everyone—

I haven’t prepared an exhaustive criticism of this draft, but I do have one concern in particular I would like to highlight. The recommendations (for they are not requirements) REQ#12 and REQ#15 discussing matters related to the Port Control Protocol (PCP) and traversal of NAT and firewalls is troubling to me.

REQ#12:  The cellular host SHOULD support a method to locally
        construct IPv4-embedded IPv6 addresses [RFC6052].  A method to
        learn PREFIX64 SHOULD be supported by the cellular host.

           This solves the issue when applications use IPv4 referrals on
           IPv6-only access networks.

           In PCP-based environments, cellular hosts SHOULD follow
           [I-D.ietf-pcp-nat64-prefix64] to learn the IPv6 Prefix used
           by an upstream PCP-controlled NAT64 device.  If PCP is not
           enabled, the cellular host SHOULD implement the method
           specified in [I-D.ietf-behave-nat64-discovery-heuristic] to
           retrieve the PREFIX64.

REQ#15:  The cellular host SHOULD support PCP [RFC6887].

           The support of PCP is seen as a driver to save battery
           consumption exacerbated by keepalive messages.  PCP also
           gives the possibility of enabling incoming connections to the
           cellular device.  Indeed, because several stateful devices
           may be deployed in wireless networks (e.g., NAT and/or
           Firewalls), PCP can be used by the cellular host to control
           network-based NAT and Firewall functions which will reduce
           per-application signaling and save battery consumption.

It seems to me that these recommendations are only worth following if there are to be PCP servers in *all* of the network elements in the paths between cellular hosts and the default free zone that implement stateful firewall (and NAT) functions.  Indeed, in at least one common cellular host architecture, there is a stateful filter in the baseband chipset firmware that blocks all inbound packets that it decides are unsolicited by applications on the main system CPU. There is no PCP service in those chipset firmware implementations, and no practical way to turn off the filtering, because it is tied up with tricky power consumption issues, and without either of those things, there is pretty much no good reason to implement a PCP client on the main system CPU. It does not matter whether there are PCP servers in the firewalls further upstream, if there is a firewall in the baseband chipset that you can’t disable or control.

I recommend dropping these recommendations and replacing them with text that recognizes the present reality that cellular hosts are simply not expected ever to receive unsolicited inbound connection flows from arbitrary remote Internet addresses. It would simplify the document and it would be a more honest appraisal of the situation.

--
james woodyatt <[email-masked]>
core os networking

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 10 Sep 2013 17:10:30 +0900

On Tue, Sep 10, 2013 at 12:59 AM, james woodyatt <[email-masked]> wrote:

> I recommend dropping these recommendations and replacing them with text
> that recognizes the present reality that cellular hosts are simply not
> expected ever to receive unsolicited inbound connection flows from
> arbitrary remote Internet addresses. It would simplify the document and it
> would be a more honest appraisal of the situation.
>

To be fair, that doesn't happen on all devices. For example, my Nexus 7 LTE
on Docomo's business APN appears to have real Internet access. I can ping
it, and when I attempt to connect to it, I get a TCP reset back. tcpdump
running on the phone shows:

17:06:20.429555 IP6 2401:fa00:4:1012:ade4:53dc:5b4f:c028 >
240a:0:248:60c1:b7cd:8a4c:4638:a4b4: ICMP6, echo request, seq 1, length 64
17:06:20.430257 IP6 240a:0:248:60c1:b7cd:8a4c:4638:a4b4 >
2401:fa00:4:1012:ade4:53dc:5b4f:c028: ICMP6, echo reply, seq 1, length 64
17:06:26.365621 IP6 2401:fa00:4:1012:ade4:53dc:5b4f:c028.43289 >
240a:0:248:60c1:b7cd:8a4c:4638:a4b4.80: S 1959749223:1959749223(0) win
14400 <mss 1394,sackOK,timestamp 9349082 0,nop,wscale 7>
17:06:26.366201 IP6 240a:0:248:60c1:b7cd:8a4c:4638:a4b4.80 >
2401:fa00:4:1012:ade4:53dc:5b4f:c028.43289: R 0:0(0) ack 1959749224 win 0

Now, the battery life implications of such a setup are debatable, but it
does suggest that there is no stateful filtering going on in the baseband.
Or did I misunderstand what you wrote?

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 10 Sep 2013 10:27:28 +0200 (CEST)

On Mon, 9 Sep 2013, james woodyatt wrote:

> arbitrary remote Internet addresses. It would simplify the document and 
> it would be a more honest appraisal of the situation.

At my previous employer we ran unfiltered Internet access to all mobile 
customers, and they all had IPv4 GUA addresses. We had to stop doing that 
due to IPv4 runout in RIPE region, otherwise we would have continued.

So your presumption above isn't true. It might be like that in some or 
even most parts of the world, but it's not in all of it.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: <[email-masked]>
Date: Tue, 10 Sep 2013 10:27:43 +0200

Hi James,

I appreciate your effort for reading and raising a technical point. I really don't care if you shared this comment during the WGLC or now once the IETF LC is over.

Some general answers:

* This document does not aim to provide a static picture of what current implementations are doing but we are listing also features to ease adoption of the IPv6-only model. For this reason, there is a list of feature that are needed for that model: these recommendations are all SHOULD ones and not MUST. FWIW, the document included some details on broken implementations and tests but that text was removed as suggested by some reviewers. The document is not intended to ACK the current broken implementations but to list of features to have more and more implementations that can be connected in IPv6-only and DS modes without service degradation.

* The feature of retrieving the PREFIX64 using PCP has been implemented and tested (see for example http://tools.ietf.org/html/draft-boucadair-pcp-nat64-experiments-00)

* Motivations for PCP from a provider perspective are mentioned in the document. No need to re-iterate that. From a customer standpoint, some users are using their mobile connection as their main line. As such, they have the same requirements as for fixed services. I have been told that there are customers running game consoles using their mobile connection (If I'm not mistaken, Reinaldo has mentioned this case in an e-mail. I will let him confirm/infirm).

* The document includes the following:

   Some of the features listed in this profile document require to
   activate dedicated functions at the network side.  It is out of scope
   of this document to list these network-side functions.

* Some operators have included PCP as a requirement for their NAT64 in the context of ongoing RFPs. For those  operators, the client-side functionality is needed.

Cheers,
Med

De : [email-masked] [mailto:[email-masked]] De la part de james woodyatt
Envoyé : lundi 9 septembre 2013 17:59
À : [email-masked] WG
Objet : [v6ops] PCP and I-D.ietf-v6ops-mobile-device-profile

everyone-

I haven't prepared an exhaustive criticism of this draft, but I do have one concern in particular I would like to highlight. The recommendations (for they are not requirements) REQ#12 and REQ#15 discussing matters related to the Port Control Protocol (PCP) and traversal of NAT and firewalls is troubling to me.

        construct IPv4-embedded IPv6 addresses [RFC6052<http://tools.ietf.org/html/rfc6052>].  A method to

           [I-D.ietf-pcp-nat64-prefix64<http://tools.ietf.org/html/draft-ietf-v6ops-mobile-device-profile-05#ref-I-D.ietf-pcp-nat64-prefix64>] to learn the IPv6 Prefix used

           specified in [I-D.ietf-behave-nat64-discovery-heuristic<http://tools.ietf.org/html/draft-ietf-v6ops-mobile-device-profile-05#ref-I-D.ietf-behave-nat64-discovery-heuristic>] to

           retrieve the PREFIX64.

REQ#15:  The cellular host SHOULD support PCP [RFC6887<http://tools.ietf.org/html/rfc6887>].

It seems to me that these recommendations are only worth following if there are to be PCP servers in *all* of the network elements in the paths between cellular hosts and the default free zone that implement stateful firewall (and NAT) functions.  Indeed, in at least one common cellular host architecture, there is a stateful filter in the baseband chipset firmware that blocks all inbound packets that it decides are unsolicited by applications on the main system CPU. There is no PCP service in those chipset firmware implementations, and no practical way to turn off the filtering, because it is tied up with tricky power consumption issues, and without either of those things, there is pretty much no good reason to implement a PCP client on the main system CPU. It does not matter whether there are PCP servers in the firewalls further upstream, if there is a firewall in the baseband chipset that you can't disable or control.

--
james woodyatt <[email-masked]<mailto:[email-masked]>>
core os networking

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 10 Sep 2013 10:29:34 +0200 (CEST)

On Tue, 10 Sep 2013, Lorenzo Colitti wrote:

> does suggest that there is no stateful filtering going on in the 
> baseband. Or did I misunderstand what you wrote?

My guess is that a lot of mobile Internet providers have a stateful 
firewall on Gi interface that filters connection initiation attempts 
towards the mobile devices. As you see yourself, this isn't universal.

Considering all rooted iPhones out there that were "hacked" by default ssh 
password a few years back, I imagine it's quite common that no Gi firewall 
is precent.

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 10 Sep 2013 17:32:20 +0900

> password a few years back, I imagine it's quite common that no Gi firewall

What James said is "in at least one common cellular host architecture,
there is a stateful filter in the baseband chipset firmware that blocks all
inbound packets that it decides are unsolicited".

So he's probably talking about a firewall in the phone baseband (i.e., on
the processor that deals with the radio), not on the network or on the
phone's main processor.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 10 Sep 2013 10:37:17 +0200 (CEST)

On Tue, 10 Sep 2013, Lorenzo Colitti wrote:

> So he's probably talking about a firewall in the phone baseband (i.e., 
> on the processor that deals with the radio), not on the network or on 
> the phone's main processor.

Check. Well, since I have experience with other devices that do not 
implement this functionality I don't subscribe to that world view.

---

From: james woodyatt <[email-masked]>
Date: Tue, 10 Sep 2013 11:06:57 -0700

On Sep 10, 2013, at 1:10, Lorenzo Colitti <[email-masked]> wrote:
> To be fair, that doesn't happen on all devices. For example, my Nexus 7 LTE on Docomo's business APN appears to have real Internet access. I can ping it, and when I attempt to connect to it, I get a TCP reset back. tcpdump running on the phone shows:
> 
> 17:06:20.429555 IP6 2401:fa00:4:1012:ade4:53dc:5b4f:c028 > 240a:0:248:60c1:b7cd:8a4c:4638:a4b4: ICMP6, echo request, seq 1, length 64
> 17:06:20.430257 IP6 240a:0:248:60c1:b7cd:8a4c:4638:a4b4 > 2401:fa00:4:1012:ade4:53dc:5b4f:c028: ICMP6, echo reply, seq 1, length 64
> 17:06:26.365621 IP6 2401:fa00:4:1012:ade4:53dc:5b4f:c028.43289 > 240a:0:248:60c1:b7cd:8a4c:4638:a4b4.80: S 1959749223:1959749223(0) win 14400 <mss 1394,sackOK,timestamp 9349082 0,nop,wscale 7>
> 17:06:26.366201 IP6 240a:0:248:60c1:b7cd:8a4c:4638:a4b4.80 > 2401:fa00:4:1012:ade4:53dc:5b4f:c028.43289: R 0:0(0) ack 1959749224 win 0
> 
> Now, the battery life implications of such a setup are debatable, but it does suggest that there is no stateful filtering going on in the baseband. Or did I misunderstand what you wrote?

I don’t think you misunderstood, but I think I should clarify my remarks in order to better convey my concern.

It’s nice that your phone, on that network, this month, can receive unsolicited inbound flows— but the problem here is the same one I complained bitterly about prior to and during the development of RFC 6092: it isn’t sufficient for only *some* or even most cellular hosts to be reachable— in most places, most of the time— with unsolicited flows by arbitrary remote hosts.  We really need it to be practically all the phones, practically all the time, practically everywhere. We don’t have that, and there is no reason to believe that we ever will have that.

If you’re trying to develop an application that does any sort of direct peer-to-peer communication between cellular hosts, then you need to be able to rely on the expectation that network elements that block unsolicited inbound flows are rare and deployed only where users are not expecting direct peer-to-peer applications to function properly, so that when your application is broken by the stateful firewall in the network, users know whom to blame and where to petition for redress.

We now have a situation where a sizable fraction of cellular IPv6-capable user-endpoint hosts are unreachable by unsolicited inbound flow because they are located behind one or more than one stateful firewall, that is enabled by default, contains no exceptions for IPsec or IKE, and implements no protocol like PCP for soliciting inbound flows from arbitrary remote addresses. This is precisely the situation I was warning against before I capitulated and agreed to serve as the editor for RFC 6092 despite my reservations about the reasons the working group decided to adopt it. This is also the situationI was warning against when I was arguing for a recommendation in RFC 6092 that firewalls not block unsolicited inbound flows in the DEFAULT configuration.

Shorter james: it’s time to admit defeat. We blew it— there will never be direct peer-to-peer telecommunications with IPv6, particularly with cellular hosts. All that traffic must be directed through relays in the network where it can be subject to police wiretap and social network analysis.

Even shorter james: I told you all so.

---

From: Owen DeLong <[email-masked]>
Date: Tue, 10 Sep 2013 12:45:33 -0700

> It’s nice that your phone, on that network, this month, can receive unsolicited inbound flows— but the problem here is the same one I complained bitterly about prior to and during the development o…

We don't even have that for most computers at this point. I think it would be a wonderful thing, but I don't think it is a problem that is unique to cellular.

> If you’re trying to develop an application that does any sort of direct peer-to-peer communication between cellular hosts, then you need to be able to rely on the expectation that network elements…

This is different from peer to peer software for non-cellular hosts how?

> We now have a situation where a sizable fraction of cellular IPv6-capable user-endpoint hosts are unreachable by unsolicited inbound flow because they are located behind one or more than one statef…

I don't think we should admit defeat, but we should fix this for more than just cellular.

Owen

---

From: "cb.list6" <[email-masked]>
Date: Tue, 10 Sep 2013 12:58:26 -0700

On Tue, Sep 10, 2013 at 11:06 AM, james woodyatt <[email-masked]> wrote:
>> expected ever to receive unsolicited inbound connection flows from arbitrary
>> remote Internet addresses. It would simplify the document and it would be a
>> more honest appraisal of the situation.
>
>
> 240a:0:248:60c1:b7cd:8a4c:4638:a4b4.80: S 1959749223:1959749223(0) win 14400
> <mss 1394,sackOK,timestamp 9349082 0,nop,wscale 7>
> It’s nice that your phone, on that network, this month, can receive
> unsolicited inbound flows— but the problem here is the same one I complained
> bitterly about prior to and during the development of RFC 6092: it isn’t
> sufficient for only *some* or even most cellular hosts to be reachable— in
> most places, most of the time— with unsolicited flows by arbitrary remote
> hosts.  We really need it to be practically all the phones, practically all
> the time, practically everywhere. We don’t have that, and there is no reason
> to believe that we ever will have that.
>
> If you’re trying to develop an application that does any sort of direct
> peer-to-peer communication between cellular hosts, then you need to be able
> to rely on the expectation that network elements that block unsolicited
> inbound flows are rare and deployed only where users are not expecting
> direct peer-to-peer applications to function properly, so that when your
> application is broken by the stateful firewall in the network, users know
> whom to blame and where to petition for redress.
>
> We now have a situation where a sizable fraction of cellular IPv6-capable
> user-endpoint hosts are unreachable by unsolicited inbound flow because they
> are located behind one or more than one stateful firewall, that is enabled
> by default, contains no exceptions for IPsec or IKE, and implements no
> protocol like PCP for soliciting inbound flows from arbitrary remote
> addresses. This is precisely the situation I was warning against before I
> capitulated and agreed to serve as the editor for RFC 6092 despite my
> reservations about the reasons the working group decided to adopt it. This
> is also the situationI was warning against when I was arguing for a
> recommendation in RFC 6092 that firewalls not block unsolicited inbound
> flows in the DEFAULT configuration.
>
> Shorter james: it’s time to admit defeat. We blew it— there will never be
> direct peer-to-peer telecommunications with IPv6, particularly with cellular
> hosts. All that traffic must be directed through relays in the network where
> it can be subject to police wiretap and social network analysis.
>

I don't see it that way at all.

I don't support PCP, and cannot see it being deployed any time soon.
The idea of it gives me heartburn.

But, in the general case of p2p, i certainly expect WebRTC to works
with ICE / STUN / TURN.  This is a use case i am very interested in
supporting, especially with IPv6 end-to-end and IPv6 <->IPv4 via TURN.

In the case of TMUS, users are able to use IPv6 to communicate freely
with anyone on the internet without any *stateful* filters.  And,
according to Lorenzo's report, TMUS subscribers will have a nice e2e
internet flow with anyone on Docomo.

I am hopeful more network operators will see it our way.

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

---

From: james woodyatt <[email-masked]>
Date: Tue, 10 Sep 2013 13:35:15 -0700

On Sep 10, 2013, at 12:45, Owen DeLong <[email-masked]> wrote:
> […]

At present, most of the wireline residential IPv6 service providers are allowing unsolicited inbound flows. It’s just some large wireless mobile IPv6 service providers and host implementations that are blocking it wholesale. I’m currently thinking that I-D.ietf-v6ops-mobile-device-profile could be a reasonable vehicle for IETF to recognize that this is admissible only in the case of 3GPP hosts, but not necessarily for all of the Internet. Trying to contain the ongoing damage here, but the major damage is done and unrepairable now.

> I don't think we should admit defeat, but we should fix this for more than just cellular.

I think it’s too late to fix this.  The time to fix it was before RFC 6092 went to publication, and arguably before RFC 4864 went to publication.  We failed utterly.  It’s done.  Time to move on.

---

From: james woodyatt <[email-masked]>
Date: Tue, 10 Sep 2013 13:53:52 -0700

> I am hopeful more network operators will see it our way.

In shorter terms: you concur with me that I-D.ietf-v6ops-mobile-device-profile should drop all its current recommendations regarding the deployment of PCP clients in cellular hosts. Is that so?

---

From: "cb.list6" <[email-masked]>
Date: Tue, 10 Sep 2013 14:01:51 -0700

On Tue, Sep 10, 2013 at 1:53 PM, james woodyatt <[email-masked]> wrote:
> In shorter terms: you concur with me that
> I-D.ietf-v6ops-mobile-device-profile should drop all its current
> recommendations regarding the deployment of PCP clients in cellular hosts.
> Is that so?
>

I have made that case, but that idea was in the rough from the author team.

CB

---

From: Owen DeLong <[email-masked]>
Date: Tue, 10 Sep 2013 14:47:09 -0700

> At present, most of the wireline residential IPv6 service providers are allowing unsolicited inbound flows. It’s just some large wireless mobile IPv6 service providers and host implementations that…

I don't think that the IETF is going to have much impact here no matter what goes into a draft.

Further, trying to overcome the (bad) administrative decisions of service providers through IETF process seems a perilous precedent in the long run.

This is the kind of thing that more calls for regulation than for IETF standards. The standards are already on the books for how to support the proper movement of packets. Blocking them isn't a standards-related decision, it's poor administrative practice.

I don't see much of a difference between this and some of Comcast's earlier misguided rate-shaping behaviors that got them a nice slap on the wrist from the FCC.

> I think it’s too late to fix this.  The time to fix it was before RFC 6092 went to publication, and arguably before RFC 4864 went to publication.  We failed utterly.  It’s done.  Time to move on.

No, RFCs are the wrong place to fix it. The place to fix it is either through consumer demand (Cameron's latest post has me contemplating a switch from VZW to T-Mo if VZW doesn't fix it for me soon) and/or regulation. It's really not a standards issue.

Owen

---

From: <[email-masked]>
Date: Wed, 11 Sep 2013 08:23:03 +0200

Hi all,

Yes, that was discussed among authors and decided to go for a SHOULD. 

One comment here: the ICE & cie path is not ideal ... and may require PCP to solve various issues: see http://tools.ietf.org/html/draft-penno-rtcweb-pcp-00 for more details. 

For the particular case of the voice over IP in managed networks (which will be the case for mobile VoIP), some benefits of PCP are: 

   o  Avoid embedding an ALG in the middleboxes.  Note, ALGs are not
      recommended since the evolution of the service would depend on the
      ALG maintenance.
   o  Not require any Hosted NAT Traversal function (e.g.,
      [I-D.ietf-mmusic-latching]) to be embedded in the SIP server.
      Intermediate NATs and firewalls are transparent to the SIP service
      platform.
   o  Avoid overloading the network with keepalive message to maintain
      the mapping in the mid-box.
   o  Not require symmetric RTP/RTCP to work.
   o  Not require symmetric SIP to work (i.e., rport [RFC3581]).
   o  Easily support unidirectional sessions.
   o  No early media issues.
   o  Because there is no need for connectivity checks, session
      establishment delay is not impacted (pairs of ports can be pre-
      reserved)

Cheers,
Med

>-----Message d'origine-----
>De : [email-masked] [mailto:[email-masked]] De la part de
>cb.list6
>Envoyé : mardi 10 septembre 2013 23:02
>À : james woodyatt
>Cc : [email-masked] WG
>Objet : Re: [v6ops] PCP and I-D.ietf-v6ops-mobile-device-profile
>
>> [.]
>> [.]

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 11 Sep 2013 08:59:20 +0200 (CEST)

On Tue, 10 Sep 2013, james woodyatt wrote:

> Shorter james: it’s time to admit defeat. We blew it— there will never 
> be direct peer-to-peer telecommunications with IPv6, particularly with 
> cellular hosts. All that traffic must be directed through relays in the 
> network where it can be subject to police wiretap and social network 
> analysis.

I don't agree.

Looking at the design goals of 5G, the next generation networks will be 
engineered for massive device scale and very different traffic patterns. 
The small packets (backscatter or scanning) killing signaling (and battery 
life) in 3G is done a lot better in LTE, and most likely in 5G it'll be 
even less impacting.

For mobile operators there is a huge incentive to block incoming 
connections to mobile today (3G) but less so going forward. Handset 
manufacturers also have a huge role in this in hardering their hosts so 
that they can actually handle being exposed to the Internet (they already 
are by large I'd say) and ask the baseband vendors to not implement 
filtering there (I don't understand why someone would do that, the 
"computer part" of the device can't be that bad at handling incoming 
connections, right?). I can understand wanting to save battery for 
customers by the ISP filtering unsolicited packets in 3G, but not going 
forward.

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Thu, 12 Sep 2013 16:45:24 +0000

Hi,

Inline with [RP]

From: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, September 10, 2013 1:27 AM
To: james woodyatt <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]> WG" <[email-masked]<mailto:[email-masked]>>
Cc: Cisco Employee <[email-masked]<mailto:[email-masked]>>
Subject: RE: [v6ops] PCP and I-D.ietf-v6ops-mobile-device-profile

Hi James,

I appreciate your effort for reading and raising a technical point. I really don’t care if you shared this comment during the WGLC or now once the IETF LC is over.

Some general answers:

* Motivations for PCP from a provider perspective are mentioned in the document. No need to re-iterate that. From a customer standpoint, some users are using their mobile connection as their main line. As such, they have the same requirements as for fixed services. I have been told that there are customers running game consoles using their mobile connection (If I’m not mistaken, Reinaldo has mentioned this case in an e-mail. I will let him confirm/infirm).

[RP] Right, FWIW in US there are wireless subscriber (LTE/4G) that do not have wireline internet. They use (and expect) this high speed wireless to carry traffic usually associated with wireline deployments. The case through a Wireless provider was related to subscribers that want to use XBOX through 4G/LTE.

Cheers,
Med

De : [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] De la part de james woodyatt
Envoyé : lundi 9 septembre 2013 17:59
À : [email-masked]<mailto:[email-masked]> WG
Objet : [v6ops] PCP and I-D.ietf-v6ops-mobile-device-profile

everyone—

           retrieve the PREFIX64.