Subject: Re: [homenet] Homenet Architecture & Interim Meeting

From: Erik Nordmark <[email-masked]>
Date: Mon, 03 Oct 2011 18:46:51 -0700

On 9/21/11 1:19 PM, Ray Hunter wrote:
> 1) I contend that multi-homing is probably going to become the "norm" in
> Europe by 2022, due to The European Electricity and Gas Directive. That
> corresponds at least to picture 4, if not more.

If we believe that multi-homing will be more common, then I think we 
need to understand what the constraints are for the multihoming in 
particular as this relates to walled gardens. I can see many different 
possibilities, which imply different requirements.

1. Just two paths to the Internet; the home gets one PA prefix from each 
ISP.

2. Like #1 but in addition the ISPs run ingress filtering so that the 
source address in a packet from the home has to match the prefix that 
ISP delegated.

3.  Like #1, but there are QoS guarantees for traffic local to an ISP. 
Thus a host in the home can connect to foo.ispA.net over either ISP-A or 
ISP-B, but gets better voice/video quality when doing it over ISP-A's 
connection.

4. Looking up foo.ispA.net works when asking the DNS server at ISP-A, 
but fails (NXDOMAIN) when asking ISP-B.

5. The lookup of foo.ispA.net works over either DNS and returns the same 
IP address, but fails (due to firewalls) for packets that are sent out 
via ISP-B.

6. The lookup of foo.ispA.net works over either DNS and returns the same 
IP address, but the application-layer content is completely different 
(e.g., a "subscriber" view when connecting over the ISP-A connection).

7. The lookup of foo.ispA.net returns different IP addresses when asking 
ISP-A vs. ISP-B.

Do we really want to solve all those problems in homenet? We can't tell 
the difference between behavior #1 and #6 at the IP layer.

    Erik

---

From: Thomas Herbst <[email-masked]>
Date: Mon, 3 Oct 2011 21:00:55 -0700

There will be wide area network providers who interwork with the home network but do not provide global connectivity.  
Two mentioned so far are utility networks and 3g providers.  One of the outputs of the wg should be to define how they should be configured to perform their role without messing up Internet communication.

A wg Chair from the Internet area did accuse me of "breaking the Internet model" because the utility networks my company builds do not provide global connectivity to users with our 100kb to the node.

tom

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Erik Nordmark [[email-masked]]
Sent: Monday, October 03, 2011 6:46 PM
To: Ray Hunter
Cc: Tim Chown; [email-masked]
Subject: Re: [homenet] Homenet Architecture & Interim Meeting

    Erik
_______________________________________________
homenet mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/homenet

---

From: Joel jaeggli <[email-masked]>
Date: Mon, 03 Oct 2011 22:16:26 -0700

On 10/3/11 21:00 , Thomas Herbst wrote:
> There will be wide area network providers who interwork with the home
> network but do not provide global connectivity. Two mentioned so far
> are utility networks and 3g providers.  One of the outputs of the wg
> should be to define how they should be configured to perform their
> role without messing up Internet communication.
> 
> A wg Chair from the Internet area did accuse me of "breaking the
> Internet model" because the utility networks my company builds do not
> provide global connectivity to users with our 100kb to the node.

not all (inter)networks  provide internet connectivity. something  more
pretty than the 250+ routes my split-tunnel ssl vpn client just
installed when it came up would be appreciated. defusing knowledge about
avail destinations is why we want routing in the first place.

> tom
> 
> ________________________________________ From:
> [email-masked] [[email-masked]] On Behalf Of Erik
> Nordmark [[email-masked]] Sent: Monday, October 03, 2011 6:46 PM 
> To: Ray Hunter Cc: Tim Chown; [email-masked] Subject: Re: [homenet]
> Homenet Architecture & Interim Meeting
> 
>> 1) I contend that multi-homing is probably going to become the
>> "norm" in Europe by 2022, due to The European Electricity and Gas
>> Directive. That corresponds at least to picture 4, if not more.
> 
> particular as this relates to walled gardens. I can see many
> different possibilities, which imply different requirements.
> 
> 1. Just two paths to the Internet; the home gets one PA prefix from
> each ISP.
> 
> 2. Like #1 but in addition the ISPs run ingress filtering so that
> the source address in a packet from the home has to match the prefix
> that ISP delegated.
> 
> 3.  Like #1, but there are QoS guarantees for traffic local to an
> ISP. Thus a host in the home can connect to foo.ispA.net over either
> ISP-A or ISP-B, but gets better voice/video quality when doing it
> over ISP-A's connection.
> 
> 4. Looking up foo.ispA.net works when asking the DNS server at
> ISP-A, but fails (NXDOMAIN) when asking ISP-B.
> 
> 5. The lookup of foo.ispA.net works over either DNS and returns the
> same IP address, but fails (due to firewalls) for packets that are
> sent out via ISP-B.
> 
> 6. The lookup of foo.ispA.net works over either DNS and returns the
> same IP address, but the application-layer content is completely
> different (e.g., a "subscriber" view when connecting over the ISP-A
> connection).
> 
> 7. The lookup of foo.ispA.net returns different IP addresses when
> asking ISP-A vs. ISP-B.
> 
> 
> Do we really want to solve all those problems in homenet? We can't
> tell the difference between behavior #1 and #6 at the IP layer.
> 
> Erik _______________________________________________ homenet mailing
> list [email-masked] https://www.ietf.org/mailman/listinfo/homenet 
> _______________________________________________ homenet mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/homenet
>

---

From: james woodyatt <[email-masked]>
Date: Tue, 04 Oct 2011 16:17:31 -0700

> Two mentioned so far are utility networks and 3g providers.  One of the outputs of the wg should be to define how they should be configured to perform their role without messing up Internet communi…

Those utility networks have a fundamental problem that I contend is beyond the scope and charter of HOMENET.

Utility networks of that sort do not provide transit to the Internet default-free zone.  They must therefore obtain their routes to residential networks bilaterally.  This implies that these utility networks could be-- and would do well to be-- numbered with ULA prefixes, and that they should use of an exterior gateway protocol at their border with residential networks so that each home network can advertise, into the utility network, its list of globally assigned prefixes that it obtains from Real Internet Service Providers.

Yes, the scale of the routing problem faced by these utility networks is hard.  No, I don't think they're going to be able to solve it adequately.  This is-- however-- not our problem.  It's theirs.  They would not have this problem if they engineered their networks differently, i.e. to rely on real Internet service providers to provide transit through the default-free zone between their equipment in residential deployments and their equipment in their data centers.  This is what EVERYONE ELSE in the world does, and it works pretty well.

> A wg Chair from the Internet area did accuse me of "breaking the Internet model" because the utility networks my company builds do not provide global connectivity to users with our 100kb to the nod…

That's really not the problem, if you want my humble opinion.  The problem, I would say, is that these utility networks insist on extending their private routing domains into our home networks where they don't belong and they aren't welcome.

On Oct 3, 2011, at 6:46 PM, Erik Nordmark wrote:
> [...]
> 6. The lookup of foo.ispA.net works over either DNS and returns the same IP address, but the application-layer content is completely different (e.g., a "subscriber" view when connecting over the ISP-A connection).

This is the basic problem faced by any multi-homed host, e.g. a personal computer with a 3G interface and a Wi-fi interface that are simultaneously active, along with a split-tunnel VPN interface [or three] running on one or both interfaces.

It is a problem for host operating systems and applications developers.  I suggest HOMENET should steer well clear of it, and just about every related problem that is too easily conflated with it.

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

---

From: Mark Townsley <[email-masked]>
Date: Tue, 4 Oct 2011 21:24:33 +0200

