Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"?

<> Fri, 13 February 2015 07:21 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 2D1951A1B62 for <>; Thu, 12 Feb 2015 23:21:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JMigtLoCWtQc for <>; Thu, 12 Feb 2015 23:21:54 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 791871A1B53 for <>; Thu, 12 Feb 2015 23:21:53 -0800 (PST)
Received: from (unknown [xx.xx.xx.4]) by (ESMTP service) with ESMTP id 0B77A264229; Fri, 13 Feb 2015 08:21:52 +0100 (CET)
Received: from Exchangemail-eme2.itn.ftgroup (unknown []) by (ESMTP service) with ESMTP id E065723805C; Fri, 13 Feb 2015 08:21:51 +0100 (CET)
Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([]) by OPEXCLILH05.corporate.adroot.infra.ftgroup ([]) with mapi id 14.03.0224.002; Fri, 13 Feb 2015 08:21:51 +0100
From: <>
To: James Woodyatt <>
Thread-Topic: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"?
Thread-Index: AQHQRvgMtdv8/yjdEkq8+myPex9ad5zuJKIw
Date: Fri, 13 Feb 2015 07:21:50 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B93300490A7FF@OPEXCLILM23.corporate.adroot.infra.ftgroup>
References: <787AE7BB302AE849A7480A190F8B9330049091C2@OPEXCLILM23.corporate.adroot.infra.ftgroup> <> <787AE7BB302AE849A7480A190F8B933004909864@OPEXCLILM23.corporate.adroot.infra.ftgroup> <>
In-Reply-To: <>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93300490A7FFOPEXCLILM23corp_"
MIME-Version: 1.0
X-PMX-Version:, Antispam-Engine:, Antispam-Data: 2015.2.13.42120
Archived-At: <>
Cc: IPv6 Ops WG <>
Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"?
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 13 Feb 2015 07:21:59 -0000

Hi James,

Please see inline.


De : James Woodyatt []
Envoyé : jeudi 12 février 2015 20:14
Cc : IPv6 Ops WG
Objet : Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"?

Mr. Boucadair—

Yes, there is a problem. The draft seems to conflate the behavior of residential broadband CPE gateways with 3GPP radios and mobile telephony handsets with tethering interfaces.

[Med] No. The recommendation is about “mobile CPE” used in various deployment to provide broadband services. An example can be found here ( Except the access technology, services offered using these CPE are the same as any fixed CPE. Please let me reiterate the following: this draft does not recommend the support of RFC7084 for every “3GPP radios and mobile telephony handsets with tethering interfaces”. I added a CAUTION text in the latest version to make this clear:

                CAUTION: This recommendation does not apply to any
                cellular device with LAN capabilities; it is specific to
                cellular CPEs in order to ensure the same IPv6
                functional parity for both fixed and cellular CPEs.

I tend not to fight too hard against RFC 6092 in residential gateway scenarios, but I've always been opposed to seeing those recommendations applied more widely, especially if it seems— like it does in this case— that the recommendation is being made out of rote repetition rather than by careful technical consideration.

[Med] It is not about repetition but about a technical strategy that aims to ensure the same functional parity whatever the access technology used to service a customer. This is key for mobile-fixe convergence, mutualizing code, engineering practices, service design and operations, and more important testing and validation resources and effort.

Please forgive this digression: I have *never* wavered in my opposition to any recommendation or specification that calls for unmanaged network layer gateways to block unsolicited inbound transport layer flows by default. I have always preferred explicit recommendations to leave RFC 6092 filtering transparency mode by default, and to require an authorized human to "opt into" the blocking of inbound flows.

[Med] I’m personally with transparent mode set by default. If there is no objection from the working group, this can be added under security section.

Yes, RFC 6092 contains no such a recommendation. To my everlasting shame.

Because I was the technical editor for RFC 6092, and I was concerned about conducting myself in that role with equanimity and fairness, I was grudgingly willing to suspend my objections on this topic when the working group settled on language that expressly makes no recommendation on whether transparency should or should not the default. That seemed to reflect consensus at the time. If I had not been the technical editor for that document, then I would have more vigorously expressed my personal objections.

On a personal level, I'm no longer sure it's better to have a document that carefully describes the behavior of these ubiquitous and harmful firewalls than to have them go undocumented as was the case with IPv4/NAT firewalls. I haven't yet come to regret withholding my personal objections to RFC 6092, but I sometimes find that strong beer can dull the pain.

[Med] You can try an orange juice too ;-)

