Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router

From: Ray Hunter <[email-masked]>
Date: Tue, 02 Aug 2011 09:47:31 +0200

>
> Subject:
> Re: [v6ops] default LAN routing protocol for IPv6 CE router
> From:
> Lorenzo Colitti <[email-masked]>
> Date:
> Mon, 1 Aug 2011 14:47:46 -0400
>
> To:
> Philip Homburg <[email-masked]>
> CC:
> "[email-masked]" <[email-masked]>
>
> Precedence:
> list
> MIME-Version:
> 1.0
> References:
> <[email-masked]> 
> <[email-masked]> 
> <CAKD1Yr09v1o79Kihxtzh1XZfARA2=[email-masked]> 
> <[email-masked]> 
> <CAKD1Yr1Q=[email-masked]> 
> <[email-masked]>
> In-Reply-To:
> <[email-masked]>
> Message-ID:
> <[email-masked]>
> Content-Type:
> multipart/alternative; boundary=000e0cd47baa5cf3fd04a976125a
> Message:
> 3
>
>
> On Mon, Aug 1, 2011 at 14:40, Philip Homburg 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     It doesn't matter how do it. If it is done using an IGP, then can
>     you bet that
>     either some ISP happens to be using that IGP on WAN links, or that
>     some script
>     kiddies will try to see what happens if you try to send those
>     packets to
>     random CPEs.
>
>
> IGPs support authentication. As part of setting up your home network, 
> you could associate CPEs with each other and use that to form a common 
> auth key.
It isn't the mechanics or technology of the protocols that's the issue: 
it's the trust relationship, the service boundary, and the cost of 
operational support. The home network and the ISP network are 2 
different management domains.

If the ISP wants to control a firewall or other equipment on a user's 
premises then they probably need to provide and own the firewall or CPE. 
Vice versa for the end user. The mix of a user owned firewall with an 
ISP provided configuration (even if that's just enable/disable function) 
just won't work practically in operations. And that's even before the 
lawyers get involved. It's not an issue that the IETF should attempt to 
solve/ automate using protocols IMVHO.

I don't see why a simple guest or DMZ network would require a VRF-Lite 
type solution to separate routing tables either, as long as a stateful 
firewall on the home network ensures logical separation of the two prefixes.

As for only delegating a single /64 to home users
i) I would hope ISP's are more sympathetic to home users who have 
genuine needs for a DMZ, guest LAN etc. now that NAT won't provide a 
solution for this requirement
ii) I would also hope that CIDR works beyond 64 bit prefix lengths (even 
if SLAAC doesn't yet)

regards,
RayH

---

From: Philip Homburg <[email-masked]>
Date: Tue, 02 Aug 2011 10:22:07 +0200

>solve/ automate using protocols IMVHO.

I don't think it is matter of an ISP wanting to control the user's firewall.

Suppose you have a generic home router, just a bunch of ethernet ports and
some proessing in a small box.

If the home router is attached to a WAN link, then it has to enable its 
firewall to separate the WAN link from the internal links.

If the router is used internal to the user's network then it should not 
enable its firewall, unless one of the ports is connected to the guest network
but then it should have a firewall tailered to guest networks.

How do you construct a router such that the router always knows what it
has to do, or at least is in some sense fail-safe?

---

From: Ray Hunter <[email-masked]>
Date: Tue, 02 Aug 2011 12:12:12 +0200

I think the earlier suggestion of Lee Howard to capture requirements for 
a home network first is a very good one.

In the current discussion, I don't think it's fully defined yet who 
operates your "generic home router" and under what conditions: whether 
the home router is one operated by the user onto a shared bridged IPv6 
access network, or whether the home router spec will be used by an ISP 
for purchasing and operating the home router, and which then also has to 
take into account the user's requirements for more than one local LAN in 
the home, or whether there are 2 home router devices (one operated by 
the user and one operated by the ISP), or even more home router devices 
that also route between IPv6 prefixes.

Appropriate behaviour of an interface will depend very much on the 
management and deployment scenario.

In IPv4 + NAT that was pretty much irrelevant. The outbound path and 
address could be learned by acting as a DHCPv4 client and the reverse 
path was "learned" via NAT. And each cascaded device could in turn act 
as a DHCPv4 server for its downstream neighbors. A simple "outbound 
only" firewall rarely did harm either. So simple cascading pretty much 
always worked without any configuration at all.

What if a user stacks multiple home routers in IPv6?
Do you assume / enforce a tree structure for a home network?
Do you assume / enforce a single-homed ISP model?

I know cascaded PD has been discussed many times in the past, but is 
there an RFC for how it should operate in practice?
RFC5877 says "Renumbering Still Needs Work"

So back to requirements, I think a list might conceivably consist of:
1) a home router should automatically discover its neighbors on a per 
port basis.
2) a home router should able to automatically detect whether each 
neighbor is in the same management domain or not
3) a home router should control peering in a secure manner
4) a home router should automatically learn prefixes and interface 
addresses (NB PD is only defined in rfc3769 to be to a single router 
attached to an ISP link, and sub-delegations within the site are NOT 
communicated back to the ISP)
5) Depending on its peering, a home router should determine it's 
position in the network relative to the CPE PD router (the root of the 
prefix delegation / home network assuming a tree structure).
6) Depending on it's position in the home network, a home router should 
automatically determine what functions it needs to enable per port 
(firewall, learning a delegated prefix, delegating further prefixes, 
management access allowed .... )