Homenet is concerned with how to make the network in the home work, so what would happen today if I took two routers, connected them to two IPv6-enabled ISPs, and then connected them to the same LAN in the home? Most residential ISPs support source-address filtering today (at least in IPv4, and in every IPv6 design I have ever seen), so your #2 seems to be the most likely starting point. 

Now the question becomes whether the routers take over and try to keep a single prefix within the home and be smart about what traffic goes where, or allow the two prefixes to be advertised and punt the multihoming problem to the hosts. If we let the hosts handle it, I have to say it is tempting to continuing punting the problem up the stack and make this a transport issue rather than an IP issue....

- Mark

On Oct 4, 2011, at 3:46 AM, Erik Nordmark wrote:

> If we believe that multi-homing will be more common, then I think we need to understand what the constraints are for the multihoming in particular as this relates to walled gardens. I can see many different possibilities, which imply different requirements.
> 
> 1. Just two paths to the Internet; the home gets one PA prefix from each ISP.
> 
> 2. Like #1 but in addition the ISPs run ingress filtering so that the source address in a packet from the home has to match the prefix that ISP delegated.
> 
> 3.  Like #1, but there are QoS guarantees for traffic local to an ISP. Thus a host in the home can connect to foo.ispA.net over either ISP-A or ISP-B, but gets better voice/video quality when doing it over ISP-A's connection.
> 
> 4. Looking up foo.ispA.net works when asking the DNS server at ISP-A, but fails (NXDOMAIN) when asking ISP-B.
> 
> 5. The lookup of foo.ispA.net works over either DNS and returns the same IP address, but fails (due to firewalls) for packets that are sent out via ISP-B.
> 
> 7. The lookup of foo.ispA.net returns different IP addresses when asking ISP-A vs. ISP-B.
> 
> 
> Do we really want to solve all those problems in homenet? We can't tell the difference between behavior #1 and #6 at the IP layer.
> 
>   Erik

---

From: Mark Andrews <[email-masked]>
Date: Wed, 05 Oct 2011 13:30:18 +1100

In message <[email-masked]>, Mark Townsley w
rites:
> 
> Homenet is concerned with how to make the network in the home work, so what w
> ould happen today if I took two routers, connected them to two IPv6-enabled I
> SPs, and then connected them to the same LAN in the home? Most residential IS
> Ps support source-address filtering today (at least in IPv4, and in every IPv
> 6 design I have ever seen), so your #2 seems to be the most likely starting p
> oint. 
> 
> Now the question becomes whether the routers take over and try to keep a sing
> le prefix within the home and be smart about what traffic goes where, or allo
> w the two prefixes to be advertised and punt the multihoming problem to the h
> osts. If we let the hosts handle it, I have to say it is tempting to continui
> ng punting the problem up the stack and make this a transport issue rather th
> an an IP issue....
> 
> - Mark

Multiple prefixes with the hosts maintaining a default route(s) per prefix.
 
> > If we believe that multi-homing will be more common, then I think we need t
> o understand what the constraints are for the multihoming in particular as th
> is relates to walled gardens. I can see many different possibilities, which i
> mply different requirements.
> > 
> > 2. Like #1 but in addition the ISPs run ingress filtering so that the sourc
> e address in a packet from the home has to match the prefix that ISP delegate
> d.
> > 
> > 3.  Like #1, but there are QoS guarantees for traffic local to an ISP. Thus
>  a host in the home can connect to foo.ispA.net over either ISP-A or ISP-B, b
> ut gets better voice/video quality when doing it over ISP-A's connection.
> > 
> > 5. The lookup of foo.ispA.net works over either DNS and returns the same IP
>  address, but fails (due to firewalls) for packets that are sent out via ISP-
> B.
> > 
> > 6. The lookup of foo.ispA.net works over either DNS and returns the same IP
>  address, but the application-layer content is completely different (e.g., a 
> "subscriber" view when connecting over the ISP-A connection).
> > 
> > Do we really want to solve all those problems in homenet? We can't tell the
>  difference between behavior #1 and #6 at the IP layer.
> > 
> >   Erik
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 04 Oct 2011 19:49:07 -0700

> Homenet is concerned with how to make the network in the home work, so what would happen today if I took two routers, connected them to two IPv6-enabled ISPs, and then connected them to the same LA…

If a home network is multi-homed, then I suspect we'd need to solve at 
least #2.

But what if it turns out that we do that and the real problem that needs 
to be solved is walled gardens that behave as #6? Then our solution to 
#2 doesn't do any good.

Hence I think we need to write down the requirements around home 
multihoming and if we are going to dismiss 4-7 below we'd better have a 
good argument why those are a bad idea.

> Now the question becomes whether the routers take over and try to keep a single prefix within the home and be smart about what traffic goes where, or allow the two prefixes to be advertised and pun…

For #2 I can see us exploring network-layer solutions like RFC6296.
But for #3-7 that might not help.

I think we had a discussion about application awareness of addresses and 
topology a while back (the IPv6 site-local debate) which seemed to 
indicate that applications don't want to deal with this. I could be that 
#4-7 are a bad idea and inconsistent with the architectural assumptions 
we make, but the IETF hasn't tried to make that statement AFAIK.

    Erik

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 04 Oct 2011 23:05:10 -0400

Problem #2 (connectivity to two ISPs with different PA assignments and 
source address filtering) does seem forth addressing... if we can.
Standardizing and mandating NPT66 (RFC 6296, not standards track) would 
seem highly undesirable.
However, so are all the other answers I know of, such as source address 
sensitive routing.

As for the later cases, while folks will build that, I think that 
solutions for those are probably better defined in places that can at 
least discuss business tradeoffs.

Yours,
Joel M. Halpern

On 10/4/2011 10:49 PM, Erik Nordmark wrote:
>> Homenet is concerned with how to make the network in the home work, so
>> what would happen today if I took two routers, connected them to two
>> IPv6-enabled ISPs, and then connected them to the same LAN in the
>> home? Most residential ISPs support source-address filtering today (at
>> least in IPv4, and in every IPv6 design I have ever seen), so your #2
>> seems to be the most likely starting point.
>
>> Now the question becomes whether the routers take over and try to keep
>> a single prefix within the home and be smart about what traffic goes
>> where, or allow the two prefixes to be advertised and punt the
>> multihoming problem to the hosts. If we let the hosts handle it, I
>> have to say it is tempting to continuing punting the problem up the
>> stack and make this a transport issue rather than an IP issue....
>
>>>> "norm" in
>>> Thus a host in the home can connect to foo.ispA.net over either ISP-A
>>> or ISP-B, but gets better voice/video quality when doing it over
>>> ISP-A's connection.
>>>

---

From: "Weil, Jason" <[email-masked]>
Date: Wed, 5 Oct 2011 10:37:04 -0400

On 10/4/11 7:17 PM, "james woodyatt" <[email-masked]> wrote:

>>network but do not provide global connectivity.
>> Two mentioned so far are utility networks and 3g providers.  One of the
>>outputs of the wg should be to define how they should be configured to
>>perform their role without messing up Internet communication.
>
>Utility networks of that sort do not provide transit to the Internet
>default-free zone.  They must therefore obtain their routes to
>residential networks bilaterally.  This implies that these utility
>networks could be-- and would do well to be-- numbered with ULA prefixes,
>and that they should use of an exterior gateway protocol at their border
>with residential networks so that each home network can advertise, into
>the utility network, its list of globally assigned prefixes that it
>obtains from Real Internet Service Providers.

[JW] Why would the utility network require the global address space
provided by the user's ISP? From a security POV, I surely wouldn't want a
gateway to my network to which I have absolutely no control over (power
meter for instance) have unfettered access to my home network. It was my
understanding that the meter would be the demarc between the home network
and the utility network, collecting data from electrical sensors with a
Zigbee interface. If it has a network connection to the home gateway I
would think it would use the home gateway's provided address space.

