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

From: Michael Kloberdans <[email-masked]>
Date: Mon, 27 Oct 2014 13:03:48 +0000

As co-chair of the Homenet working group, Mark Townsley suggested that the Homenet group provide comments on the CER-ID (Customer Edge Router Identification), draft before adding it to the Homenet agenda for IETF-91.

This draft proposes a DHCP option that explicitly identifies a specific home router as the edge between the boundary of the public and private networks at the home.  The CER has a public-facing interface and one or more internal-facing interface(s).  Conversely, it also identifies internal routers that are not at the boundary edge.  Knowing the edge is important for applying services such as a firewall, NAPT and requesting IPv6 PDs.

This draft also provides a mechanism to change the default automatically or manually assigned edge router.  This draft peacefully co-exists with other border detection and other assignment methods.  The CER-ID draft features have already been incorporated into Cable Industry specifications for eRouter (Cable Modem integrated into a routing, switching unit), but could also be helpful to TELCO and other industries.

Flexibility was built-in by allowing multiple numbering schemes to identify the CER, including up to 128-bits for an IPv6 address.  A simple number can also be used to act as a flag if desired.  Again, the ability to manually or automatically move the designation of the edge router is available by using a double colon ‘::’ in the CER-ID field and indicates that router is NOT the Edge router.

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.

Please read this short draft below and provide comments.

Regards,

Network Working Group                                          C. Donley
Internet-Draft                                             M. Kloberdans
Intended status: Informational                                 CableLabs
Expires: February 13, 2015                                 J. Brzozowski
                                                                 Comcast
                                                           C. Grundemann
                                                                    ISOC
                                                         August 12, 2014

               Customer Edge Router Identification Option
                   draft-donley-dhc-cer-id-option-04

Abstract

   Addressing mechanisms supporting DHCPv6 Prefix Delegation in home
   networks such as those described in CableLabs' eRouter specification
   and the HIPnet Internet-Draft require identification of the customer
   edge router (CER) as the demarcation between the customer network and
   the service provider network.  This document reserves a DHCPv6 option
   to identify the CER.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on February 13, 2015.

Copyright Notice

   Copyright (c) 2014 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents

Donley, et al.          Expires February 13, 2015               [Page 1]
Internet-Draft                cer-id-option                  August 2014

   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   2
   2.  CER Identification Option . . . . . . . . . . . . . . . . . .   2
   3.  CER-ID Compatibility  . . . . . . . . . . . . . . . . . . . .   4
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   4
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   4
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   5
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   5
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   5

1.  Introduction

   Some addressing mechanisms supporting DHCPv6 Prefix Delegation in
   home networks such as those described in
   [I-D.grundemann-homenet-hipnet] and [EROUTER] require identification
   of the customer edge router as the demarcation between the customer
   network and the service provider network.  For prefix delegation
   purposes, it is desirable for other routers within the home to know
   which device is the CER so that the customer home network only
   requests a single prefix from the ISP DHCPv6 server, and efficiently
   distributes this prefix within the home.  CER-ID is a 128-bit string
   that optionally represents an IPV6 address, or another arbitrary
   number.  The CER-ID maybe treated as a hint to be used with border
   detection methods.  This document reserves a DHCPv6 option to be used
   to identify the CER.

1.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

2.  CER Identification Option

   A Customer Edge Router (CER) sets the CER_ID to the IPv6 address of
   its LAN interface.  If it has more than one LAN IPv6 address, it
   selects one of its LAN or loopback IPv6 addresses to be used in the
   CER_ID.  An ISP server does not respond with the CER_ID or sets the

