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

"STARK, BARBARA H" <bs7652@att.com> Mon, 27 October 2014 18:27 UTC

Return-Path: <bs7652@att.com>
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 473521A8A88 for <homenet@ietfa.amsl.com>; Mon, 27 Oct 2014 11:27:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level:
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 wOFCzLMQGn98 for <homenet@ietfa.amsl.com>; Mon, 27 Oct 2014 11:27:05 -0700 (PDT)
Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B6051A0194 for <homenet@ietf.org>; Mon, 27 Oct 2014 11:23:40 -0700 (PDT)
Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.2-0) with ESMTP id cad8e445.2b7aff86b940.4643206.00-2449.12993774.nbfkord-smmo06.seg.att.com (envelope-from <bs7652@att.com>); Mon, 27 Oct 2014 18:23:40 +0000 (UTC)
X-MXL-Hash: 544e8dac024d4336-b845199204a8e1432fd7a4a7e092138d83f984ca
Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.2-0) over TLS secured channel with ESMTP id b8d8e445.0.4642860.00-2208.12992803.nbfkord-smmo06.seg.att.com (envelope-from <bs7652@att.com>); Mon, 27 Oct 2014 18:23:10 +0000 (UTC)
X-MXL-Hash: 544e8d8e7b832bc1-cdaf4d3d43a6c1cc9778ccef3eee67fe0a93fa1b
Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s9RIN6YD015345; Mon, 27 Oct 2014 14:23:06 -0400
Received: from alpi131.aldc.att.com (alpi131.aldc.att.com [130.8.218.69]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s9RIMqbK015215 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 27 Oct 2014 14:22:55 -0400
Received: from GAALPA1MSGHUBAF.ITServices.sbc.com (GAALPA1MSGHUBAF.itservices.sbc.com [130.8.218.155]) by alpi131.aldc.att.com (RSA Interceptor); Mon, 27 Oct 2014 18:22:40 GMT
Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.152]) by GAALPA1MSGHUBAF.ITServices.sbc.com ([130.8.218.155]) with mapi id 14.03.0195.001; Mon, 27 Oct 2014 14:22:40 -0400
From: "STARK, BARBARA H" <bs7652@att.com>
To: Michael Kloberdans <M.Kloberdans@cablelabs.com>, Markus Stenberg <markus.stenberg@iki.fi>
Thread-Topic: [homenet] Comments requested for draft CER-ID
Thread-Index: AQHP8eZyBnMT2tvAoEOB5hY9+dInupxEMOKAgAAP7gCAAAg4gIAAEmEA//++LDA=
Date: Mon, 27 Oct 2014 18:22:40 +0000
Message-ID: <2D09D61DDFA73D4C884805CC7865E61130EA81CA@GAALPA1MSGUSRBF.ITServices.sbc.com>
References: <D0739ED2.D31D%m.kloberdans@cablelabs.com> <A06B0EA0-5817-4584-9010-776FC1CE1C90@iki.fi> <D073AA38.D326%m.kloberdans@cablelabs.com> <9C9AAA6C-61E0-4BAB-9BB4-DA02B74835FD@iki.fi> <D073C4AF.D36F%m.kloberdans@cablelabs.com>
In-Reply-To: <D073C4AF.D36F%m.kloberdans@cablelabs.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.70.6.241]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-AnalysisOut: [v=2.0 cv=X9rl3hve c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a]
X-AnalysisOut: [=riIHBUA8hK4A:10 a=BLceEmwcHowA:10 a=IkcTkHD0fZMA:10 a=zQP]
X-AnalysisOut: [7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=jU2thFBwAAAA:8 a=48vgC7mUAA]
X-AnalysisOut: [AA:8 a=uFSKDfX_B7JSQYYPPGYA:9 a=QEXdDO2ut3YA:10 a=ShkLpKDU]
X-AnalysisOut: [LFQA:10 a=z5GxMmkQ6zqjZ1Os:21 a=F8LcOWKmZZWWYAhQ:21]
X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)]
X-MAIL-FROM: <bs7652@att.com>
X-SOURCE-IP: [144.160.229.23]
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/kdaXa4zPYN6SpYuDxvyfX7eT4EU
Cc: "homenet@ietf.org" <homenet@ietf.org>
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 18:27:09 -0000