>
>Yes, the scale of the routing problem faced by these utility networks is
>hard.  No, I don't think they're going to be able to solve it adequately.
> This is-- however-- not our problem.  It's theirs.  They would not have
>this problem if they engineered their networks differently, i.e. to rely
>on real Internet service providers to provide transit through the
>default-free zone between their equipment in residential deployments and
>their equipment in their data centers.  This is what EVERYONE ELSE in the
>world does, and it works pretty well.

[JW] For any value add applications offered by application service
providers, I would think routing through the default-free zone offered but
your ISP/s would be the preferred option here.

>That's really not the problem, if you want my humble opinion.  The
>problem, I would say, is that these utility networks insist on extending
>their private routing domains into our home networks where they don't
>belong and they aren't welcome.
>
>This is the basic problem faced by any multi-homed host, e.g. a personal
>computer with a 3G interface and a Wi-fi interface that are
>simultaneously active, along with a split-tunnel VPN interface [or three]
>running on one or both interfaces.
>
>It is a problem for host operating systems and applications developers.
>I suggest HOMENET should steer well clear of it, and just about every
>related problem that is too easily conflated with it.
>
>
>--

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: james woodyatt <[email-masked]>
Date: Wed, 05 Oct 2011 12:25:13 -0700

On Oct 5, 2011, at 7:37 AM, Weil, Jason wrote:
> [JW] Why would the utility network require the global address space provided by the user's ISP?

I can imagine that it might require this on the grounds that provider aggregation will make it easier for the utility network to aggregate routes to its subscriber's residential networks.  Otherwise, every subscriber ends up advertising their own ULA prefix into the routing domain of the utility network, and the result is a routing table explosion.

> From a security POV, I surely wouldn't want a
> meter for instance) have unfettered access to my home network.

That's an orthogonal issue.  From a security POV, you should have control over all the nodes in the network demarcated by the boundaries of the routing domain in your home.  If you don't have control over the power meter, then it shouldn't be in your routing domain.  You should have your own router, which you control and which enforces your policies, as the gateway to the utility network.

> It was my

I'd like to know how these utility operators would like to define the boundaries of their networks and how they should be demarcated from private residential networks with which they intend to interwork.  Is there a document, preferably an Internet draft, which I should read to understand that?

---

From: Joel jaeggli <[email-masked]>
Date: Thu, 06 Oct 2011 23:57:44 -0700

On 10/4/11 16:17 , james woodyatt wrote:
>> There will be wide area network providers who interwork with the
>> home network but do not provide global connectivity. Two mentioned
>> so far are utility networks and 3g providers.  One of the outputs
>> of the wg should be to define how they should be configured to

every-time I connect my split-tunneled vpn to my home network, I am
attaching a non-dfz-connected inter-network behind my home network, I
don't think of this as rare or particularly exceptional problem (it's
not confined to utility networks). it does have the potential for
address collisions (as built currently)in ipv4 due to the extensive if
not quite complete use of rfc-1918 used within the scope of that private
internetwork.

> networks could be-- and would do well to be-- numbered with ULA
> prefixes, and that they should use of an exterior gateway protocol at
> their border with residential networks so that each home network can
> advertise, into the utility network, its list of globally assigned
> prefixes that it obtains from Real Internet Service Providers.
> 
> Yes, the scale of the routing problem faced by these utility networks
> is hard.  No, I don't think they're going to be able to solve it
> adequately.  This is-- however-- not our problem.  It's theirs.  They
> would not have this problem if they engineered their networks
> differently, i.e. to rely on real Internet service providers to
> provide transit through the default-free zone between their equipment
> in residential deployments and their equipment in their data centers.
> This is what EVERYONE ELSE in the world does, and it works pretty
> well.
> 
>> Internet model" because the utility networks my company builds do
>> not provide global connectivity to users with our 100kb to the
>> node.
> 
> problem, I would say, is that these utility networks insist on
> extending their private routing domains into our home networks where
> they don't belong and they aren't welcome.
> 
>> [...] 6. The lookup of foo.ispA.net works over either DNS and
>> returns the same IP address, but the application-layer content is
>> completely different (e.g., a "subscriber" view when connecting
>> over the ISP-A connection).
> 
> This is the basic problem faced by any multi-homed host, e.g. a
> personal computer with a 3G interface and a Wi-fi interface that are
> simultaneously active, along with a split-tunnel VPN interface [or
> three] running on one or both interfaces.
> 
> It is a problem for host operating systems and applications
> developers.  I suggest HOMENET should steer well clear of it, and
> just about every related problem that is too easily conflated with
> it.
> 
> 
> -- james woodyatt <[email-masked]> member of technical staff, core os
> networking
> 
> 
>

---

From: james woodyatt <[email-masked]>
Date: Fri, 07 Oct 2011 06:17:28 -0700

On Oct 6, 2011, at 23:57 , Joel jaeggli wrote:
> attaching a non-dfz-connected inter-network behind my home network

Yes, but these utility networks are faced basically with the problem of establish a private network connection through an access concentrator in each and every subscriber home network simultaneously.  In IPv4, this doesn't merely have the *potential* for address realm conflict... it's absolutely unavoidable, and it kills the deal before you can even begin to work on the routing problem.   In IPv6, there isn't a huge problem with address realm conflict, but the routing problem looms pretty big.

---

From: Joel jaeggli <[email-masked]>
Date: Fri, 07 Oct 2011 10:39:06 -0700

On 10/7/11 06:17 , james woodyatt wrote:
>> every-time I connect my split-tunneled vpn to my home network, I
>> am attaching a non-dfz-connected inter-network behind my home
>> network
> 
> Yes, but these utility networks are faced basically with the problem
> of establish a private network connection through an access
> concentrator in each and every subscriber home network
> simultaneously.  In IPv4, this doesn't merely have the *potential*
> for address realm conflict... it's absolutely unavoidable, and it
> kills the deal before you can even begin to work on the routing
> problem.   In IPv6, there isn't a huge problem with address realm
> conflict, but the routing problem looms pretty big.

If you can cover the end-users total intersection between the utility
network and their own with one or two prefixes instead of (for example
the 250 public/private prefixes in my split tunnels table) it seems like
a tractable problem. it's better if they're GUA,cause then you have some
strong assurance that they don't intersect.

I guess what I'd say is that while interconnection with private
inter-nets may well be classified as either a threat or a menace at your
convenience, it's not a new problem as surfaced by homenet and it's
probably not going away.

---

From: Curtis Villamizar <[email-masked]>
Date: Fri, 07 Oct 2011 12:55:01 -0700

> not quite complete use of rfc-1918 used within the scope of that private

Joel,

Being new to this WG I may have it wrong, but a point of this WG may
be to change the use of RFC1918 space to IPv6 space.  For example, not
only your computers, but your home thermostats, your electic meter,
your entertainment systems, SIP phones, etc can each have global IPv6
addresses.  Beats "go check the thermostat at 10.0.0.1" from your
mobile phone.  Authentication will be an issue for product (but
from the charter, not in scope for the WG).

With an IPv6 only home network you don't need to use rfc1918 number
space.  You can put your /64 behind a firewall if you like.  You can
use RFC3142 as one means to reach the IPv4 world at least for anything
based on TCP (SMTP, HTTP, etc).  Or you can use application gateways
(what I use).  The benefit over using net 10/8 or other rfc1918 space
is that if your hosts at different sites use IPv6 and if your laptop
in a IPv4 only site can at least get a 6to4 tunnel, you can use a
globally routable IPv6 number space.

Try using IPv6 instead of rfc1918.  (for example, see mail headers).

