IETF Logo Mail Archive

Re: [homenet] Comments requested for draft CER-ID

Markus Stenberg <markus.stenberg@iki.fi> Mon, 27 October 2014 13:21 UTC

Return-Path: <markus.stenberg@iki.fi>
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6F181A923E for <homenet@ietfa.amsl.com>; Mon, 27 Oct 2014 06:21:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.279
X-Spam-Level:
X-Spam-Status: No, score=0.279 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779] autolearn=no
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 0fQoC6htDXXh for <homenet@ietfa.amsl.com>; Mon, 27 Oct 2014 06:21:00 -0700 (PDT)
Received: from jenni1.inet.fi (mta-out1.inet.fi [62.71.2.194]) by ietfa.amsl.com (Postfix) with ESMTP id B82091AC428 for <homenet@ietf.org>; Mon, 27 Oct 2014 06:20:52 -0700 (PDT)
Received: from poro.lan (80.220.64.126) by jenni1.inet.fi (8.5.142.08) (authenticated as stenma-47) id 541949910365C1D5; Mon, 27 Oct 2014 15:20:48 +0200
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Markus Stenberg <markus.stenberg@iki.fi>
In-Reply-To: <D0739ED2.D31D%m.kloberdans@cablelabs.com>
Date: Mon, 27 Oct 2014 15:20:45 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <A06B0EA0-5817-4584-9010-776FC1CE1C90@iki.fi>
References: <D0739ED2.D31D%m.kloberdans@cablelabs.com>
To: Michael Kloberdans <m.kloberdans@cablelabs.com>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/5j10Rc7vvB6tW7esEml7z9Yud50
Cc: "homenet@ietf.org" <homenet@ietf.org>, Markus Stenberg <markus.stenberg@iki.fi>
Subject: Re: [homenet] Comments requested for draft CER-ID
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <homenet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/homenet>, <mailto:homenet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/homenet/>
List-Post: <mailto:homenet@ietf.org>
List-Help: <mailto:homenet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/homenet>, <mailto:homenet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Oct 2014 13:21:01 -0000

On 27.10.2014, at 15.03, Michael Kloberdans <m.kloberdans@cablelabs.com> wrote:
> Behaviors resulting from the knowledge of the CER are left to other implementations.  One implementation detects the CER and disables firewall, NAPT and allocates PD requests for all Internal Routers (non-CER), but this is just one example of applying behaviors based on knowing where the CER lies.

First, draft comments..

Section 2 - why clients SHOULD send the ORO for this at all? Perhaps it is MAY, just server responding with one.  Why use WAN _or_ unique LAN interface address? Inconsistency is not a plus. Also, it is not obvious to me what to do if  it has one LAN interface but multiple addresses..

Then, non-draft comments ..

I am not sure evil bit (that ISP must obviously be nice enough to set, i.e. cer_id ::) is really what I would trust my firewalling decisions on. In Cablelabs context this is especially puzzling, as you have ISP-facing holes (with weird antenna-style bits in them), and home facing holes (RJ45 or wireless). Why is this autodetection needed at all there? Or is it just so ISP _can_ turn off the firewall if they want to, or government wants to force them to do so?

Cheers,

-Markus

v2.23.0 | Report a Bug | By Email