Most current IGP's would fulfill many of those requirements, but 
probably not all. The main problem is I don't think the above list is 
anywhere near definitive or widely accepted. So saying one protocol or 
mechanism is "better" than another is then a bit premature IMHO.

regards,
RayH

---

From: "Weil, Jason" <[email-masked]>
Date: Tue, 2 Aug 2011 07:39:15 -0400

Ray,

I also agree that requirements and use cases seem the next logical step. I'd be willing to document the ones that we are contemplating. It would be useful to have someone more familiar with DSL/Fiber residential deployments do so there as well.

As has already been mentioned, this is a great conversation but it really belongs on the Homenet list at this point (copying that list in case people are not following both).

Jason

From: Ray Hunter <[email-masked]<mailto:[email-masked]>>
Date: Tue, 2 Aug 2011 06:12:12 -0400
To: Philip Homburg <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router

I think the earlier suggestion of Lee Howard to capture requirements for a home network first is a very good one.

In the current discussion, I don't think it's fully defined yet who operates your "generic home router" and under what conditions: whether the home router is one operated by the user onto a shared bridged IPv6 access network, or whether the home router spec will be used by an ISP for purchasing and operating the home router, and which then also has to take into account the user's requirements for more than one local LAN in the home, or whether there are 2 home router devices (one operated by the user and one operated by the ISP), or even more home router devices that also route between IPv6 prefixes.

Appropriate behaviour of an interface will depend very much on the management and deployment scenario.

In IPv4 + NAT that was pretty much irrelevant. The outbound path and address could be learned by acting as a DHCPv4 client and the reverse path was "learned" via NAT. And each cascaded device could in turn act as a DHCPv4 server for its downstream neighbors. A simple "outbound only" firewall rarely did harm either. So simple cascading pretty much always worked without any configuration at all.

I know cascaded PD has been discussed many times in the past, but is there an RFC for how it should operate in practice?
RFC5877 says "Renumbering Still Needs Work"

So back to requirements, I think a list might conceivably consist of:
1) a home router should automatically discover its neighbors on a per port basis.
2) a home router should able to automatically detect whether each neighbor is in the same management domain or not
3) a home router should control peering in a secure manner
4) a home router should automatically learn prefixes and interface addresses (NB PD is only defined in rfc3769 to be to a single router attached to an ISP link, and sub-delegations within the site are NOT communicated back to the ISP)
5) Depending on its peering, a home router should determine it's position in the network relative to the CPE PD router (the root of the prefix delegation / home network assuming a tree structure).
6) Depending on it's position in the home network, a home router should automatically determine what functions it needs to enable per port (firewall, learning a delegated prefix, delegating further prefixes, management access allowed .... )