If the provider side of the WAN connection just hands the home router
an IPv6 prefix, then some form of autoconfiguration is possible.  If
not, IPv4 rfc1918 autoconfiguration can be used with NAT unless a
tunnel is configured.  It wouldn't hurt to do both IPv4 rfc1918
autoconfiguration with NAT and IPv6 autoconfiguration with a native
prefix or with a configured tunnel (or with 6to4 enabled).

Curtis

---

From: Joel jaeggli <[email-masked]>
Date: Fri, 07 Oct 2011 14:09:06 -0700

On 10/7/11 12:55 , Curtis Villamizar wrote:
> be to change the use of RFC1918 space to IPv6 space.

I've got a little experience numbering networks...

My observation which apparently you missed was in response to James
Woodyatt's point about whether the interconnection of private
inter-networks (e.g. those without internet routes for example a utility
such as an elecritc provider) was is scope for homenet.

>  For example, not

---

From: Michael Richardson <[email-masked]>
Date: Fri, 07 Oct 2011 18:38:11 -0400

>>>>> "Jari" == Jari Arkko <[email-masked]> writes:
    Jari> Though its not clear to me exactly how that affects the
    Jari> architecture. Wireless extenders are part of L2 that is not
    Jari> usually visible, though the other things are perhaps more
    Jari> visible to l3. Maybe the effects are what we should be talking
    Jari> about in terms of the requirements.

I wanted to point out that one of the complexities in debugging L2
networks that contain things like wireless extenders is exactly that:
they are not visible, they don't show up traceroute, you can't address
them easily to ask them questions, and the like. 
I think that these things will go away over time once we are successful.

(BTW: I think that proxy-arp might me the solution to bridged IPv4 vs
routed IPv6. Proxy-arp has the "feature" that it usually breaks
multicast, but that might be a feature for a wireless extender...)

    > So there may also be a requirement for interconnection of
    > multiple ultra-short range networks via a house backbone:
    > e.g. lights on top floor pool to form a mesh network, and lights
    > in the basement form a mesh network, but the reinforced concrete
    > floor partitions the two wireless meshes, so you need a routed
    > connection between them.

    Jari> I think we do include that already. Its part of being able to
    Jari> provide a routed, multi-subnet network. Precisely for these
    Jari> reasons. (But if you are arguing that we should all use some

I need to CC the roll list on this part, see next email.

    >> 3) Virtual machines are exploding. I run 4 VM's on my
    >> workstation. With the various upcoming application stores and
    >> multiple application developers running on one system, I could
    >> easily imagine that each application eventually runs in its own
    >> mini-VM, so each IPv6 host becomes the equivalent of an old style
    >> mainframe with multiple prefixes and intra-machine routing. That
    >> may add another layer of routing to your picture. There may also
    >> be virtual firewalls between those VM's, which adds another
    >> layer.

    Jari> Yep. I have that in my network, too :-) But the question is,
    Jari> what does it imply in terms of requirements? It at least
    Jari> implies that we need to support many devices, and probably
    Jari> even more reason to allow for additional subnets (e.g., to
    Jari> allow one set of virtual machines exist in their own subnet
    Jari> inside a physical device).

I want amplify something I said today about subnet allocations vs
virtual machines.   Products like XEN, VMware and VirtualBox have
some kernel components which needs to be installed by an administrator.
This means that he VM host (the "dom0") can have a (virtual) switch for
the guest machines which can be either *bridged* or *routed*.  
(I can't speak to Parallels, but I know it can bridge or NAT)

There are advantages to routing, particularly on a laptop that sometimes
does not actually have any network connection, and also you have the
opportunity to enable the Advanced Security feature in the virtual
router.

The problem is with things that use QEMU/Bochs based emulation.
This includes the Android emulator that comes with the Android SDK. 
(Note that this emulates an ARM system on an x86 platform).
This presently can also include the KVM system in some situations.
(KVM is basically native (x86 on x86) emulation with acceleration by
using VT extensions.)

The issue is that the default configuration is to include a reverse
stack in QEMU.  It's rather ingenius actually.  It basically turns a TCP
SYN packet into a call to the OS connect(2) call.  The result is NAPT,
and default "Simple Security" sans PCP.   It's possible to configure
QEMU to instead bridge to a virtual interface, but it's not default,
because that setup requires superuser to configure, and it doesn't
work at all (AFAIK) on windows or OSX. 

Is this really an issue for the IETF?  Not really, things can be made to
work, but my concern is that a typically KVM/QEMU user could, if the
router code is built-in to the QEMU, rather than into the operating
system, wind up allocating a prefix each time they boot up a single VM,
and while they might not run a lot of VMs at the same time, they might
well run many different VMs sequentially.   

How and who do we inform when we have run out of prefixes?

-- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition.

---

From: Michael Richardson <[email-masked]>
Date: Fri, 07 Oct 2011 18:38:19 -0400

This is a conversation that started on the Homenet list.

If you plug two RPL root bridges into two ports of an ethernet switch,
they will happily link your lighting network together.

That's something that I think that might not have been clearly stated in
the discussion at today's interim meeting:  RPL might not be hidden
behind the ethernet/802.15.4 router, it might use the ethernet to
connect different zones.   So, don't be surprised if you see RPL ICMPv6
messages crossing some of the inside lans.

Continuing along the thought process that stuff should just work,
regardless of how grandma plugs things in... it would therefore be nice
if RPL could bridge across a routed homenet lan.

This would work, I think, if the RPL ICMPv6 DIOs, which are currently
multicast to a link-local group by default, could instead on a RPL node
with an uplink, send to a site-local ULA multicast group.  

This is also not strictly necessary: the upstairs and downstairs RPL
meshes, if they allocate ULA prefixes as we have discussed, simply route
across the homenet LAN, and probably things will work.

Where this might fail is if the P2P mechanism in RPL was being used,
because it basically forms a temporary DAG across the mesh find the most
direct route.  If the best route is via the homenet, it won't be found
if the two meshes are partitioned.

---

From: Curtis Villamizar <[email-masked]>
Date: Sun, 09 Oct 2011 11:44:04 -0700

> I've got a little experience numbering networks...

Yes I know.

> such as an elecritc provider) was is scope for homenet.

So why would the elecritc provider not support IPv6 if they wanted to
use the same internet infrastructure provided by the homenet?

The model today is the the meter contacts the elecritc provider (this
works with NAT).  With IPv6, the electric provider could poll the
meters, as long as they know the meter's IPv6 address.  If anything,
the meter could push a new IPv6 address on installation and each time
it saw a new address assigned to it (as is done in mobility
applications, but this should not be often for a stationary meter).
Of course some reasonable authentication is needed.

The point is that once IPv6 is supported, everything has a global
address, things like this are easier (either end can initiate
interaction).  The example of electric meters is a trivial one but the
same can apply to other things.  The example of checking a thermostat
or other thing in the home from a mobile phone is a better example of
a need to initiate interaction from outside the homenet, where global
address space is helpful.

Others uses where having a global IPv6 address are nice are the home
KDC, plus CVS, SVN, or GIT server, etc.  These may not be common in
the average home.  :-)

So the answer may be it is out of scope if the utility has some hack
over some private infrastructre like IP over the power lines that is
not connected to the homenet, in scope if they are using global
addressing and taking advantage of the homenet.  Maybe water meter or
gas meter would be better examples since I don't know of IP over water
pipes.  In a lot of places these meters use a twisted pait that goes
who knows where and might be better served with a WiFi chip or low
power WPAN or plain ol' Ethernet and using the homenet.

It may be possible to work something out with the local provider (MSO
or ILEC) if the homeowner takes down their Internet access or doesn't
want Internet.  For example, leave the wires and local provider low
end router in place, but with filters (where they can't be tampered
with) only allowing access to the meters.