Donley, et al.          Expires February 13, 2015               [Page 2]
Internet-Draft                cer-id-option                  August 2014

   CER_ID to ::.  Such a response or lack of response indicates to the
   DHCPv6 client that it is the CER.

   The format of the CER Identification option is:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      option-code              |      option-len               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                           CER_ID                              |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       option-code          OPTION_CER_ID (TBD).
       option-len           36
       CER_ID value         IPv6 address of CER or ::

   Figure 1.

   A DHCPv6 client SHOULD include the CER Identification option code in
   an Option Request option [RFC3315] in its DHCP Solicit messages.

   The DHCPv6 server MAY include the CER Identification option in any
   response it sends to a client that has included the CER
   Identification option code in an Option Request option.  The CER
   Identification option is sent in the main body of the message to
   client, not as a sub-option in, e.g., an IA_NA, IA_TA
   [RFC3315]option.

   When sending the CER Identification option, the DHCPv6 server MUST
   set the CER_ID value to either one of its IPv6 addresses, another
   identifier, or ::. If a device does not receive the CER
   Identification Option or receives a CER ID of :: from the DHCPv6
   server, it MUST include one of its Globally Unique IPv6 addresses
   (unless another identifier is used), in the CER_ID value in response
   to DHCPv6 messages received by its DHCPv6 server that contains the
   CER Identification option code in an Option Request option.  If the
   device has only one LAN interface, it SHOULD use its LAN IPv6 address
   as the CER_ID value.  If the device has more than one LAN interface,
   it SHOULD use the lowest Globally Unique address not assigned to its
   WAN interface.

Donley, et al.          Expires February 13, 2015               [Page 3]
Internet-Draft                cer-id-option                  August 2014

3.  CER-ID Compatibility

   CER-ID explicitly indicates that a gateway is, or is not, the
   demarcation point between public and private networks by containing a
   reachable IPv6 address, other identifier or a double colon '::'
   (double colon indicates that the CER-ID sender is NOT the edge
   router), and as a compliment, can be applied to various border
   definitions and detection methods such as:

   o  I.D.  Draft-IETF-Homenet-Arch-16 [I-D.ietf-homenet-arch]

   o  I.D.  Draft-Grundemann-homenet-HIPnet-01
      [I-D.grundemann-homenet-hipnet]

   o  I.D.  Draft-IETF-Kline-Homenet-Default-Perimeter-01
      [I-D.kline-default-perimeter]

   o  Others, including manual configuration

4.  IANA Considerations

   IANA is requested to assign an option code from the "DHCP Option
   Codes" Registry for OPTION_CER_ID.  IANA is also requested to
   maintain a list of authentication options.

5.  Security Considerations

   The security of a home network is an important consideration.  Both
   the HIPNet [I-D.grundemann-homenet-hipnet] and Homenet
   [I-D.ietf-homenet-arch] approaches change the operational model of
   the home network vs. today's IPv4-only paradigm.  Specifically, these
   networks eliminate NAT inside the home network (and only enable it
   for IPv4 at the edge router, if required), support global
   addressability of devices, and thus need to consider firewall and/or
   filter support in various home routers.  As the security profile of
   these home routers can shift based on their position in the network
   (e.g., edge vs. internal), security can be severely compromised if
   routers misidentify their border and mistakenly reduce or eliminate
   firewall rules.  If the CER-ID option is used as part of the border
   detection algorithm, it becomes a natural, but not the only place to
   enact firewall, NAT, Prefix Delegation and other functions in the
   home network.

6.  Acknowledgements

Donley, et al.          Expires February 13, 2015               [Page 4]
Internet-Draft                cer-id-option                  August 2014

7.  References

7.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3315]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
              and M. Carney, "Dynamic Host Configuration Protocol for
              IPv6 (DHCPv6)", RFC 3315, July 2003.

7.2.  Informative References

   [EROUTER]  CableLabs, "CableLabs IPv4 and IPv6 eRouter Specification
              (CM-SP-eRouter-I12-131120)", April 2014.

   [I-D.grundemann-homenet-hipnet]
              Grundemann, C., Donley, C., Brzozowski, J., Howard, L.,
              and V. Kuarsingh, "A Near Term Solution for Home IP
              Networking (HIPnet)", draft-grundemann-homenet-hipnet-01
              (work in progress), February 2013.

   [I-D.ietf-homenet-arch]
              Chown, T., Arkko, J., Brandt, A., Troan, O., and J. Weil,
              "IPv6 Home Networking Architecture Principles", draft-
              ietf-homenet-arch-16 (work in progress), June 2014.

   [I-D.kline-default-perimeter]
              Kline, E., "Default Border Definition", draft-kline-
              default-perimeter-01 (work in progress), November 2012.

Authors' Addresses

   Chris Donley
   CableLabs
   858 Coal Creek Cir.
   Louisville, CO  80027
   US

   Email: [email-masked]<mailto:[email-masked]>

