Subject: Re: [homenet] draft-chown-homenet-arch-00.txt

From: Erik Nordmark <[email-masked]>
Date: Mon, 03 Oct 2011 21:35:54 -0700

On 9/21/11 5:27 AM, Tim Chown wrote:
> Hi,
>
> I have been working with Jari, Jason and Ole to produce a new version
> of the homenet architecture draft. Mark, who produced the first
> version with Jari, is now of course WG chair and has stepped down as
> editor of the text.

One thing I've been looking for is a way to avoid boiling the ocean; I 
think being able to assign stable IP address prefixes in an arbitrary 
topology is a hard problem, yet I think there simple home topologies 
that show up today with IPv4 NATs that we should be able to handle with 
relative ease.

Today's IPv4 consumer home routers have a designated uplink port 
(labeled "Internet", "WAN", or something similar) and the behavior is 
different on that port (where it runs a DHCPv4 client) and the other 
ports (where it runs a DHCPv4 server). If we start with a simple 
solution to target such devices for IPv6 home networks (without IPv6 
NATs), then we can come up with hierarchical prefix delegation and 
default routes towards the delegating routers; no need to ensure that a 
single stable prefix is assigned to each link in an arbitrary topology 
of routers.

Then we can work on that harder problem as an extension of the simple 
approach for the simple topologies.

    Erik

---

From: "Howard, Lee" <[email-masked]>
Date: Wed, 5 Oct 2011 15:59:45 -0400

(Doing my homework at the last minute.)

First, let me say that I think this document is well-written, and I like the way it builds up from fundamentals to explain why the architecture ought to meet certain cases.

The last paragraph of "Multiple Segments" says "multiple routers" but that principle hasn't been mentioned.  I agree that the architecture should allow for it, but it comes up abruptly.

The section "   Security, Borders, and the elimination of NAT" discusses security, but provides no architecture or advice.  It seems odd to lump these things together, unless there is an assumption that Borders are firewalls or advanced-security-monsters.  For defense in depth, that unstated assumption should be explicitly repudiated.  There's not really any discussion of the elimination of NAT.

"Naming and service discovery are thus important, but they {may==>should} also be expected to operate across the scope".  Or "should" could be "will" or "would" if you want to avoid rfc2119 language.

"For the purposes of this memo and IP layer
   operation this arrangement is considered equivalent to the topology
   in Figure 1."
Huh?  How could they be equivalent?

Figure 3 has some vertical lines that I think are strays.  I wouldn't expect a host in a home network to have two simultaneous connections to the same network segment (e.g., Network A, or Network B).

The principle "Largest Possible Subnets" is explained, but given that routing will be required, the reasons why large L2 domains are preferable to routing are still unclear.

The "Transparent End-to-End" principle is clearer now than it the previous draft.  To make the language consistent with rfc1958 though, it should be mentioned that end-to-end communications are important for their robustness to failure of intermediate systems, and that NAT (and firewalling, if you want to argue that) is dependent on state machines which are not self-healing.

Why is "IP Connectivity between All Nodes" an important architectural principle?  What if the SmartGrid guys don't want us touching some of their nodes?  What if some parts of the network are managed and others are unmanaged?  The reason for this principle is unclear, and seems only to constrain us where constrain may or may not be needed.

I'd like to add a modifier to "Self-Organization" that manual configuration should override self-organization.

"Least Topology Assumptions" should be "Fewest Topology Assumptions."

The "Intelligent Policy" principle is poorly defended.  Apparently Cisco wants to sell database/signature updates, but this principle presumes consensus on an operating model  that has never been tried.  If the sentence "these traffic patterns should be driven off up-to-date databases in the Internet" is removed, I do not object.

Section 3.5 needs to be rewritten.  It asserts that little to no protocol work is necessary, when previous sections said (or asked) that remains to be seen.  It's difficult to assert that extensions are possible without defining the requirements or at least use cases, and naming the protocols to be extended.

I'm arriving very late tonight.  See you all tomorrow.