IMHO: these sort of arrangements are well out of scope.  The homenet
is just a connection to the global Internet.  

IMO: The homenet equipment needs to be prepared for an IPv4 only
provider. a native IPv6 only provider, or a dual stack provider.  For
IPv4, expect to most often get one address from the provider for local
use (via DHCP) and enable NAT by default, or have multiple addresses
configured (and optionally also have NAT configured).  With IPv6,
expect to get more than will ever be needed (a /64).  Note that you
*can* subdivide a /64 in a homenet as long as any advertisement to the
provider (globally routable prefix) is /64 or shorter.  [I'm using
/112 and /96 (each on 2 byte boundaries) within a /64 and it works
fine].  If there is no native IPv6, the homenet equipment must support
a configured 6to4 tunnel or other configured tunnel.

Whether to automatically bring up a 6to4 tunnel in the absense of
native IPv6 and the absense of configuration, is an issue worth
discussing.  I think no, since it may overload 6to4 servers, but I'm
willing to be persuaded.

Curtis

---

From: Michael Richardson <[email-masked]>
Date: Mon, 10 Oct 2011 11:51:10 -0400

>>>>> "james" == james woodyatt <[email-masked]> writes:
    >> home network but do not provide global connectivity.  Two
    >> mentioned so far are utility networks and 3g providers.  One of
    >> the outputs of the wg should be to define how they should be
    >> configured to perform their role without messing up Internet
    >> communication.

    james> Those utility networks have a fundamental problem that I
    james> contend is beyond the scope and charter of HOMENET.

    james> Utility networks of that sort do not provide transit to the
    james> Internet default-free zone.  They must therefore obtain their
    james> routes to residential networks bilaterally.  This implies
    james> that these utility networks could be-- and would do well to
    james> be-- numbered with ULA prefixes, and that they should use of

If you said, "ULA-Central" I would agree.
I do not want to debug random packets on someone's network without
whois.

    >> not provide global connectivity to users with our 100kb to the

    james> That's really not the problem, if you want my humble opinion.
    james> The problem, I would say, is that these utility networks
    james> insist on extending their private routing domains into our
    james> home networks where they don't belong and they aren't
    james> welcome.

It does break the *I*nternet model: the one where the ISPs control
everything like the telcos did before, and I need to beg to be allowed
to receive SYN packets.  Why do I care if it breaks the business plans
of some ISPs?   

But the IETF needs to spend more time worrying about the *Internet
Protocols* rather than just the *I*nternet.   

    >> over the ISP-A connection).

    james> This is the basic problem faced by any multi-homed host,
    james> e.g. a personal computer with a 3G interface and a Wi-fi
    james> interface that are simultaneously active, along with a
    james> split-tunnel VPN interface [or three] running on one or both
    james> interfaces.

    james> It is a problem for host operating systems and applications
    james> developers.  I suggest HOMENET should steer well clear of it,
    james> and just about every related problem that is too easily
    james> conflated with it.

What is the set of problems left for homenet then?

---

From: Michael Richardson <[email-masked]>
Date: Mon, 10 Oct 2011 13:06:23 -0400

>>>>> "Erik" == Erik Nordmark <[email-masked]> writes:
    Erik> 4. Looking up foo.ispA.net works when asking the DNS server at
    Erik> ISP-A, but fails (NXDOMAIN) when asking ISP-B.

    Erik> 5. The lookup of foo.ispA.net works over either DNS and
    Erik> returns the same IP address, but fails (due to firewalls) for
    Erik> packets that are sent out via ISP-B.

    Erik> 6. The lookup of foo.ispA.net works over either DNS and
    Erik> returns the same IP address, but the application-layer content
    Erik> is completely different (e.g., a "subscriber" view when
    Erik> connecting over the ISP-A connection).

We have heard requests for a facility to provide hosts information of
the sort:
    when looking for an FQDN that has suffix "X", please contact server "Y"

And my question is: isn't that what an NS record is?

It seems to me that we can solve all of the walled garden DNS in IPv6
land, with an arrangement like:

      example.com           NS reachable by the world.
      garden.example.com    NS pointing to AAAA record, where IPv6
                            address is only reachable from garden.
      television.garden.example.com    AAAA returned from
                            garden.example.com name server (above)

This solution works perfectly in IPv4 land, but due to lack of IPv4
global address space, the NS for garden.example.com winds up pointing to
RFC1918 address, and not only does this look bad, but it can in fact
cause failures if there really is a DNS server at that address.

It seems to me that we just don't need anything else in IPv6, except
easily *available* non-connected PI address space (whether it's ULA-C,
some recognized part of 2000::/3, or an entirely new space).

NOTE: the existing ingress filtering problem means that one must assume
      that walled gardens will have to provide address space to the home
      that will be used to talk to them.  A challenge to the walled
      garden people's thought process is that they might be thinking
      that they need 1-IP per customer, when in fact, they need to have
      at least a /60 per customer.

---

From: james woodyatt <[email-masked]>
Date: Mon, 10 Oct 2011 16:40:20 -0700

> to receive SYN packets.  Why do I care if it breaks the business plans

I hate to break the news to you, but it isn't the ISPs that are making you beg to receive a SYN packet from anywhere on the Internet.  It's the home gateway vendors, who are following the advice of RFC 4864 to implement stateful default-deny simple security mechanisms, and who follow the advice of myriad other 'experts' who insist that these functions be enabled by default.

Shorter james: it's your residential subscribers who insisting that your devices need to beg for permission to receive inbound SYN packets from arbitrary remote addresses.

The IETF is in the process of specifying a protocol to let you beg for incoming packets, c.f. I-D.ietf-pcp-base.  I wish you all the luck in the world convincing the average home networking gear buyer that they shouldn't need any of this craziness.  Sincerely.  I tried that.  Been there, done that, got the T-shirt, ended up buffing the car with it, donated the car to charity when the car wore out... in other words, I am done struggling against what you call "the Internet model" because from my perspective that's like to trying to bail out San Francisco bay with a tea cup.  Have fun storming the castle though...

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 10 Oct 2011 16:47:43 -0700

In message <[email-masked]>
 
> Protocols* rather than just the *I*nternet.   

I completely agree with the WG chair on this one.

If the utility network wants to share a common homenet infrastructure
but remain disjoint from the Internet, then it must do so in a way
that doesn't break the other uses of the homenet.

One way may be to identify (somehow) those hosts that are using the
homenet for the purpose of connecting to the utility network, such as
the home heating system, the water header, etc and only offer
addressing and routing to that subset of equipment.

Another even simpler solution is to have the utility gateway stop
serving as an ND or DHCP server completely if it detects connectivity
to the Internet and just use that connectivity.  Surely the utility
can afford an Internet connection.  Use the Internet if it is there,
otherwise use the utility network.

OTOH - If the reason for avoiding the Internet is because an industry
came up with a meter protocol with no security assuming it was only
going to be used on a walled off private network, then that is not a
homenet WG issue either.

> What is the set of problems left for homenet then?

Certainly not solving the broken utility network issues.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 10 Oct 2011 17:07:40 -0700

In message <[email-masked]>
Michael Richardson writes:
 >  
> >>>>> "Erik" =3D=3D Erik Nordmark <[email-masked]> writes:

If this is a walled garden within the home, would it be simple enough
to use a 6to4 address space for one globally unique IPv4 address and
just not bring up a 6to4 tunnel?

Instant walled garden.  With private DNS.

Alternately bring up the 6to4 tunnel but don't propogate or forward on
the garden side.  If garden.example.com is the A record for the 6to4
and also has an AAAA record, and it is also the DNS server within the
garden, then the DNS records are availabel both inside and outside but
connectivity is inside only.