My comments continue to be:
I think an indication of "this interface is external" (i.e., don't trust me, this is a "public" network) can be valuable in applying "external" classification to an interface. I'm happy not to trust those who claim to be untrustworthy. But that doesn't seem to be the primary focus of this CER ID proposal. I think that trying to use certain CER ID values as an indication of "this interface is internal" (i.e., trust me -- really!) is problematic.

The idea that the CER ID will somehow cause consistent behavior by IRs has no basis, because the expectation for IRs to treat the CER ID as a "trust me -- really!" indication is problematic. I would be opposed to any suggestion that IRs trust a "trust me -- really!" CER ID value and behave in a trusting manner as a result of it. As Markus suggests, other indicators should be used for positive identification of internal interfaces.

I consider the formatting of the option as an IP address to be flawed. If it is the case that CableLabs would not accept IETF input to change this option to a format that IETF participants would find useful (because it's already this way in the eRouter specs and eRouter vendors are implementing it), then I think it should not be standardized by IETF and should remain a vendor option specified purely in the eRouters specs. 

If others think that an indication of "this interface is external" would be useful, then I would be happy to propose such a thing, or work with others to propose such a thing. I would make it a flag. It might be useful to consider including other flags (e.g., multiple IA_PD requests are ok / not ok) in the option as well. It would be an option that comes from ISPs to indicate preferred expected behavior on the external interface.

I'm opposed to ISPs trying to control what happens on my home network's internal interfaces through standardized DHCP options. That's one of the reasons I only have non-ISP provided/affiliated routers in my home. In fact, I would want my routers to identify any ISP-provided device as being on an external interface.  I'm absolutely unwilling to accept anything that would allow an ISP to disable my internal router's firewall. I would prefer to have the firewall on the ISP router be disabled, if there is a firewall on an internal router. 
Barbara 

> Markus,
> CER-ID can apply to more than just the cable industry.  DSL modems and
> satellite services can also take advantage of the benefits if we don’t lock
> down the interface.  Also, some home owners may not want the natural
> boundary being the Cable modem or DSL modem and this provides a way to
> make that happen.
> 
> Do you still want to discuss how or why CER-ID is implemented this way?
> 
> Thank you for your comments so far.
> 
> 
> Michael Kloberdans
> Lead Architect / Home Networking     CableLabs®
> 
> 858 Coal Creek Circle.  Louisville, CO. 80027
> 303-661-3813 (v)
> 
> 
> 
> 
> On 10/27/14, 8:47 AM, "Markus Stenberg" <markus.stenberg@iki.fi> wrote:
> 
> >On 27.10.2014, at 16.17, Michael Kloberdans
> ><m.kloberdans@cablelabs.com>
> >wrote:
> >> All home routers should know their role; CER or IR.  The status of
> >>CER  places the burden of providing the firewall and NAPT as it was
> >>determined  to be the edge router.  The interior routers need to
> >>understand their role  and disable their firewall and NAPT abilities.
> >>This is why the CER-ID is  a numeric value (indicating CER status) or
> >>a double colon (indicating IR  status).
> >
> >I agree with that. However, I disagree with how you are doing it.
> >
> >> In the case of the eRouter (combined cable modem and
> >>router/switch/wireless), it performs a /48 check between the IA_NA and
> >>the  IA_PD ranges.  If the ISP sends a double colon or null in the
> >>CER-ID ORO,  AND if the IA_NA is in a different /48 than the given
> >>IA_PD, the eRouter  becomes the CER.  It must now declare to the IRs
> >>that it is the CER.  A  directly connected IR will see the CER value
> >>in the ORO and, in the  absence of another controlling protocol,
> >>disable its firewall and NAPT  functions.
> >
> >Why cannot it determine it is CER by bits coming from particular type
> >of plug? Cable modem plug looks different from ethernet/wireless? It
> >would be much more secure that way.
> >
> >> The nice advantage of the double colon is for network literate people
> >>like  yourself to manually determine where the boundary between public
> >>and  private network will be.  If you didn¹t want the Cable or DSL
> >>modem to be  the CER, manually give them a Œ::² and assign a CER-ID to
> >>a downstream  router.  Thus, CER-ID allows for automatic detection of
> >>the CER and  uniform behavior of IRs within the home and also a way to
> >>design your  network the way you desire.
> >
> >Again, bits coming from cable port <> not sounds much simpler to me.
> >And more secure.
> >
> >Cheers,
> >
> >-Markus
> 
> _______________________________________________
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet