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

James Woodyatt <jhw@nestlabs.com> Thu, 12 February 2015 19:13 UTC

Return-Path: <jhw@nestlabs.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19F221A00A8 for <v6ops@ietfa.amsl.com>; Thu, 12 Feb 2015 11:13:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level:
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R4us6joU9xlg for <v6ops@ietfa.amsl.com>; Thu, 12 Feb 2015 11:13:53 -0800 (PST)
Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 177211A1AB3 for <v6ops@ietf.org>; Thu, 12 Feb 2015 11:13:52 -0800 (PST)
Received: by mail-ob0-f182.google.com with SMTP id nt9so11764777obb.13 for <v6ops@ietf.org>; Thu, 12 Feb 2015 11:13:52 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=SvD/2y6J3fDelAB3YjrYxcC75nzi5GD2ja/dRDPFhDI=; b=LfgbzvBmQd0lRxxRD1kB9/ckIVZA01wlZN5mVoWhhOkDyfgQbp5GzvkK0QISAjnhdL ksw0kCOM9uDbjbHFRibtr++G8QEJY+qH79iPiJNXCPsLeHvTr1EzXXdu9d+VWmKqRfdr L19GUnAX78UI+WvkBtV76F+7vACn0fq72dSIBQ0AwpGjcsCcULqR3PAXz7cntCKop1+E CIp2uhV9bd8n6J+55cSxtarZ8vANK6BZxahowKPRpRcqo3I8akRElolU9rUd73Os8lnG nvQLnMNpQ3Wd+INutsrMBllcdbSI7KOscF8Hmsbp9F8IPvfV9vmklOLMYII62reAFjNi Xd6Q==
X-Gm-Message-State: ALoCoQnwyak2B+7hNEA8GRUZ4z3wtBk47RlQQtw1yuFGVwPEX0mI8FRku6VK8XE/sl9qZc27rcNS
MIME-Version: 1.0
X-Received: by 10.202.95.2 with SMTP id t2mr3609853oib.104.1423768432459; Thu, 12 Feb 2015 11:13:52 -0800 (PST)
Received: by 10.76.150.2 with HTTP; Thu, 12 Feb 2015 11:13:52 -0800 (PST)
In-Reply-To: <787AE7BB302AE849A7480A190F8B933004909864@OPEXCLILM23.corporate.adroot.infra.ftgroup>
References: <787AE7BB302AE849A7480A190F8B9330049091C2@OPEXCLILM23.corporate.adroot.infra.ftgroup> <CADhXe52o=Vxux1+G8_EXgE_-a3Mest_LD6Hzzqu=hDp3H++Ttw@mail.gmail.com> <787AE7BB302AE849A7480A190F8B933004909864@OPEXCLILM23.corporate.adroot.infra.ftgroup>
Date: Thu, 12 Feb 2015 11:13:52 -0800
Message-ID: <CADhXe52v+qJGrTc1W8U7PMTjTvHcnZhwbT3CTDGfTgA4qOHmLg@mail.gmail.com>
From: James Woodyatt <jhw@nestlabs.com>
To: mohamed.boucadair@orange.com
Content-Type: multipart/alternative; boundary=001a113cdccea8deb5050ee8eb76
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/5u0XY8jnXZ-sMH4uxNeNS_TYfJ8>
Cc: IPv6 Ops WG <v6ops@ietf.org>
Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"?
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Feb 2015 19:13:57 -0000

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. 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.

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.

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.

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. 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.

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, <mohamed.boucadair@orange.com> 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 <http://tools.ietf.org/html/rfc7084>].
>
>
>
>                 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
> <http://tools.ietf.org/html/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 <http://tools.ietf.org/html/rfc7084>], which in turn
>
>    recommends compliance with Recommended Simple Security Capabilities
>
>    in Customer Premises Equipment (CPE) for Providing Residential IPv6
>
>    Internet Service [RFC6092 <http://tools.ietf.org/html/rfc6092>].  Therefore, the security considerations
>
>    in Section 6 of [RFC6092] <http://tools.ietf.org/html/rfc6092#section-6> 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.
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :* James Woodyatt [mailto:jhw@nestlabs.com]
> *Envoyé :* mercredi 11 février 2015 18:51
> *À :* BOUCADAIR Mohamed IMT/OLN
> *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, <mohamed.boucadair@orange.com> 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 <jhw@nestlabs.com>
>
> Nest Labs, Communications Engineering
>



-- 
james woodyatt <jhw@nestlabs.com>
Nest Labs, Communications Engineering