Walled gardens always seem like a bad idea.  And probably always are a
bad idea.

If you have control over both the DHCP (4 or 6) server and the DNS
server, you can make DNS look like anything you want within the
garden.  [Except for those hosts who do their own DNS from root or have
configured a DNS forwarder from elsewhere.  Only the geeks.]

The original question seems to be whether the same dns query (for
example, garden.example.com) could be made to resolve differently in
ISP-A and ISP-B and the answer is "yes" with no changes but with the
exception within [] in the prior paragraph.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 10 Oct 2011 19:45:55 -0700

In message <[email-masked]>
james woodyatt writes:
 
> I hate to break the news to you, but it isn't the ISPs that are making
> you beg to receive a SYN packet from anywhere on the Internet.  It's
> the home gateway vendors, who are following the advice of RFC 4864 to
> implement stateful default-deny simple security mechanisms, and who
> follow the advice of myriad other 'experts' who insist that these
> functions be enabled by default.
>  
> Shorter james: it's your residential subscribers who insisting that
> your devices need to beg for permission to receive inbound SYN packets
> from arbitrary remote addresses.
>  
> The IETF is in the process of specifying a protocol to let you beg for
> incoming packets, c.f. I-D.ietf-pcp-base.  I wish you all the luck in
> the world convincing the average home networking gear buyer that they
> shouldn't need any of this craziness.  Sincerely.  I tried that.  Been
> there, done that, got the T-shirt, ended up buffing the car with it,
> donated the car to charity when the car wore out... in other words, I
> am done struggling against what you call "the Internet model" because
> from my perspective that's like to trying to bail out San Francisco
> bay with a tea cup.  Have fun storming the castle though...

All of this is only true for IPv4 but not for IPv6.

If you need a SYN from outside, then you need a globally routable
address and then practically speaking you need IPv6.  The most simple
solution is 6to4 but that means replacing the border router if it
doesn't support 6to4.

The other way is to accept the rfc1918 address you got from the NAT
and TCP tunnel through the NAT.  For an electrical meter with
extremely low throughput needs and very high delay tolerance, this
seems easy enough.  The meter simply need to know the IP address of
its electrical transmission provider.  If that IP addres is not
configured right at installation, the power never comes on and someone
would notice.  The electrical transmission provider can then provide
an IPv6 address and a gateway to IPv6.  The cost is a tiny flow of TCP
keepalives but if the ISP complains, tell them to support IPv6.

It is a shame that you can't get a SYN from outside into a home
network that is behind an IPV4 only NAT44, but use of NAT is not a
situation that the IETF encouraged.  We can't change that so we can
only try to move forward on a better path.

btw- ietf-pcp-base is just yet another hack built onto NAT44 to try to
extend its life.  For the last 15 years the IPv4 sky was falling.  Now
it finally really is falling as the NAT hacks are coming undone in
many ways and the ISPs can't get addresses to build infrastructure.
The good news is now we can get something done with IPv6.

Curtis

---

From: james woodyatt <[email-masked]>
Date: Mon, 10 Oct 2011 20:07:01 -0700

> All of this is only true for IPv4 but not for IPv6.

I wasn't talking about IPv4 at all.  My comments are relevant in a world entirely comprising IPv6-only service providers.  The IPv6 Internet will be saddled with all of the problems of the IPv4 Internet with respect to devices on homenets having to beg the gateways to allow inbound packets from arbitrary remote destinations.  It has nothing to do with NAT, and everything to do with firewalls and stateful filters.

---

From: Peter Koch <[email-masked]>
Date: Tue, 11 Oct 2011 08:08:17 +0200

> This solution works perfectly in IPv4 land, but due to lack of IPv4

it works, but nowhere near perfectly. Whenever a querying system
changes its intended name space (resolution context) from $local
to the global one, resolution of names in garden.example.com
will just time out. Encoding this user experience in the design looks
like a suboptimal choice to me.
For resolution from the inside, you'd likely be dependent on access
to the external delegation, which may not be feasible, either.

> some recognized part of 2000::/3, or an entirely new space).

While ULAs would "reduce" collisions, the general issues would be the same
as with RFC1918 space.

A single "local" context won't be enough.

-Peter

---

From: Michael Richardson <[email-masked]>
Date: Tue, 11 Oct 2011 07:48:25 -0400

>>>>> "Curtis" == Curtis Villamizar <[email-masked]> writes:
    Curtis> If this is a walled garden within the home, would it be simple enough
    Curtis> to use a 6to4 address space for one globally unique IPv4 address and
    Curtis> just not bring up a 6to4 tunnel?

    Curtis> Instant walled garden.  With private DNS.

I think that this might well be a great way to get walled garden address
space.  We should probably emphasize that 2002: space is part of
2000::/3, and should not be treated differently by routers.

However, I'm afraid that hosts might already have rules (due to happy
eyeballs) that make 2002: useable.  I hope i am wrong here.

    Curtis> If you have control over both the DHCP (4 or 6) server and the DNS
    Curtis> server, you can make DNS look like anything you want within the
    Curtis> garden.  [Except for those hosts who do their own DNS from root or have
    Curtis> configured a DNS forwarder from elsewhere.  Only the geeks.]

Or anyone running DNSSEC, and I expect DNSSEC to be required for
anything working with .gov or .mil or their equivalents in other
countries. 

    Curtis> The original question seems to be whether the same dns query (for
    Curtis> example, garden.example.com) could be made to resolve differently in
    Curtis> ISP-A and ISP-B and the answer is "yes" with no changes but with the
    Curtis> exception within [] in the prior paragraph.

Yes, the dns server can give out different answers to different query
origins. This interacts very poorly with DNS caches, including the ones
on hosts.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 11 Oct 2011 08:11:33 -0400

>>>>> "Peter" == Peter Koch <[email-masked]> writes:

    Peter> it works, but nowhere near perfectly. Whenever a querying system
    Peter> changes its intended name space (resolution context) from $local
    Peter> to the global one, resolution of names in garden.example.com
    Peter> will just time out. Encoding this user experience in the design looks
    Peter> like a suboptimal choice to me.

yes, but what is being asked for now, is that the host equivalent of
/etc/resolv.conf be extended with a list of suffixes.  We are told that
mobile operators (who still think they own the handsets) will be
deploying various application layer systems whereby the application will
always do some DNS requests over 4G, and some content will only be
available that way.

So, this failure you describe will still occur, but instead of "timeout"
the user will get "host not found"

    >> some recognized part of 2000::/3, or an entirely new space).

    Peter> While ULAs would "reduce" collisions, the general issues would be the same
    Peter> as with RFC1918 space.

Thus why I said ULA-C.

---

From: "Howard, Lee" <[email-masked]>
Date: Fri, 21 Oct 2011 11:31:41 -0400

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of james
> woodyatt
> Sent: Monday, October 10, 2011 11:07 PM
> To: [email-masked]
> Cc: [email-masked]
> I wasn't talking about IPv4 at all.  My comments are relevant in a world entirely comprising
> IPv6-only service providers.  The IPv6 Internet will be saddled with all of the problems of
> the IPv4 Internet with respect to devices on homenets having to beg the gateways to allow
> inbound packets from arbitrary remote destinations.  It has nothing to do with NAT, and
> everything to do with firewalls and stateful filters.

s/beg/authorize

---

From: Curtis Villamizar <[email-masked]>
Date: Fri, 21 Oct 2011 09:20:24 -0700

In message <[email-masked]>
 
> > everything to do with firewalls and stateful filters.

That response seems to be confirming the problem.