Lee

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Tim
> Chown
> Sent: Wednesday, September 21, 2011 8:27 AM
> To: [email-masked]
> Subject: [homenet] draft-chown-homenet-arch-00.txt
>
> Hi,
>
> I have been working with Jari, Jason and Ole to produce a new version of the homenet
> architecture draft. Mark, who produced the first version with Jari, is now of course WG
> chair and has stepped down as editor of the text.
>
> The structure of the draft remains similar. We have expanded section 2 on IPv6 implications
> for home networking, added a couple of extra models in section 3, expanded the principle
> section and also added a considerations section where we discuss certain topics that may (or
> may not) be deemed in scope for the text.
>
> Feedback is of course welcome, indeed required!
>
> I don't know whether Mark and Ray will call for WG adoption at this stage. The charter
> targets a WG draft by the end of September, but this is also a document that I hope will
> have some additional revisions from your feedback before the interim meeting.
>
> There are some acknowledgements to be added; these will be included in the next version.
>
> Tim
>
> On 21 Sep 2011, at 12:37, [email-masked] wrote:
>
> > A New Internet-Draft is available from the on-line Internet-Drafts directories.
> >
> >     Title           : Home Networking Architecture for IPv6
> >     Author(s)       : Jari Arkko
> >                          Tim Chown
> >                          Jason Weil
> >                          Ole Troan
> >     Filename        : draft-chown-homenet-arch-00.txt
> >     Pages           : 20
> >     Date            : 2011-09-21
> >
> >   This text describes the evolving networking technology within small
> >   &quot;residential home&quot; networks.  The goal of this memo is to define the
> >   architecture for IPv6-based home networking.  The text highlights the
> >   impact of IPv6 on home networking, and illustrates some topology
> >   scenarios.  The architecture shows how standard IPv6 mechanisms and
> >   addressing can be employed in home networking, lists a number of
> >   principles that should apply, and outlines the need for specific
> >   protocol extensions for certain additional functionality.
> >
> >
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-chown-homenet-arch-00.txt
> _______________________________________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: Russ White <[email-masked]>
Date: Tue, 11 Oct 2011 09:50:01 -0400

> We would like to get plenty of review and comment. 

Rather than dealing with individual edits, I'd rather start with a
general philosophy question. I understand that the IETF thinks NATs are
evil, but I also think there shouldn't be so much emphasis on "homenets
are not NAT," in an architecture document. Can we sideline the entire
discussion over NATs. They're going to be there no matter what.

My second concern is that while I understand the "end-to-end principle,"
I also know that it's not realistic in many situations --and the home is
one place where it's probably not. I know, I know, this is all heresy,
but hear me out for a second before you hit reply and tell me how stupid
I am being.

This one line illustrates the entire concept in a nutshell:

> Security perimeters can of
>       course restrict the end-to-end communications, but it is
>       easier to block certain nodes from communicating than it is to re-
>       enable nodes to communicate if they have been hidden behind
>       address translation devices.

Is this really true? When I want to secure a physical space, I block off
all access, then put in carefully thought out access control points. I
don't pile all my goods in the middle of the street, and then actively
monitor every person who walks by, hiring more people to do the
monitoring as needed.

And I would point out that the problem is even worse in the network
world --it's a large risk to come into my house and try to rob me,
because of the physical danger involved. There is physical risk for the
person breaking and entering, in other words. Breaking into me network
has no risk whatsoever, and the gain could be huge --larger than
stealing what I have in my living room. Instead of stealing my
television, could steal my identity --and all at no physical risk, with
trivial effort (you don't have to actually go to my house, etc.). So my
posture on the network side is actually "stronger," and "more
suspicious," than it is on the physical side.

I think we should be a little more realistic about network security.
We'd all like to live in a world where there are no identity thieves,
and there are no viruses, and there is no-one trying to harm you, or
invade your privacy. But that's just not real.

And I know I'm about to get all sorts of stories about how someone has
had their computer connected to the internet for x number of years, no
nat, no firewall, and they've never caught anything, nor had anyone
steal anything. Maybe you just need to lead a more interesting life if
that's the case. And I'm happy for you, but when I actually administered
a large network, I had virus incidents constantly --and I know I face it
all the time in customer networks.

So, IMHO:

1. Stop the screed against NAT.

2. Set out positive requirements, rather than negative ones.

3. Be realistic about security --the default should be _nothing_ reaches
into my home, and I should have an easily managable way to allow what I
want to allow. The default should not be an open door to anyone from
anyplace at any time, and then "we'll put in advanced monitoring to
block activity."

Just my 2c.

:-)