I *was* opposed to RFC 7084 (and its predecessor) because it did not take the view that RFC 6092 firewall capability SHOULD be set for transparency by default. I didn't win that argument, and I expect I will lose it again in the context of this draft— which I oppose for other reasons as well, but this is the one that animates me before the others.

I'm especially concerned that I-D.ietf-v6ops-mobile-device-profile seems to be too easily read to recommend the application of RFC 6092 firewalls inside mobile telephony handsets for tethered users.

[Med] As I explained above this is not the intent. I added a CAUTION for that purpose but if you still think there is still a risk, I can check how better to address your issue.

That's an expansion of the scope intended for RFC 6092 beyond the usage case of residential gateways, and I really wouldn't like to see that.

[Med] There is no expansion of the scope: a cellular CPE is a flavor of residential gateway in part of a country where fixed infrastructure is inexistent or inefficient.

Shorter james:

  *   I've got BIG problems recommending RFC 6092 firewalls for mobile telephony handsets with tethered hosts.
  *   I've got BIG problems whenever it even looks like IETF might be recommending RFC 6092 firewalls should be non-transparent by default.
  *   I've also got problems with recommending RFC 6092 firewalls without expressly cautioning that IETF takes no position on whether they should be transparent by default.
  *   I'm slightly annoyed whenever RFC 6092 firewalls are even recommended at all, but I can get over that with strong enough beer.

On Wed, Feb 11, 2015 at 10:39 PM, <<>> wrote:
Hi James,

Thank you for raising this point as it helps to clarify a confusion.

This document DOES NOT RECOMMENT RFC6092 for tethered hosts.

I guess you are referring to this item:

   L_REC#2:  The cellular CPE must be compliant with the requirements
             specified in [RFC7084<>]4>].

                There are several deployments, particularly in emerging
                countries, that relies on mobile networks to provide
                broadband services (e.g., customers are provided with
                mobile CPEs).

                Note, this profile does not require IPv4 service
                continuity techniques listed in [RFC7084<>] because those
                are specific to fixed networks.  IPv4 service continuity
                techniques specific to the mobile networks are included
                in this profile.

This is about cellular ** CPE ** not tethered devices (You may noticed that this item used explicitly “cellular CPE” while other items in this section uses “cellular device”). RFC7084 is required for this case to ensure a functional parity with fixed CPEs.

BTW, the text you suggested about RFC6092 is in the draft:

   In the case of cellular devices that provide LAN features, compliance

   with L_REC#2 entails compliance with [RFC7084<>]4>], which in turn

   recommends compliance with Recommended Simple Security Capabilities

   in Customer Premises Equipment (CPE) for Providing Residential IPv6

   Internet Service [RFC6092<>]2>].  Therefore, the security considerations

   in Section 6 of [RFC6092]<> are relevant.  In particular, it bears

   repeating here that the true impact of stateful filtering may be a

   reduction in security, and that IETF make no statement, expressed or

   implied, as to whether using the capabilities described in any of

   these documents ultimately improves security for any individual users

   or for the Internet community as a whole.

Are you suggesting that a mobile CPE should not have the same functionalities as the fixed one, and therefore RFC7084 should not be cited in this I-D? Or you are suggesting that RFC7084 is harmful?

Thank you.


De : James Woodyatt [<>]
Envoyé : mercredi 11 février 2015 18:51
Cc : IPv6 Ops WG
Objet : Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"?

On Wed, Feb 11, 2015 at 4:09 AM, <<>> wrote:

Which items are not technically justified?

Others may have other items that bug them, and additional items may spring to my mind later if I put my mind to it, but I see no technical justification to recommend a simple firewall by default for tethered hosts according to RFC 6092. I consider that recommendation to be actively harmful.

james woodyatt <<>>
Nest Labs, Communications Engineering

james woodyatt <<>>
Nest Labs, Communications Engineering