The customer should not need the ISP to authorize inbound traffic.
Otherwise the service should not be called an "Internet" service.  It
is a service providing only limited Internet connectivity.

Curtis

---

From: "Howard, Lee" <[email-masked]>
Date: Fri, 21 Oct 2011 13:11:45 -0400

> From: Curtis Villamizar [mailto:[email-masked]]
> Sent: Friday, October 21, 2011 12:20 PM
> To: Howard, Lee
> Cc: james woodyatt; [email-masked]; [email-masked]
> In message
> <[email-masked]
> e.com>
> "Howard, Lee" writes:
>
> >

Perhaps I misunderstood the scenario.
I would have the sentence read:
"Devices on homenets have to authorize gateways to allow inbound packets
from arbitrary remote destinations."

Hosts can set their own security policy.  If it's "send me everything," it
can signal a firewall (using e.g. PCP) to allow everything.  If it's "do not call,"
it can signal a firewall (using e.g. PCP) to deny anything not explicitly
allowed.

I do not adhere to "default permit" as a security principle.

Lee

---

From: Cameron Byrne <[email-masked]>
Date: Fri, 21 Oct 2011 10:32:54 -0700

On Oct 21, 2011 10:11 AM, "Howard, Lee" <[email-masked]> wrote:
> > > > From: [email-masked] [mailto:[email-masked]] On
Behalf Of
> > james
> > > > I wasn't talking about IPv4 at all.  My comments are relevant in a
world entirely
> > comprising
> > > > IPv6-only service providers.  The IPv6 Internet will be saddled with
all of the problems
> > of
> > > > the IPv4 Internet with respect to devices on homenets having to beg
the gateways to
> > allow
> > > > inbound packets from arbitrary remote destinations.  It has nothing
to do with NAT,
> > and

Then you also do not care for supporting the e2e principle, and I thought I
heard people mumble e2w  was a good thing at the start of homenet.

I am in the camp the host should be strong and smart and networks should be
simple and fast.

Cb

> Lee
>
> > Curtis
>
> 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: "Howard, Lee" <[email-masked]>
Date: Fri, 21 Oct 2011 14:21:00 -0400

> Then you also do not care for supporting the e2e principle, and I thought
> I heard people mumble e2w  was a good thing at the start of homenet.
> I am in the camp the host should be strong and smart and networks should
> be simple and fast.
>
> Cb

Let's discuss the end-to-end principle and see how it applies here.

rfc1958 quotes from [Saltzer]:
"The function in question can completely and
   correctly be implemented only with the knowledge and help of the
   application standing at the endpoints of the communication system.
   Therefore, providing that questioned function as a feature of the
   communication system itself is not possible. (Sometimes an incomplete
   version of the function provided by the communication system may be
   useful as a performance enhancement.")

In this instance, the "function" could be considered either a) implementation
of a forwarding policy, or b) the application sending/receiving packets.  If
(a), then is is being done "with the knowledge and help of the application,"
so the principle is intact.  If (b), then the firewall is not attempting to
implement that function, only to forward or not forward packets, and the
principle is intact.

All of the examples contemplated in rfc1958 and in the original paper
are about adding processing to packet forwarding, such as error checking,
encryption, or deduplication.  In this case, the host (or application) is
establishing a security policy, and asking for help enforcing that policy.

A general security principle is to drop malicious traffic as close to the
source as possible (rfc3013, rfc3871).

"the end-to-end argument is not an
absolute rule, but rather a guideline that helps in application and protocol design analysis"
http://web.mit.edu/Saltzer/www/publications/endtoend/endtoend.pdf

People can argue that the end-to-end principle prohibits use of stateful firewalls.
I believe that properly implemented, where the host (application) sets the policy
and the gateway/firewall makes a forwarding decision, the principle is upheld.

Lee

---

From: Curtis Villamizar <[email-masked]>
Date: Fri, 21 Oct 2011 11:38:16 -0700

In message <[email-masked]>
"Howard, Lee" writes:
 
> Perhaps I misunderstood the scenario.  I would have the sentence read:
> "Devices on homenets have to authorize gateways to allow inbound
> packets from arbitrary remote destinations."
>  
> Hosts can set their own security policy.  If it's "send me
> everything," it can signal a firewall (using e.g. PCP) to allow
> everything.  If it's "do not call," it can signal a firewall (using
> e.g. PCP) to deny anything not explicitly allowed.
>  

Lee,

Thanks for the prompt response.  Seems it was a misunderstanding and
we are in agreement.  I'm not fond of PCP so if it were my home
router, I'd configure the exceptions on the router.  That should
always be an option.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Fri, 21 Oct 2011 11:49:50 -0700

In message <[email-masked]>
"Howard, Lee" writes:
 
> In this instance, the "function" could be considered either a)
> implementation of a forwarding policy, or b) the application
> sending/receiving packets.  If (a), then is is being done "with the
> knowledge and help of the application," so the principle is intact.
> If (b), then the firewall is not attempting to implement that
> function, only to forward or not forward packets, and the principle is
> intact.
>  
> are about adding processing to packet forwarding, such as error
> checking, encryption, or deduplication.  In this case, the host (or
> application) is establishing a security policy, and asking for help
> enforcing that policy.
>  
> A general security principle is to drop malicious traffic as close to
> the source as possible (rfc3013, rfc3871).
>  
> "the end-to-end argument is not an absolute rule, but rather a
> guideline that helps in application and protocol design analysis"
> People can argue that the end-to-end principle prohibits use of
> stateful firewalls.  I believe that properly implemented, where the
> host (application) sets the policy and the gateway/firewall makes a
> forwarding decision, the principle is upheld.
>  
> Lee

Lee,

What people are arguing is a violation of the end-to-end principle is
having a provider put in place filters that can't be shut of by the
consumer.  It would be preferable if the consumer could shut them off
completely with at most one support call and then take responsibility
themselves or better yet have configuration control over the firewall.

If a mechanism is provided to poke pinholes, that may be acceptable to
some.  PCP may not be acceptable to many, preferring a configuration
(persistent) change to the firewall.

I for one would rather you shut off any firewall that you provide and
leave it to me (and I would find another provider if you couldn't do
that).  But that is not typical.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Fri, 21 Oct 2011 12:04:03 -0700

In message <CAD6AjGRqy4yjHpWnY+qEiyuJ8egvNtH=5stj=[email-masked]>
Cameron Byrne writes:
 
> I am in the camp the host should be strong and smart and networks
> should be simple and fast.
>  
> Cb

Same here but we can't get rid of all the windows systems out there.

So service providers are compelled to put firewalls in front of
consumer customers (and even most small business) and have them
enabled by default.