Donley, et al.          Expires February 13, 2015               [Page 5]
Internet-Draft                cer-id-option                  August 2014

   Michael Kloberdans
   CableLabs
   858 Coal Creek Cir
   Louisville, CO  80027
   US

   Email: [email-masked]<mailto:[email-masked]>

   John Brzozowski
   Comcast
   1306 Goshen Parkway
   West Chester, PA  19380
   US

   Email: [email-masked]<mailto:[email-masked]>

   Chris Grundemann
   ISOC
   Denver  CO

   Email: [email-masked]<mailto:[email-masked]>

Donley, et al.          Expires February 13, 2015               [Page 6]

Michael Kloberdans
Lead Architect / Home Networking     CableLabs®

858 Coal Creek Circle.  Louisville, CO. 80027
303-661-3813 (v)

---

From: Markus Stenberg <[email-masked]>
Date: Mon, 27 Oct 2014 15:20:45 +0200

> 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 Route…

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

---

From: Michael Kloberdans <[email-masked]>
Date: Mon, 27 Oct 2014 14:17:46 +0000

Markus,
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). 
 
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.

Having all IRs understand their role is allows consistent behaviors.

CER-ID can be any numeric value.  A simple number can act as a flag.  An
IPv6 address is urged because it allows communications between the CER and
the IRs, and may be used in the cable industry.

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.

Comments?

Michael Kloberdans

On 10/27/14, 7:20 AM, "Markus Stenberg" <[email-masked]> 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..
>
>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
>

---

From: Markus Stenberg <[email-masked]>
Date: Mon, 27 Oct 2014 16:47:11 +0200

> a numeric value (indicating CER status) or a double colon (indicating IR

I agree with that. However, I disagree with how you are doing it.

> absence of another controlling protocol, disable its firewall and NAPT

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.

> network the way you desire.

Again, bits coming from cable port <> not sounds much simpler to me. And more secure. 

Cheers,

-Markus

---

From: Ola Thoresen <[email-masked]>
Date: Mon, 27 Oct 2014 16:00:42 +0100 (CET)

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

But that would not work if the router only has ethernet-ports - which is probably the case if the customer has various kinds of FTTH (many of these will use Fast/Gig-ethernet over copper for the last meters in to the CPE).

However I do agree that the suggested solution seems sub optimal.  It is way to easy for a misconfigured router to disable all local security (IE. turning off firewalling) without the network owners knowledge.

/Ola (T)

---

From: Michael Kloberdans <[email-masked]>
Date: Mon, 27 Oct 2014 15:52:58 +0000

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

On 10/27/14, 8:47 AM, "Markus Stenberg" <[email-masked]> wrote:

>plug? Cable modem plug looks different from ethernet/wireless? It would
>be much more secure that way.
>

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Mon, 27 Oct 2014 18:22:40 +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 

> 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
> >On 27.10.2014, at 16.17, Michael Kloberdans
> ><[email-masked]>
> >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).
> >
> >>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.
> >
> _______________________________________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet

---

From: Michael Richardson <[email-masked]>
Date: Tue, 28 Oct 2014 15:37:11 -0400

> All home routers should know their role; CER or IR.  The status of CER

80% of the innovation of the Homenet working group is really to find a way to
avoid having to *tell* the routers this role.  Yes, they wind up deriving it,
and I agree that it's useful for the routers to emit their conclusion in
the form of CER-ID.

> 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 think that your document needs a 2-3 page explanation of reasons why
an router should believe the CER-ID it says.  It's a very clear attack vector
on a home router if you can get it to turn off it's firewall.

I don't think your security considerations is adequate; you likely did not
understand Markus' reference to the "evil bit", which a Steve Bellovin April
1 "RFC": rfc3514.txt.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 30 Oct 2014 21:45:49 +0100 (CET)

>   The format of the CER Identification option is:

I am not an expert when it comes to DHCP. Is there something implicit in 
the way that DHCP options are designed that makes it obvious that the 
"CER_ID value" is using ASCII or 128 bits binary to represent the IPv6 
address? Because it's not obvious to me from reading the above text.

-- 
Mikael Abrahamsson    email: [email-masked]