Russ

---

From: John Mann <[email-masked]>
Date: Wed, 12 Oct 2011 11:33:04 +1100

Hi,

> >       address translation devices.

I think you are quoting from the "Transparent End-to-End Communications"
section on pages 14/15
which is to do with communications _within_ the home network.

> ...

Generally speaking, I want open access within my home network,
but may add specific rules to stop e.g. guest wi-fi getting to certain
servers.

I don't want layers of NAT within my home network, which is what you can get
if you plug the WAN port of a IPv4 network device into the LAN port of
another device.

> anyplace at any time, and then "we'll put in advanced monitoring to

See " Security, Borders, and the elimination of NAT" section on page 5.
---
      [RFC6092] provides recommendations for an IPv6 firewall that
      applies "limitations on end-to-end transparency where security
      considerations are deemed important to promote local and Internet
      security."  The firewall operation is "simple" in that there is an
      assumption that traffic which is to be blocked by default is
      defined in the RFC and not expected to be updated by the user or
      otherwise.  The RFC also discusses an option for CPEs to have an
      option to be put into a "transparent mode" of operation.

      It is important to distinguish between addressability and
      reachability; i.e.  IPv6 through use of globally unique addressing
      in the home makes all devices potentially reachable from anywhere.
      Whether they are or not should depend on firewall or filtering
      behaviour, and not the presence or use of NAT. ...
---

Does this address you concerns?

    John

---

From: Russ White <[email-masked]>
Date: Wed, 12 Oct 2011 07:58:20 -0400

> section on pages 14/15 which is to do with communications _within_ the home network.

Yes... I understand the rational behind not wanting a NAT within the
home, but the text reads in a much larger way. And the anti-NAT bits
aren't just limited to that one section, but rather scattered throughout.

So I would say --

1. Take out the bits about "we don't want NAT."
2. Replace them with a single section detailing exactly what you want in
terms of "transparent end-to-end communications" specifically within the
home.

> but may add specific rules to stop e.g. guest wi-fi getting to certain

You want guests to be able to get to all servers by default, unless you
specifically go into a configuration on some device?

What's really needed is the ability to divide things into "domains,"
probably requiring some form of local directory server, and then
controlling who is in what domain. Anything within a domain can access
anything else within the same domain by default, and cannot access
anything in the other domain by default, including network connections.

> Does this address you concerns?

No, not really, because it assumes just what I don't want to assume
--that end-to-end reachability is the default, and I must take specific
actions in order to block specific pieces of reachability.

If you want, I'll try and suggest wording later today or tomorrow.

:-)

Russ

---

From: james woodyatt <[email-masked]>
Date: Wed, 12 Oct 2011 12:26:56 -0700

> actions in order to block specific pieces of reachability.

Those of us who still bear the scars of the debate over RFC 6092 well remember that the Simple Security document takes great pains to make no such assumption.

>> 1.2.  Use of Normative Keywords
>> 
>>       NOTE WELL: This document is not a standard, and conformance with
>>       it is not required in order to claim conformance with IETF
>>       standards for IPv6.  It uses the normative keywords defined in the
>>       previous section only for precision.
>> 
>>    Particular attention is drawn to recommendation REC-49, which calls
>>    for an easy way to set a gateway to a transparent mode of operation.
>> 
>> [...]
>> 3.4.  Passive Listeners
>> 
>> REC-49: Internet gateways with IPv6 simple security capabilities MUST
>>    provide an easily selected configuration option that permits a
>>    "transparent mode" of operation that forwards all unsolicited flows
>>    regardless of forwarding direction, i.e., not to use the IPv6 simple
>>    security capabilities of the gateway.  The transparent mode of
>>    operation MAY be the default configuration.
>> 
>>    In general, "transparent mode" will enable more flexibility and
>>    reliability for applications that require devices to be contacted
>>    inside the home directly, particularly in the absence of a protocol
>>    as described in REC-48.  Operating in transparent mode may come at
>>    the expense of security if there are IPv6 nodes in the home that do
>>    not have their own host-based firewall capability and require a
>>    firewall in the gateway in order not to be compromised.

The "MAY" in that recommendation was the subject of about two years of teeth gnashing and garment rending, which I hope this working group shall not repeat.

--
james woodyatt <[email-masked]>
member of technical staff, core os networking