To not do so would result in the service provider having a network of
malicious bots (as opposed to a network containing a subset of sites
running malware that the service provider couldn't prevent).

Back in the early 1990s I argued that we should not let windows
systems on the Internet.  That was back when your network (college
campuses, corporations, etc) could be shut down by a provider if
attacks were coming out of it and you did nothing to completely
eradicate it.  An example of this was Mitnik breaking into a
university in Houston and Sesquinet shutting off their Internet for
four days due to a computer science department response that security
was a hard problem and from a practical standpoint there was nothing
they could do about it.  Back then, if you couldn't make it secure, it
didn't belong on the Internet.

I do see your point and agree with you.  From a technical perspective,
firewalls are an inadequate bandaid over a set of OS and application
security problems and the right thing to do is fix the root casue.

Curtis

---

From: Cameron Byrne <[email-masked]>
Date: Fri, 21 Oct 2011 12:31:14 -0700

> Same here but we can't get rid of all the windows systems out there.

Why?  Even windows XP comes with a host based firewall since 2003 ...
That's coming up on 10 years by the time homenet influences the
market.

<sarcasm>

. blah blah blah... we all must engineer for the least common
denominator because somebody out there can be attacked by the Morris
Worm still...

</sarcasm>

And, most (cite?) actual attacks are not preventable with a $30 home
router.  Most (cite?) homenet security issues are relate to phishing
and users downloading and installing malware with admin privilege,
which PCP and stateful firewalls cannot solve.

> running malware that the service provider couldn't prevent).

Is there proof that $30 home routers protect computers and "move the
needle" on malware?  Or is this left over mindset from  the 1990s?

> didn't belong on the Internet.

Would a firewall stopped this or was this social engineering?  Also,
this is not the 1990s... Things are indeed better now from a network
programming perspective. Social engineering and so on are a different
layer.

> security problems and the right thing to do is fix the root casue.
^^^^
Good stuff there.  Lets focus on that instead of the dogma and FUD to
create "homenet" of the future.

Thanks,

Cameron

---

From: "Howard, Lee" <[email-masked]>
Date: Fri, 21 Oct 2011 17:22:32 -0400

I've had some of these arguments before, but I'll write them down now
so there's a record.  Maybe we should document the debated points in
a discussion draft, so we could invite further comment.

> which PCP and stateful firewalls cannot solve.

Port scanning is largely blocked by stateful firewalls.  Thus it's not the
prevention of actual attacks, but the fact that attacks don't exist because
they're useless given the existence of firewalls.

> > consumer customers (and even most small business) and have them

btw, I realize we operated from different assumptions.  My default view
is that the customer manages the gateway/firewall, not the ISP (or maybe
in addition to the ISP).  So in my world view, it's clear that the user (or
host, or application) sets the security policy, which is enforced by the
firewall.  So if one OS believes it is invulnerable, it can signal the firewall
to allow all traffic to it.  If another OS wants defense in depth, it can
signal the firewall to allow only wanted traffic.  You may s/OS/app.

> needle" on malware?  Or is this left over mindset from  the 1990s?

I argue they hold the needle on malware, and there's no reason to make
it easier to attack ignorant users.

Somebody else once said:
> There are no attacks in IPv6, what are we protecting against?
We should design security in before there are attacks, not wait and see
what gets attacked.

To be constructive, I would like home routers (or at least home border
gateways) have a "default deny" security policy, which can be
overriden by user configuration or signaling from internal hosts that
traffic is wanted.  "Signaling" could be PCP, uPNP, SYN, etc.

Lee

---

From: Hans Liu <[email-masked]>
Date: Sat, 22 Oct 2011 01:03:22 +0000

+1 Agree with Lee. 

Best regards,
Hans

Sent from Hans' iPad2

---

From: Curtis Villamizar <[email-masked]>
Date: Fri, 21 Oct 2011 18:52:23 -0700

In message <CAD6AjGQCbRkqE4tg3P=[email-masked]>
 
> create "homenet" of the future.

Cameron,

I was arguing against firewalls as a security solution.  You seemed to
have missed the whole point of the email.  Pleae reread it.

At most you could say that I conceded that firewalls are a marginal
improvement (and therefore won't go away).  For the provider it may be
whether 90% of their users end up running malware or 10% (cite?).
When there is a new remote exploit discovered it limits the damage.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Fri, 21 Oct 2011 19:37:02 -0700

In message <[email-masked]>
"Howard, Lee" writes:
 
> Port scanning is largely blocked by stateful firewalls.  Thus it's not
> the prevention of actual attacks, but the fact that attacks don't
> exist because they're useless given the existence of firewalls.

Its absurd for companies to put firewalls in and then use that as an
excuse to run tftp to load images or configuration.

If you as a company get someone good to do a security audit, they will
do port scans for you and tell you what, if anything, is a potential
problem.  For enterprise, using a firewall instead of doing this just
means that as soon as one PC is running malware, that exposure is wide
open.

> btw, I realize we operated from different assumptions.  My default
> view is that the customer manages the gateway/firewall, not the ISP
> (or maybe in addition to the ISP).  So in my world view, it's clear
> that the user (or host, or application) sets the security policy,
> which is enforced by the firewall.  So if one OS believes it is
> invulnerable, it can signal the firewall to allow all traffic to it.
> If another OS wants defense in depth, it can signal the firewall to
> allow only wanted traffic.  You may s/OS/app.

Some MSOs install a router with firewall enabled.  Most will
cheerfully disable it completely on request.  I got a MSO business
service and it took a while before they disabled it *and* saved the
config so it didn't come back, even though I kept telling them they
needed to do that.  It was a small battle to get them to turn off
their NAT, their firewall, their DHCP, and then a bit of a larger
battle to get them to do rDNS.

> it easier to attack ignorant users.

There are a lot of retired people where I live and many will tell you
that they think its time to upgrade their windows 98 PC.  They *need*
someone to put up a firewall for them.

> We should design security in before there are attacks, not wait and
> see what gets attacked.
>  

Agree.  For consumer and small business, firewall enabled is a
reasonable default.  I would not like to see it recommended in an RFC
unless it was explained why the sorry state of PC software has made it
a necessary evil, at least for now.

Curtis

---

From: Cameron Byrne <[email-masked]>
Date: Fri, 21 Oct 2011 19:37:35 -0700

On Oct 21, 2011 6:52 PM, "Curtis Villamizar" <[email-masked]> wrote:
>
>
> In message <CAD6AjGQCbRkqE4tg3P=+
[email-masked]>
> have missed the whole point of the email.  Pleae reread it.

Got it, no firewalls, you are against them.

> When there is a new remote exploit discovered it limits the damage.

Got it, you think firewalls are required because gradma is running BIND 8.

But, my point is that sp3 windows xp has a default on firewalls. So, assume
10yo software, what exploits are we preventing? How often do they occur?

I am just looking for specific data so we can make a data supported
decision.

Cb

---

From: Cameron Byrne <[email-masked]>
Date: Fri, 21 Oct 2011 20:02:01 -0700

> But, my point is that sp3 windows xp has a default on firewalls. So,
assume 10yo software, what exploits are we preventing? How often do they
occur?
decision.
> Cb

http://www.netmarketshare.com/operating-system-market-share.aspx?qprid=10

Accoding to this data, 0.16% are running win2k, which afaik does not have a
standard OS based default firewall and is the last Windows OS to not have a
standard host based firewall that prevents remote attacks.

Are we really engineering and setting security policy for less than1%?  Keep
in mind this 1% is getting even smaller.

Cb

---

From: Curtis Villamizar <[email-masked]>
Date: Fri, 21 Oct 2011 21:48:18 -0700

In message <[email-masked]>
Cameron Byrne writes:
> assume 10yo software, what exploits are we preventing? How often do
> they occur?
>  

As far as I am concerned you may have come close to winning this
argument with the statistic that 0.16% of hosts predate firewalls in
the host OS.

OTOH - I don't think the last windows remote exploit predates when XP
was introduced.  Search for "microsoft windows and remote exploit" at
http://www.kb.cert.org/vuls/html/search to get plenty of data to
support your decisions.  Here is a 2008 example where a firewall would
help: http://www.kb.cert.org/vuls/id/827267 .  It took a few minutes
to find an exploit like this in the very long list.

Most attacks do involve getting the user to view a web page or open an
email attachment or something like that.  For example
http://www.kb.cert.org/vuls/id/230057 (that's 2011).  And in such a
case a firewall usually doesn't help.  There are tons of these.

Curtis

---

From: Ray Bellis <[email-masked]>
Date: Mon, 24 Oct 2011 08:15:45 +0000

On 21 Oct 2011, at 19:49, Curtis Villamizar wrote:

> consumer.

<chair hat="on">

Anything outside of the home network is outside of our scope.

</chair>

Ray