Most current IGP's would fulfill many of those requirements, but probably not all. The main problem is I don't think the above list is anywhere near definitive or widely accepted. So saying one protocol or mechanism is "better" than another is then a bit premature IMHO.

regards,
RayH

Philip Homburg wrote:

________________________________
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: Ray Bellis <[email-masked]>
Date: Tue, 2 Aug 2011 11:53:28 +0000

Jason 

Thanks for the cross-post.

I agree that this discussion does indeed belong in Homenet, where we are specifically chartered to investigate the issues surrounding addressing and routing within the SOHO network.

Ray Bellis
Homenet WG co-chair

---

From: Keith Moore <[email-masked]>
Date: Tue, 2 Aug 2011 08:28:10 -0400

> has to do, or at least is in some sense fail-safe?

The idea that a firewall should automatically know what "it has to do" strikes me as utterly bizarre.   I realize that there's a desire to minimize the configuration burden for unsophisticated users (and agree with that), but the idea that the firewall knows better than the user what his security policy should be seems ridiculous.

A different idea is that the firewall always work in a very minimal mode by default (e.g. it passes no traffic, or maybe only outgoing port 80 traffic, but its configuration interface is enabled for the internal ports) so that the user must configure it in order to get it to do anything useful.  That way, the first thing a user learns about his router/firewall is how to configure it.  Then you want to focus on making the configuration interface easy to understand.  (You also have to figure out how to keep the user from hooking up the internal port to the external connection.)

But these are user interface issues, not protocol issues.   Perhaps they're better addressed in homenet than here.

Keith

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Tue, 2 Aug 2011 10:08:32 -0400

+1, Keith.

Auto-magic is good for basic functions, but not for advanced functions.

Cheers,
Rajiv

Sent from Phone....

On Aug 2, 2011, at 8:28 AM, "Keith Moore" <[email-masked]> wrote:

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

---

From: Keith Moore <[email-masked]>
Date: Tue, 2 Aug 2011 11:56:24 -0400

On Aug 2, 2011, at 11:39 AM, Nick Hilliard wrote:

> On 02/08/2011 13:28, Keith Moore wrote:
>> A different idea is that the firewall always work in a very minimal mode
>> by default (e.g. it passes no traffic, or maybe only outgoing port 80
>> traffic, but its configuration interface is enabled for the internal
>> ports) so that the user must configure it in order to get it to do
>> anything useful.
> 
> Each support call into a support centre costs money, and if you scale it
> up, any user that ends up calling support is basically losing money for the
> ISP.  Yes, margins are that thin.
> 
> Building a firewall that almost guarantees that an end-user will need to
> open a support call is both useless to the end-user and financially harmful
> to a service provider.  There is no point whatsoever in doing this - it
> adds pointless complexity with no measurable return.
> 
> If you want to build a router suitable for Keith Moore, then go out and
> customise a WRT54G, or hack a soekris into shape.  But don't assume that
> most end-users have either the interest or the capability to work out a
> good quality security policy for themselves because by-and-large, they don't.

I understand all of that.  What I'm saying is that having the router try to be clever about what the policy should be, is even worse.  

Keith

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 02 Aug 2011 16:39:47 +0100

Nick

---

From: "Brzozowski, John" <[email-masked]>
Date: Tue, 2 Aug 2011 23:08:49 +0000

On 8/2/11 3:47 AM, "Ray Hunter" <[email-masked]> wrote:

>i) I would hope ISP's are more sympathetic to home users who have genuine
>needs for a DMZ, guest LAN etc. now that NAT won't provide a solution for
>this requirement
[jjmb] I am sure shorter allocations will be available.  As I stated in an
earlier email the end user also needs to make sure their CPE supports the
same.

>ii) I would also hope that CIDR works beyond 64 bit prefix lengths (even
[jjmb] assuming you are referring to longer than /64 this could work you
would have to leverage DHCPv6 for address assignment or static
configuration.  I imagine this may complicate renumbering.

---

From: "Brzozowski, John" <[email-masked]>
Date: Tue, 2 Aug 2011 23:08:55 +0000

On 8/2/11 8:28 AM, "Keith Moore" <[email-masked]> wrote:

>The idea that a firewall should automatically know what "it has to do"
>strikes me as utterly bizarre.   I realize that there's a desire to
>minimize the configuration burden for unsophisticated users (and agree
>with that), but the idea that the firewall knows better than the user
>what his security policy should be seems ridiculous.
[jjmb] I agree Keith that having a firewall automatically know what to do
is a tall order.  I also think the is more than a desire to ease
configuration burden, this is a must since most users on the Internet have
very basic technical skills.
>anything useful.  That way, the first thing a user learns about his
>router/firewall is how to configure it.  Then you want to focus on making
>the configuration interface easy to understand.  (You also have to figure
>out how to keep the user from hooking up the internal port to the
>external connection.)
[jjmb] I said something similar to this is in an earlier email.  To the
start there should perhaps be a basic configuration that protects the user
and allows the service to be usable.
>
>But these are user interface issues, not protocol issues.   Perhaps
>they're better addressed in homenet than here.
[jjmb] I could image some protocol work that could ease the pain here, UI
for sure could facilitate ease of use.

---

From: Mark Smith <[email-masked]>
Date: Wed, 3 Aug 2011 19:10:38 +0930

On Tue, 2 Aug 2011 11:56:24 -0400

> > good quality security policy for themselves because by-and-large, they don't.

Which is why host OS vendors have taken over that policy definition, and
provided simple labels such as "home network", "public network" etc.
and, for example, when the link on a network connection comes up, asks
the end-user where they are/what type of network they've attached to -
and that could be automated by recognising the attached networks by
using network identifiers such as Wifi SSID or default router MAC
addresses.

> I understand all of that.  What I'm saying is that having the router try to be clever about what the policy should be, is even worse.  

And if CPE firewalls become too smart or too obstructionist,
Internet application developers will just come up with, or
rather, reuse the NAT traversal techniques they've developed in the
past, adapted to IPv6, to make their applications traverse those CPE
firewalls.

Fundamentally I think an arms war exists between Internet
application developers and the entities who deploy network
located constraints, such as firewalls or NAT, which the networked
application developers will always want to win. If their networked
applications can't work over the Internet, regardless of the commonly
encountered constraints, then there is no point in writing them in the
first place, so the developers have a very basic and fundamental motive
to work around these constraints.

---

From: Keith Moore <[email-masked]>
Date: Wed, 3 Aug 2011 07:47:37 -0400

> to work around these constraints.

+1

---

From: Philip Homburg <[email-masked]>
Date: Wed, 03 Aug 2011 13:58:32 +0200

>> to work around these constraints.

-1

This line of reasoning doesn't make sense to me. 

When it comes to NAT, why would there be a war? A NAT is not try to block any
traffic. It usually has to do a complicated job on a small budget.

Same applies to firewalls. If I want to run an application, why would I wait
for developers to figure out how to bypass my firewall?

---

From: Keith Moore <[email-masked]>
Date: Wed, 3 Aug 2011 08:09:59 -0400

> traffic. It usually has to do a complicated job on a small budget.

NAT absolutely has the effect of blocking traffic, and many people have been sold NATs on the basis that they are a security measure.

> for developers to figure out how to bypass my firewall? 

In general, many people want the "right thing" to happen without having to think much about whether it's really the "right thing".  When it doesn't work, they don't want to question whether it's their network configuration that is the problem.

The "right thing" is that applications that they want to work, work, and applications that they don't want to work, don't work.  And somehow, magically, the network is supposed to know the difference.

If the application doesn't work through the NAT or the firewall in its existing configuration, in these people's minds, it's the application's fault.

Applications that don't work through NATs and firewalls face an almost-insurmountable barrier to deployment.  So most of the applications that people have heard of, work through NATs and most firewalls.  This further reinforces the perception that the only applications that matter are those that have no trouble with NATs and firewalls.

The need to make applications work through NATs and firewalls means that those applications cost quite a bit more to develop and deliver, which itself imposes a huge barrier.  And yet, people will cite the existence of such applications as evidence that NATs don't cause problems for applications.  (though these days, at least most IETF people are a bit more enlightened than that)

Keith

---

From: Mark Smith <[email-masked]>
Date: Wed, 3 Aug 2011 22:11:39 +0930

On Wed, 03 Aug 2011 13:58:32 +0200
Philip Homburg <[email-masked]> wrote:

> When it comes to NAT, why would there be a war?

To clarify, I meant an "arms race" not "arms war".

> A NAT is not try to block any traffic.

By it's nature it blocks traffic in the inbound direction, regardless
of whether that is what the end-user/application wants. Work arounds
like manual port forwarding stun, Upnp etc. overcome that to some
extent, but they're *work arounds*, and ultimately multiple hosts
behind the NAT can't share the same inbound transport layer port.
Any application whose communication is best suited to a peer-to-peer
architecture may have to work around NATs by using an publicly
addressed and mutually visible intermediary or host between the
application peers. This relay host is another point of failure,
potentially a performance bottle neck, and potentially a
man-in-the-middle for the application. A prominent example of an
peer-to-peer natured application that has got to a lot of effort to
work around NATs is Skype. Imagine if that developer time could have
instead been used to develop new features, improve core application
functionality, or fix bugs sooner.

> It usually has to do a complicated job on a small budget.
> 

Upstream/network located firewalls create the same sorts of constraints
that NATs do. Certainly IPv6 firewalls with e.g. UPnP are going to be
better as there is no NAT involved, so transport layer ports can be
"shared" or are unique to each host. However, if the CPE firewall is
more than one hop away from the host running UPnP so UPnP doesn't work,
or the CPE doesn't support a protocol like UPnP, then the application
either will fail to work, or the application developer will have to
spend time developing work arounds for the network constraint.

Application developers would want their application to work for 100% of
people try to use it. If they can't achieve 100%, they would want as
close to it. Say 20% of the possible users of the application have IPv6
CPE firewalls that can't be switched off via UPnP or something similar,
the application developer will have to spend time developing work
arounds.

Regards,
Mark.

---

From: Philip Homburg <[email-masked]>
Date: Wed, 03 Aug 2011 15:18:33 +0200

>of whether that is what the end-user/application wants. 

Same thing. An arms race implies a sequence of steps where both sides will
use more and more heavy machinery to win.

NAT doesn't do that. It just does its thing.

>Work arounds

Exactly. That's technical limitation. Not some sort of 'race'.

>A prominent example of an

Well, it is just a fact of life. IPv4 comes with NAT. 

It's a pity that application developers seems so silent on this issue. I
haven't checked, does Skype even do IPv6?

If they would make apps that would work better on IPv6 then there would be a
lot more demand.

At the moment, as shown on IPv6day, IPv6 is just IPv4 but different. Doesn't
seem to have any benefit at all.

>spend time developing work arounds for the network constraint.

Dealing with NAT is tricky due to the technical limitation of NAT.

When firewalls became mainstream, there were lots of servers that could
be exploited easily. At the moment, clients have caught up with servers and
are now at least as easy to exploit if not easier.

So now may be the right time to revisit firewall control protocols to try to
get applications, hosts and firewalls to cooperate implementing a sensible
security policy.

>the application developer will have to spend time developing work

I'd say, we should create good protocols that do work and can be supported
easily by applications, operating systems, and network devices.

There will always be broken environments. It's upto application developers
whether they want to support them or not.

---

From: Keith Moore <[email-masked]>
Date: Wed, 3 Aug 2011 09:23:16 -0400

> If they would make apps that would work better on IPv6 then there would be a

Ah yes, that tiny fraction of the net that has reliable IPv6 access would be clamoring for chance to use those apps to communicate with others in that tiny fraction.

Keith

---

From: "Brzozowski, John" <[email-masked]>
Date: Tue, 2 Aug 2011 23:09:00 +0000

>ISP.  Yes, margins are that thin.
[jjmb] +1
>adds pointless complexity with no measurable return.
[jjmb] conversely building a firewall that exposes the provider will also
cost in some way shape or form.
>good quality security policy for themselves because by-and-large, they
[jjmb] advanced users should buy advance routers so they can do advanced
things.