Subject: CPEs

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 4 Jan 2008 13:34:38 +0100

Let me tackle three issues related to CPEs in one monster message.  
These issues are:

- firewalling
- address provisioning
- IPv4/IPv6 transition/coexistance

When I say "CPE" that can both mean a cable/DSL modem, a home router  
with integrated cable/DSL modem or a home router with no modem  
functionality. I'll call them CPE(m), CPE(r) or CPE(rm) where  
appropriate. If they're managed by the ISP I may add -ISP, if they're  
managed by the end-user/consumer I may add -USER. Note that all of  
this applies to consumer installations.

First, let me start with a few sentences on my philosophy in this area  
and then a list of issues that we need to figure out so the industry  
can move forward.

CPE philosophy
--------------

Because broadband consumers span the gamut from completely ignorant  
about even the most superficial technical issues to people who  
actually build those CPEs, the most important thing is that a CPE can  
address all reasonable use cases along that gamut. In other words: an  
expert user shouldn't be forced to live with what's best for that  
granny who doesn't even have a PC but does have some IP enabled  
devices such as picture frames or sewing machines, but on the other  
hand, the granny shouldn't be forced to become an expert.

What this means is that the defaults are such that non-expert users  
get the tradeoff between security, usability and other aspects that is  
most appropriate (which would be the default settings), but experts  
get to override these defaults. At the very least, it MUST be possible  
to make the CPE act transparently.

Security

As for security: these days, any IP device MUST be ready to be  
connected to a hostile network, which includes the open internet.  
However, because this wasn't true in the past and because removing a  
layer of "security" is scary, it's not possible to market CPEs that  
don't do any filtering. This means that there must be filtering, but  
since it doesn't do anything useful in practice and it does get in the  
way, this filtering must be the minimum that will be accepted by the  
market. That would almost certainly be the level of filtering that is  
de facto provided in today's IPv4 CPEs, which is: outgoing sessions  
and related return traffic is allowed (stateful filtering) and  
applications get to open up TCP/UDP ports for incoming traffic.

Now obviously it's possible to argue that this isn't a good way of  
filtering (in both directions, it can be too much or too little), but  
since that is what you get with pretty much any current CPE those  
discussions are largely moot. The only changes that are possible are  
those that BOTH improve security AND usability at the same time. Any  
change that improves one over the other will be seen as unacceptable  
by one camp.

Transition

Ideally, a CPE will provide both IPv4 and IPv6 service to hosts  
connected to it, regardless of whether the ISP provides IPv4, IPv6 or  
both. So that probably means: regular IPv4 operation, native IPv6,  
6to4, Teredo, NAT-PT... It would be even better if IPv4 hosts behind  
the CPE could make use of IPv6 services and the other way around.  
(Maybe using an HTTP(S) proxy?)

Multiple CPEs

Obviously if there is a CPE(m) then it should also be possible to add  
a CPE(r), but users may have reasons to have multiple CPE(r)s,  
possibly connected in parallel to a CPE(m) but having one CPE(r)  
connect to the LAN side of another CPE(r) would also be a possibility,  
and even the only possible option if there is a CPE(mr). Although  
security policies may prohibit certain applications to work across a  
CPE(r), service discovery and addressing should be transparent within  
the entire site.

Questions
---------

Security

1. Do we all agree that a model where there is stateful filtering by  
default, but applications can request incoming sessions is what we  
should aim for?

2. Or should the opening up of incoming ports go through the OS,  
rather than be signalled directly from applications to the CPE?

3. Should a host have the option of signalling to a CPE that it  
doesn't require any filtering?

Address provisioning

4. Is implementing DHCPv6 snooping and option insertion, similar to  
what currently happens with DHCP for IPv4, a good option for vendors  
of broadband equipment, or is a provisioning solution where this isn't  
necessary preferable?

5. Can we assume the presence of DHCPv6 prefix delegation in CPEs?

6. Can we assume the presence of DHCPv6 address assignment in clients?  
It's not available in most of them now, so how would we get to such a  
state and how soon?

7. Is the model where there is a CPE with modem functionality but not  
router functionality a reasonable one?

8. Do we want to ISPs to provide RAs to customers in the case where 6  
= no and 7 = yes? If not, then what?

9. If 8, then what is the value of the M and O bits?

10. If 5 and a user adds more than one routing CPE, how does the  
prefix delegation work? The "first" routing CPE requests a prefix from  
the ISP and then provides sub-prefixes to the other CPE(r)s, or does  
each CPE get a prefix from the ISP? In the latter case, how do CPE(r)s  
know what routes to install for prefixes held by other CPE(r)s within  
the site?

11. Do we expect ISPs to provide reachability for a new and old prefix  
concurrently when changing prefixes or do ISPs provide long-time  
stable prefixes to IPv6 customers? If "no" on both, then how do we  
avoid disconnected sessions on prefix changes?

12. How do we avoid problems caused by customer equipment MAC  
addresses clashing with that of other customers?

13. How many devices are allowed to connect to a CPE(m)?

14. What kind of addressing is used between the ISP and the first  
CPE(r)? Global customer specific, global shared between customers,  
link local only?

15. How does DAD work on the subnet between an ISP and customers?  
Should hosts and CPEs ignore their own DAD packets when they loop back  
to them?

DNS

16. How do we expect customer devices to enter into the DNS?

17. If the answer to 16 is dynamic DNS updates, how does the  
authentication work?

18. Should IPv6 hosts be prepared to operate without a working reverse  
DNS entry?

Third party devices

19. How do users authorize third-party devices (ranging from gas  
meters to set top boxes) use of their broadband connection?

20. How can third party devices be prevented from observing both data  
traffic and service discovery?

21. How can third party device traffic be limited and/or given QoS?

---

From: Shane Kerr <[email-masked]>
Date: Fri, 4 Jan 2008 16:32:55 +0100

Iljitsch,

> default, but applications can request incoming sessions is what we

I agree.

> rather than be signalled directly from applications to the CPE?

I think it should be done by the applications. As an application
developer, having the OS doing some stuff that I may or may not know
about is no better than the current NAT situation. Do we really want
to have to have an application-level STUN-equivalent?

> doesn't require any filtering?

This makes sense to me. I can see a lot of situations where I would
want to tell someone "click on the 'no IPv6 filtering' button and
we'll try it again".

> of broadband equipment, or is a provisioning solution where this isn't  

(I'm not an operator, so I can't answer.)

> 5. Can we assume the presence of DHCPv6 prefix delegation in CPEs?

I don't think this is 100% necessary. There are other ways to get a
prefix to a customer premise. For instance, equipment can be shipped
with the prefixed pre-configured. If a customer purchases their own
gear, they can configure prefixes statically.

So, "no". :)

> It's not available in most of them now, so how would we get to such a  

In the near term (say 5 years), I don't think we can assume DHCPv6
address assignment in general. Specific operators who supply their own
equipment can mandate this, of course.

> router functionality a reasonable one?

I don't think so. Minimal routing is very lightweight considering
current technology in CPE.

> = no and 7 = yes? If not, then what?

Well, if the CPE doesn't do it, then it has to be the ISP, right?

> know what routes to install for prefixes held by other CPE(r)s within  

Well... given the current allocation model, I would think the ISP
would give /48 to the "first" CPE via prefix delegation, and then this
CPE could give /64 out to any other requesting CPE.

"/48 is the new /32", "/64 is the new RFC 1918"... ?

> avoid disconnected sessions on prefix changes?

Personally I like the model of providing reachability for both old and
new during renumbering. But... since an ISP only gets a few thousand
/48 at a time, they may be faced with resource scarcity, and not have
the space (GROAN!!!!).

> addresses clashing with that of other customers?

In which context? I thought both autoconf and DHCPv6 made provision
for this?

> 13. How many devices are allowed to connect to a CPE(m)?

I don't understand the question... ?

> CPE(r)? Global customer specific, global shared between customers,  

Site local? :)

Seriously, I'd just use global from the management network, although
that does leave possiblity of leakage...
 
> 16. How do we expect customer devices to enter into the DNS?

I think the DNS strategy needs to be mapped to the addressing
strategy (we're talking about ip6.arpa, right?).

For PD I am in favor of delegating to the CPE (although knowing which
address the server is sitting at is tricky). I know this violates the
DNS idea of redundant servers, but as a customer at the end of a pipe
I don't really care if people have reverse for my IP addresses if my
pipe breaks.

> 17. If the answer to 16 is dynamic DNS updates, how does the  

Well... if the ISP has good control over their network, then using
source IP address may make sense. And maybe someday hosts will use
RFC 3971 (SEND), and that will make even more sense...

> 18. Should IPv6 hosts be prepared to operate without a working reverse  

Yes.

(My own take is that we should have deprecated reverse for IPv6,
because of these issues. The costs outweigh the benefits. Nobody
seemed to agree with me when I pushed for this though. Sometimes I
hate DNS weenies.)

> 21. How can third party device traffic be limited and/or given QoS?

Right now, this is all all layer 2, right? Is there a special reason
not to continue this model?

--
Shane

---

From: Christian Huitema <[email-masked]>
Date: Fri, 4 Jan 2008 10:28:43 -0800

> doesn't require any filtering?

I agree with Iljitsch assessment of the state of the market. Stateful filtering in the CPE is technically useless and gets in the way, but there is probably no way to sell a CPE today that doesn't do it. So, whatever model we have has better assume that there is filtering by default in the gateway. The debate should then go on the possible ways to bypass that filtering. So the answer to the questions would be:

1) Assume that there is stateful filter somewhere in the network, because we cannot anymore stop it than stop the rain from falling. (On the other hand, the IETF should not encourage rain to fall and routers to meddle with traffic.) As a corollary, assume that there need to be a way to empower all applications.

2a) The decision to empower applications rightly belong to the user. The user should make a conscious arbitration between the benefits derived from the application, and the exposure created by running that application. Whether the application uses its own code to achieve that or whether it is built using system components is irrelevant. As a matter of fact, modern operating systems incorporate built-in firewalls and can control which applications are exposed to the network, or not. In any case, the IETF should not be concerned with the internal architecture of end systems, and should not engage in a debate on the split of functions between application, OS, libraries, host firewalls and other common services.

2b) The solutions that do work well in practice, like STUN and Teredo, are those that do not require any explicit signaling between the end system and the gateways or firewalls. Explicit signaling has a mediocre record of working when the system is directly connected to the gateway -- UPNP, for example, ends up working in maybe two thirds of such deployments. Explicit signaling just does not work when the router is several hops away. If the problem is "how to cross stateful filtering routers", the solution has to be "create state", probably by sending sacrificial packets along the path in order to "open the filters".

3) Yes, there should be an option for hosts to signal that they have implemented their own "internal firewall", and would rather not use the services of the router. In the design team discussions, two options where raised to that effect. One was to allow IPSEC through by default, with the reasoning that a host implementing IPSEC also has its own internal firewall. The other was to allow communication with privacy addresses, with the reasoning that privacy addresses are randomized, and thus are least likely to be attacked by Internet scanning worms.

-- Christian Huitema

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 6 Jan 2008 00:27:55 +0100

On 4 jan 2008, at 19:28, Christian Huitema wrote:

> 2a) The decision to empower applications rightly belong to the user.  
> The user should make a conscious arbitration between the benefits  
> derived from the application, and the exposure created by running  
> that application. Whether the application uses its own code to  
> achieve that or whether it is built using system components is  
> irrelevant.

I don't think it's always irrelevant. For instance, I suggested at one  
point that a host would indicate its desire to be unfirewalled through  
an neighbor discovery option. There is no reasonable way for  
applications to use such a mechanism.

Also, it could be considered undesirable to have individual  
applications do things like this without oversight from "the system".

> In any case, the IETF should not be concerned with the internal  
> architecture of end systems, and should not engage in a debate on  
> the split of functions between application, OS, libraries, host  
> firewalls and other common services.

Well, obviously someone has to do it, because otherwise there is no  
standard way for applications to ask for these services.

> 2b) The solutions that do work well in practice, like STUN and  
> Teredo, are those that do not require any explicit signaling between  
> the end system and the gateways or firewalls. Explicit signaling has  
> a mediocre record of working when the system is directly connected  
> to the gateway -- UPNP, for example, ends up working in maybe two  
> thirds of such deployments. Explicit signaling just does not work  
> when the router is several hops away. If the problem is "how to  
> cross stateful filtering routers", the solution has to be "create  
> state", probably by sending sacrificial packets along the path in  
> order to "open the filters".

You're basically saying that the situation where there is no need for  
a protocol because systems can trigger the desired action unilaterally  
is preferable over the situation where two systems need to cooperate  
so there must be a protocol between them to accomplish this. That is a  
truism.

However, it doesn't apply here. There is simply no reasonable way to  
get traffic past a stateful firewall without the cooperation from the  
firewall. Also, unlike the IPv4 situation, we actually do get to think  
about this before there are millions of boxes from dozens of vendors  
out there.

> One was to allow IPSEC through by default, with the reasoning that a  
> host implementing IPSEC also has its own internal firewall.

My thinking here was that IPsec is specifically designed to reject  
unknown traffic and IKE/ISAKMP is specifically designed to operate in  
a hostile environment, so no additional firewalling is required.

---

From: Leo Vegoda <[email-masked]>
Date: Mon, 7 Jan 2008 09:26:26 +0100

On 4 Jan 2008, at 16:32, Shane Kerr wrote:

[...]

> /48 at a time, they may be faced with resource scarcity, and not have

On the whole, ISPs assign addresses for the period during which you  
pay them for a service. I doubt there will be any resource scarcity  
leading to revoked assignments while end-sites continue to pay for  
service from their ISPs. I don't think an alternative where random / 
48s move around between different ASs is a good model to promote.

Regards,

Leo

---

From: Shane Kerr <[email-masked]>
Date: Mon, 7 Jan 2008 10:38:23 +0100

On Mon, Jan 07, 2008 at 09:26:26AM +0100, Leo Vegoda wrote:
> >>11. Do we expect ISPs to provide reachability for a new and old
> >>prefix concurrently when changing prefixes or do ISPs provide
> >>long-time stable prefixes to IPv6 customers? If "no" on both, then
> >>how do we avoid disconnected sessions on prefix changes?
> >
> >Personally I like the model of providing reachability for both old
> >and new during renumbering. But... since an ISP only gets a few
> >thousand /48 at a time, they may be faced with resource scarcity,
> >and not have the space (GROAN!!!!).
> 

Well, the scenerio I'm thinking of does not involve a new AS. For
example, if your ISP opens a new site closer to your home, they may
want to route your connectivity into the new site, which could very
well involve renumbering.

So, Ilijtsch's question is important.

I am told that today the best way to do such a migration in IPv4 is
for ISPs to pick a time to move customers to the new numbers, and use
ever-decreasing DHCP lease times to insure that users renumber as
close to that time as possible - but not to overlap the address spaces
for any time.

IPv6 was designed to be able to allow end hosts to more-or-less
painlessly migrate between addresses. I don't know if this has been
widely tested (I suspect not). Plus, unless there is some clever work
on both the ISP and customer side, a renumbering can affect the end
site.

Again, my preference is to support both old and new addresses during a
renumbering, but I don't know if IPv6 is mature enough technology, or
if we have enough space after squandering so much of it.

--
Shane

---

From: Leo Vegoda <[email-masked]>
Date: Mon, 7 Jan 2008 12:06:15 +0100

On 7 Jan 2008, at 10:38, Shane Kerr wrote:

[...]

> well involve renumbering.

Ah, now I understand.

> close to that time as possible - but not to overlap the address spaces

If I was working for an ISP I'd prefer the method that would result in  
the fewest support calls. My experience is that RIRs are happy to give  
ISPs a bit of slack during a renumbering process if it results in more  
efficient address space usage in the medium term.

Address scarcity in this context shouldn't be a worry.

Regards,

Leo

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Mon, 7 Jan 2008 18:11:41 +0200

> default, but applications can request incoming sessions is what we

It is pretty clear at this point, that there will be stateful firewalling in 
many SOHO deployments. As such, we clearly need a hole opening mechanism. Or 
then we close the IETF transport area, and declare that there shall only be 
UDP and client-to-server TCP from now on :o

What I am really worried however is, if we don't clearly state HOW stateful 
firewalling should be done, or if we do, but vendors ignore us, we'll end up 
with the same issues as with IPv4+NAT:
- UDP working "client-to-client", but with battery-hungry short refresh 
timers,
- TCP only works client-to-server only (so client-to-client congestion control 
is non-existent at the transport layer),
- everything else does not work reliably.

> rather than be signalled directly from applications to the CPE?

I don't understand the question. The OS will always be sitting between the 
application and the CPE in any case, by virtue of providing the socket API, 
the network stacks and drivers, and possibly the local firewall.

> doesn't require any filtering?

It would probably be useful in some scenarios.

> of broadband equipment, or is a provisioning solution where this isn't

The CPE should preserve options it does not know, I suppose, for the sake of 
extensibility. OTOH, I expect many end devices will stick to ICMPv6 autoconf.

> 5. Can we assume the presence of DHCPv6 prefix delegation in CPEs?

On the upstream side, I suppose so.
On the downstream side, it would be needed for chaining of CPEs. We'd probably 
need multicast proxying as well for the same reason (see also James 
architecture proposal). 

> 6. Can we assume the presence of DHCPv6 address assignment in clients?

No.

> It's not available in most of them now, so how would we get to such a

I think we won't get to such a state that we could assume pervasive DHCPv6. 
What's wrong with giving ICMPv6 autoconf for end nodes anyway?

> router functionality a reasonable one?

Maybe it depends on the definition of CPE. There are non-routing modems, and 
there are SOHO routers without modems, and I assume they'll continue to 
exist.

> = no and 7 = yes? If not, then what?

Maybe if the end node is dumb and does not do DHCPv6, it could be required to 
need a CPE? I suppose general purpose computers have or will have DHCPv6 at 
some point. Not sure about, say Apple though.

(...)
> 16. How do we expect customer devices to enter into the DNS?

I am not sure we need DNS here.

> 18. Should IPv6 hosts be prepared to operate without a working reverse

They'd better do it, because there are deployed IPv6 networks without reverse 
DNS. Especially if the host uses privacy addresses.

-- 
Rémi Denis-Courmont
http://www.remlab.net/

---

From: james woodyatt <[email-masked]>
Date: Mon, 7 Jan 2008 10:54:16 -0800

> - everything else does not work reliably.

I concur.

> the network stacks and drivers, and possibly the local firewall.

This is already happening in the OS for IPv4/NAT.  That's where the  
NAT-PMP and UPnP IGD support is coded.  Application developers aren't  
rolling their own implementations of those protocols.  They're  
relying on the OS to provide them with APIs.

I see no reason to burden application developers with new  
requirements just to use IPv6 instead of IPv4/NAT.

> It would probably be useful in some scenarios.

No.  No, no, no.  Firewalls don't care what nodes think are their  
filtering requirements.  Policy is decided by the firewall  
administrator and enforced in the network middlebox.

The *only* reason for nodes to signal anything to a firewall is to  
give it a chance to be more transparent than it would otherwise be  
without the signaling.  Nodes can tell firewalls things like "I'm  
accepting arbitrary incoming flows at this network address [these  
transport addresses]."  That allows firewalls to get out of the way  
*IF* policy allows.  Without such signaling, no policy is possible  
and stateful firewalls must resort to blocking all incoming flows  
because they don't know which are solicited and which are not.

>> 5. Can we assume the presence of DHCPv6 prefix delegation in CPEs?

No.  Or, at least, not yet.

No.

> What's wrong with giving ICMPv6 autoconf for end nodes anyway?

Nothing.

> some point. Not sure about, say Apple though.

Mac OS X does not support DHCP6.  I can't say when or if it ever will.

> I am not sure we need DNS here.

It's a luxury item.

> DNS. Especially if the host uses privacy addresses.

We're going to need privacy addresses once IPv6 worm authors start  
harvesting target addresses from server logs and honeypots.

--
james woodyatt <[email-masked]>
member of technical staff, communications engineering

---

From: Christian Huitema <[email-masked]>
Date: Mon, 7 Jan 2008 13:01:49 -0800

> administrator and enforced in the network middlebox.

In a "home" environment, and in fact in most SOHO environments, there is no "firewall administrator". You have at best the "reluctant administrator", i.e. the one family member charged with rebooting the router when it fails. This is the main difference between "managed" and "unmanaged" environments.

In an unmanaged environment, you really cannot assume that the policy is decided by the firewall administrator. In practice, it is placed in the box by the firewall manufacturer, and mostly left untouched by the users. So, if we assume that the firewalls will be closed by default, we can as well assume that there never will be any incoming TCP connection in the home.

Now, that may be a fine assumption. At least, it is a predictable environment. We can start from there, implement all P2P services over UDP, and design some variant of STUN to open the holes. That may well be more productive than making stern sounding statements in IETF groups...

-- Christian Huitema

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 08 Jan 2008 10:18:07 +1300

> Mac OS X does not support DHCP6.  I can't say when or if it ever will.

I predict extremely strong demand for this from corporate and campus
customers.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 08 Jan 2008 10:20:40 +1300

On 2008-01-07 22:38, Shane Kerr wrote:
> renumbering, but I don't know if IPv6 is mature enough technology,

See RFC 4192.

> or

Huh? The canonical model is for multiple prefixes per site;
there isn't any issue about it.

     Brian

---

From: james woodyatt <[email-masked]>
Date: Mon, 7 Jan 2008 14:20:02 -0800

On Jan 7, 2008, at 13:18, Brian E Carpenter wrote:
> [I wrote:]
> I predict extremely strong demand for this from corporate and  
> campus customers.

I'd say that's an entirely sensible prediction— if you were to ask me  
while I have a pint in my hand.  I just can't say anything  
authoritative about future product features.  What we have today is  
what we have today.

---

From: james woodyatt <[email-masked]>
Date: Mon, 7 Jan 2008 14:43:10 -0800

On Jan 7, 2008, at 13:01, Christian Huitema wrote:
>
> In a "home" environment, and in fact in most SOHO environments,  
> there is no "firewall administrator". You have at best the  
> "reluctant administrator", i.e. the one family member charged with  
> rebooting the router when it fails. This is the main difference  
> between "managed" and "unmanaged" environments.
>
> In an unmanaged environment, you really cannot assume that the  
> policy is decided by the firewall administrator. In practice, it is  
> placed in the box by the firewall manufacturer, and mostly left  
> untouched by the users. [...]

All quite true.  It still doesn't change the fact that firewalls are  
where policy is decided and enforced, and nodes should only be  
required to notify firewalls of their application listeners, and  
*not* to request permission for their applications to listen.

> So, if we assume that the firewalls will be closed by default, we  
> can as well assume that there never will be any incoming TCP  
> connection in the home.
>
> Now, that may be a fine assumption.

I don't believe for a second that UPnP IGD won't be extended to  
support IPv6 filter control in addition to IPv4/NAT control.  There  
will be incoming TCP/IPv6 connections to the home environment just  
like there are incoming TCP/IPv4/NAT connections today.  The question  
is whether there will be an IETF recommendation for how they will get  
there over IPv6, or if IETF will continue to pretend like it isn't a  
problem we should be thinking about— just like we have with the IPv4/ 
NAT case for lo these many years.

If IETF wants to embrace UPnP IGD for IPv6, then I would call that an  
improvement over the status quo ante.  Not very much of an improvement 
— mind you—but it's Better Than Nothing.  Let me ask this question  
again to the whole group: does anyone know if UPnP Forum intends to  
publish their specifications for IGD/IPv6 under terms that IETF can  
accept as a standards track document?  If so, when?

---

From: Tim Chown <[email-masked]>
Date: Tue, 8 Jan 2008 13:56:31 +0000

> there isn't any issue about it.

For some tests run a couple of years ago, see:
	http://www.6net.org/publications/deliverables/D3.6.2.pdf

For a small enterprise, the RFC4192 process basically worked with
the OSes and platforms we used, but that was without any use of DHCPv6
(all RAs/autoconf).

The pain with renumbering lies outside the 'basic' network layer
reconfigurations of RFC4192 though.

-- 
Tim

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 8 Jan 2008 17:18:14 +0100

> NAT-PMP and UPnP IGD support is coded.  Application developers  
> aren't rolling their own implementations of those protocols.   
> They're relying on the OS to provide them with APIs.

I'm not sure if this is universally true. For instance, I believe that  
Azureus (popular BitTorrent client) has its own uPnP/NAT-PMP code.

> requirements just to use IPv6 instead of IPv4/NAT.

It would be good if the OS could determine the needs of applications  
and act on those without explicit signalling from the app, yes.

> administrator and enforced in the network middlebox.

See Christian's comment.

> harvesting target addresses from server logs and honeypots.

Hm, how disposable can we make addresses before the baby goes out with  
the bath water?

But more importantly for this discussion: do we assume that these  
temporary addresses don't get DNS names? I know some people want DHCP  
servers to handle setting up DNS entries. It's not completely  
impossible to do this: you can have a host ask for a specific address  
with an IA option and then the DHCPv6 server still gets to see the  
address even though the host generated it. But there are other ways to  
do it, too. I like the dynamic DNS approach, although this needs to be  
handled carefully because Windows' DDNS implementation is pretty much  
a DDoS attack against the root servers. The forward DNS isn't a big  
problem, although this may need some setting up if the ISP doesn't  
handle it. Reverse should be easy: just let address X change the DNS  
entry for address X. But as an ISP, I would prefer to simply delegate  
the reverse DNS to the user's server for reduced headaches.

---

From: "Bound, Jim" <[email-masked]>
Date: Tue, 8 Jan 2008 16:44:29 +0000

Response to Iljitsch mail below.

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Iljitsch van Beijnum
> Sent: Friday, January 04, 2008 7:35 AM
> To: IPv6 Operations
> Subject: CPEs
>
> When I say "CPE" that can both mean a cable/DSL modem, a home
> router with integrated cable/DSL modem or a home router with
> no modem functionality. I'll call them CPE(m), CPE(r) or
> CPE(rm) where appropriate. If they're managed by the ISP I
> may add -ISP, if they're managed by the end-user/consumer I
> may add -USER. Note that all of this applies to consumer
> installations.

Well defined.

>
> First, let me start with a few sentences on my philosophy in
> this area and then a list of issues that we need to figure
> out so the industry can move forward.
>
> CPE philosophy
> --------------
>
> Because broadband consumers span the gamut from completely
> ignorant about even the most superficial technical issues to
> people who actually build those CPEs, the most important
> thing is that a CPE can address all reasonable use cases
> along that gamut. In other words: an expert user shouldn't be
> forced to live with what's best for that granny who doesn't
> even have a PC but does have some IP enabled devices such as
> picture frames or sewing machines, but on the other hand, the
> granny shouldn't be forced to become an expert.

I agree.

>
> What this means is that the defaults are such that non-expert
> users get the tradeoff between security, usability and other
> aspects that is most appropriate (which would be the default
> settings), but experts get to override these defaults. At the
> very least, it MUST be possible to make the CPE act transparently.

I agree,

>
> Security
>
> As for security: these days, any IP device MUST be ready to
> be connected to a hostile network, which includes the open internet.
> However, because this wasn't true in the past and because
> removing a layer of "security" is scary, it's not possible to
> market CPEs that don't do any filtering. This means that
> there must be filtering, but since it doesn't do anything
> useful in practice and it does get in the way, this filtering
> must be the minimum that will be accepted by the market. That
> would almost certainly be the level of filtering that is de
> facto provided in today's IPv4 CPEs, which is: outgoing
> sessions and related return traffic is allowed (stateful
> filtering) and applications get to open up TCP/UDP ports for
> incoming traffic.

One filter I believe will become required will be end-to-end IPsec and it is just let through, but for corporate and government markets there could become decrypt capability supporting the media line rates without performance degradation, and I believe we will see this form of DPI in the home CPE too.  The other data point I see happening is as peer-2-peer moves further users will want the option to encrypt at their device to an application function and other devices, thus the filter is if IPsec and secure (big question for sure) then let it pass. Ergo no filters at all for this case.  The firewall becomes a security manager with far more intelligence than today.

>
> Now obviously it's possible to argue that this isn't a good
> way of filtering (in both directions, it can be too much or
> too little), but since that is what you get with pretty much
> any current CPE those discussions are largely moot. The only
> changes that are possible are those that BOTH improve
> security AND usability at the same time. Any change that
> improves one over the other will be seen as unacceptable by one camp.

The above is key per Fred's call to action that started this thread and to determine what we in the IETF can provide to support the Alain new social contract do we only consider today or do we think out of the box a bit too?  Also I dc not believe the IETF can provide a deployment exact case for the new social contract that the market must decide and then implement all we can do is provide the ops tools or possibly new protocol work to assist it in the IETF.  We need to keep our scope correct and responsibility within the IETF for what we do as an SDO correct.

>
> Transition
>
> Ideally, a CPE will provide both IPv4 and IPv6 service to
> hosts connected to it, regardless of whether the ISP provides
> IPv4, IPv6 or both. So that probably means: regular IPv4
> operation, native IPv6, 6to4, Teredo, NAT-PT... It would be
> even better if IPv4 hosts behind the CPE could make use of
> IPv6 services and the other way around.

Again we cannot force this but a phenomena for IPv6 that needs to change is that the provider needs to provide dual-stacked services not just IPv4 or IPv6 native only.  The question is do we in v6ops assume the provider provides dual stack services as an assumption for the work threads Fred suggested?

>
> Multiple CPEs
>
> Obviously if there is a CPE(m) then it should also be
> possible to add a CPE(r), but users may have reasons to have
> multiple CPE(r)s, possibly connected in parallel to a CPE(m)
> but having one CPE(r) connect to the LAN side of another
> CPE(r) would also be a possibility, and even the only
> possible option if there is a CPE(mr). Although security
> policies may prohibit certain applications to work across a
> CPE(r), service discovery and addressing should be
> transparent within the entire site.

I think it is inevitable that CPE 'r' and 'm' because of the DPI end-to-end trust scenario I describe above which I believe is a requirement for the market.  I am not sure addressing can in reality be transparent but it would be nice if that were true.

>
> Questions
> ---------
>
> Security
>
> 1. Do we all agree that a model where there is stateful
> filtering by default, but applications can request incoming
> sessions is what we should aim for?

I believe the default will be statefull but option should exist to turn off the default for many reasons in addition to the one listed above.

>
> 2. Or should the opening up of incoming ports go through the
> OS, rather than be signalled directly from applications to the CPE?

The default should go through the OS as the default I am thinking peformance and transparency as the reasons.

>
> 3. Should a host have the option of signalling to a CPE that
> it doesn't require any filtering?

Absolutely yes or as I state above permit IPsec to pass through.

>
> Address provisioning
>
> 4. Is implementing DHCPv6 snooping and option insertion,
> similar to what currently happens with DHCP for IPv4, a good
> option for vendors of broadband equipment, or is a
> provisioning solution where this isn't necessary preferable?

I am not parsing entirely why this is a valid question for CPE edge, but can see it as server in the home?  But, for the home environment I strongly suggest that stateless IPv6 be used so can you re-phrase the question at least for me?  Thanks.

> 5. Can we assume the presence of DHCPv6 prefix delegation in CPEs?

No. That should not be assumed at all.  We must consider all the options.  See renumbering RFC 4192.

> It's not available in most of them now, so how would we get
> to such a state and how soon?

For the home or mobile devices I don't think so stateless will be cheaper to build/ship and configure, and deploy for Mobile IPv6 as one example.  DHCPv6 is for enterprise networks and ISPs is my view and I believe a requirement for all clients in those market sectors today for many reasons.

>
> 7. Is the model where there is a CPE with modem functionality
> but not router functionality a reasonable one?

I don't think so and this should be transparent to v6ops mission for this thread is my input.

>
> 8. Do we want to ISPs to provide RAs to customers in the case
> where 6 = no and 7 = yes? If not, then what?

I think this is not our business RAs are RAs we must assume CPE devices have the intelligence to process any RA.

> 9. If 8, then what is the value of the M and O bits?

These would only be valid for CPE devices if DHCPv6 prefix delegation is used and though I think that will happen we should not assume this as the default but cover both.  I won't respond here on the M and O context or indirection as that could be huge rat hole at this point.

>
> 10. If 5 and a user adds more than one routing CPE, how does
> the prefix delegation work? The "first" routing CPE requests
> a prefix from the ISP and then provides sub-prefixes to the
> other CPE(r)s, or does each CPE get a prefix from the ISP? In
> the latter case, how do CPE(r)s know what routes to install
> for prefixes held by other CPE(r)s within the site?

We must define all possibilities and use cases and then the market and products will decide our job is to cover all scenarios.

>
> 11. Do we expect ISPs to provide reachability for a new and
> old prefix concurrently when changing prefixes or do ISPs
> provide long-time stable prefixes to IPv6 customers? If "no"
> on both, then how do we avoid disconnected sessions on prefix changes?

Both will happen our job is to define the ramifications of both scenarios.  That means we dive into the technical details on how to do this as part of the work.

> addresses clashing with that of other customers?

I really hope we don't have to work on this in v6ops or in the IETF this is a standard problem regardless of IPv6 or IPv4?  Or am I missing the specific IPv6 issue?  Thanks.

> 13. How many devices are allowed to connect to a CPE(m)?

Absolutely none of the IETF's business.  Sorry this is a product feature set for the vendors.

>
> 14. What kind of addressing is used between the ISP and the
> first CPE(r)? Global customer specific, global shared between
> customers, link local only?

Again all will be used we need to define what the technical details are for each case if we want to take on that much work.

> Should hosts and CPEs ignore their own DAD packets when they
> loop back to them?

No one ignores DAD that is required to use DAD per the specs.

> 16. How do we expect customer devices to enter into the DNS?

As they do today.

> 17. If the answer to 16 is dynamic DNS updates, how does the

DNSSEC or IPsec or other methods but this would be good to identify the options.

>
> 18. Should IPv6 hosts be prepared to operate without a
> working reverse DNS entry?

Sure this is done today with IPv4.

>
> Third party devices
>
> 19. How do users authorize third-party devices (ranging from
> gas meters to set top boxes) use of their broadband connection?

Sorry not the IETF's  business.

>
> 20. How can third party devices be prevented from observing
> both data traffic and service discovery?

This is done through various means today but falls under reverse-intrusion-detection of the devices. Not clear this is v6ops business?

> 21. How can third party device traffic be limited and/or given QoS?

OK this begins to boil the ocean for the list of things to do and QoS should be dealt with out of v6ops is what we should say in v6ops.

Nice Job on this Iljitsch thanks
/jim

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 8 Jan 2008 17:44:03 +0100

On 7 jan 2008, at 23:43, james woodyatt wrote:

> like there are incoming TCP/IPv4/NAT connections today.  The  
> question is whether there will be an IETF recommendation for how  
> they will get there over IPv6, or if IETF will continue to pretend  
> like it isn't a problem we should be thinking about— just like we  
> have with the IPv4/NAT case for lo these many years.

> If IETF wants to embrace UPnP IGD for IPv6, then I would call that  
> an improvement over the status quo ante.  Not very much of an  
> improvement— mind you—but it's Better Than Nothing.  Let me ask this  
> question again to the whole group: does anyone know if UPnP Forum  
> intends to publish their specifications for IGD/IPv6 under terms  
> that IETF can accept as a standards track document?  If so, when?

Hm, doesn't this protocol have a worse-than-average track record  
security-wise? I even remember having to update my computer because of  
this fairly recently...

The IETF has some experience in designing middlebox management  
protocols and IPv6 is a core IETF technology. Does it make sense to  
outsource something like this?

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 8 Jan 2008 18:04:56 +0100

[Response to other issues will follow]

On 8 jan 2008, at 17:44, Bound, Jim wrote:

> One filter I believe will become required will be end-to-end IPsec  
> and it is just let through, but for corporate and government markets  
> there could become decrypt capability supporting the media line  
> rates without performance degradation, and I believe we will see  
> this form of DPI in the home CPE too.  The other data point I see  
> happening is as peer-2-peer moves further users will want the option  
> to encrypt at their device to an application function and other  
> devices, thus the filter is if IPsec and secure (big question for  
> sure) then let it pass. Ergo no filters at all for this case.  The  
> firewall becomes a security manager with far more intelligence than  
> today.

There has been some talk about letting all IPsec through regardless of  
statefulness, but I don't remember a clear conclusion.

However, this does seem to be an attractive option in the sense that  
it allows for a way to have peer-to-peer communication without giving  
up security. It would probably still need some selling to some  
security-conscious groups, but a good argument there would be that  
there is no reasonable way that an attacker could get anywhere without  
first negotiating a security association, but if we don't implement  
this, that simply means applications will use less secure peer-to-peer  
mechanisms.

---

From: "Bound, Jim" <[email-masked]>
Date: Tue, 8 Jan 2008 17:11:18 +0000

ack I concur with you on the issue you articulate well below.
thanks
/jim

> From: Iljitsch van Beijnum [mailto:[email-masked]]
> Sent: Tuesday, January 08, 2008 12:05 PM
> To: Bound, Jim
> Cc: IPv6 Operations
> Subject: Should CPE allow all IPsec through? Was: Re: CPEs
>
> > One filter I believe will become required will be
> end-to-end IPsec and
> > it is just let through, but for corporate and government
> markets there
> > could become decrypt capability supporting the media line rates
> > without performance degradation, and I believe we will see
> this form
> > of DPI in the home CPE too.  The other data point I see
> happening is
> > as peer-2-peer moves further users will want the option to
> encrypt at
> > their device to an application function and other devices, thus the
> > filter is if IPsec and secure (big question for
> There has been some talk about letting all IPsec through
> regardless of statefulness, but I don't remember a clear conclusion.
>
> However, this does seem to be an attractive option in the
> sense that it allows for a way to have peer-to-peer
> communication without giving up security. It would probably
> still need some selling to some security-conscious groups,
> but a good argument there would be that there is no
> reasonable way that an attacker could get anywhere without
> first negotiating a security association, but if we don't
> implement this, that simply means applications will use less
> secure peer-to-peer mechanisms.
>

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Tue, 8 Jan 2008 20:06:02 +0200

> security-wise? I even remember having to update my computer because of

As much as I am NOT a fan of UPnP, I believe the security issues are either:
- implementation errors,
- limits of the on-link trust model.

I would not consider security as the main disadvantage of UPnP. Of course, we 
can do better, for instance using a challenge-response scheme to validate the 
address ownership. And we may want to support learning of the firewall 
gateway address using DHCPv6 so that it can be used in network topology (I am 
thinking about wide area radio networks in particular) without multicast.

> protocols

But the track record is deployment-wise worse than that of UPnP IGD.

I would much rather have an IETF protocol à la ALD for IPv6 firewall control, 
than UPnP IGD 2.0. But I'd also rather have IGD 2.0 than nothing, if vendors 
decide to go for IGD 2.0. I guess that's what James meant as well.

> and IPv6 is a core IETF 
> Does it make sense to outsource something like this?

We cannot ban other entities from doing it, can we?

-- 
Rémi Denis-Courmont
http://www.remlab.net/

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 8 Jan 2008 12:00:38 -0800

> this, that simply means applications will use less secure 
> peer-to-peer mechanisms.

Or that those less secure peer-to-peer applications will run
over UDP/500 and protocol 50.

-d

---

From: james woodyatt <[email-masked]>
Date: Tue, 8 Jan 2008 14:10:00 -0800

On Jan 8, 2008, at 12:00, Dan Wing wrote:
>
> Or that those less secure peer-to-peer applications will run over  
> UDP/500 and protocol 50.

Yes, but I don't think that's where the resistance to the idea of  
allow udp/500 and proto/50 to pass from exterior to interior by  
default originates.  I think the resistance originates from the very  
simple (and stupid) expectation that the default rules for all  
firewalls is to disallow unsolicited traffic from the exterior to  
reach interior nodes.  Making an exception for udp/500 and proto/50  
involves *thinking* about why those packets are "safe" and not any  
others.  Thinking is hard and exceptions are complicated, making  
everything difficult to understand.

That said, I will note that the current CPE simple security I-D  
recommends that unsolicited udp/500 and proto/50 be allowed to pass  
from the exterior to interior nodes by default.  (The specific  
recommendations are R16 and R17.)

Is there a consensus in the working group that these recommendations  
should be reversed?

---

From: Fred Baker <[email-masked]>
Date: Tue, 8 Jan 2008 17:07:33 -0800

Hmm. Dumb question.

It seems to me that there is an excellent attack in this. If I know  
that a given address (perhaps found in the envelope of an email I  
have observed) is populated and attempt to open an IPsec session, I  
consume some amount of computing resource. If I do that a lot, I can  
consume a large quantity of computing resource. I can obviously also  
consume other resources including bandwidth of various kinds.

There are some mechanisms that we use in mail filtering, in which we  
identify a relatively small set of IP addresses that are highly  
likely to be business partners on matters of business, and with all  
others we apply some level of prejudice - known nogoodnicks have  
their SYN ignored, and unknowns get a higher level of scrutiny than  
common business partners. My IT department tells me that "ignoring  
SYNs" dumps about 75% of traffic to Cisco, and the additional  
scrutiny dumps over 80% of the rest before it ever gets to the MUA. I  
in my case the final MUA (the beysian filter in my email client) is  
still dumping an average of 58 emails a day, which if the IT folks'  
statistics right means that they are sheilding me from something on  
the order of 2000/day. I can tell you of days (SOBIG.F comes to mind)  
in which I received over 6000 emails, mostly junk, in a matter of a  
couple of hours, so that doesn't seem too far out in the weeds.

I'm envisioning the same basic attack, but in setting up IPsec  
sessions. I wonder what the best approach would be. I have little to  
no expectation that my Infosec department is going to even *think*  
about opening the firewall to let that class of attack through - they  
would view the suggestion as somewhere between idiocy and lunacy. 58  
spurious sessions getting through and not being about to authenticate  
with my system in the course of a day is one thing (still high, but  
survivable); a focused attack of multiple thousands of sessions per  
day ongoing 24X7 is simply not on.

How would you suggest preventing that attack from ever getting to the  
host and retain the ability to connect into the host from outside the  
domain?

The thing that comes to mind depends on frequently-changed privacy  
addresses - if I use a previously-unused privacy address for every  
minute during which I open new sessions and let old ones expire,  
pulling addresses out of emails won't be much of an attack surface.  
But that doesn't address any matter in which the host is legitimately  
expecting to be contacted from outside its domain, and it still  
leaves the attack on the router on that LAN.

On Jan 8, 2008, at 9:04 AM, Iljitsch van Beijnum wrote:

>> and it is just let through, but for corporate and government  
>> markets there could become decrypt capability supporting the media  
>> line rates without performance degradation, and I believe we will  
>> see this form of DPI in the home CPE too.  The other data point I  
>> see happening is as peer-2-peer moves further users will want the  
>> option to encrypt at their device to an application function and  
>> other devices, thus the filter is if IPsec and secure (big  
>> question for sure) then let it pass. Ergo no filters at all for  
>> this case.  The firewall becomes a security manager with far more  
>> intelligence than today.
>
> There has been some talk about letting all IPsec through regardless  
> of statefulness, but I don't remember a clear conclusion.
>
> However, this does seem to be an attractive option in the sense  
> that it allows for a way to have peer-to-peer communication without  
> giving up security. It would probably still need some selling to  
> some security-conscious groups, but a good argument there would be  
> that there is no reasonable way that an attacker could get anywhere  
> without first negotiating a security association, but if we don't  
> implement this, that simply means applications will use less secure  
> peer-to-peer mechanisms.
>

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 9 Jan 2008 00:21:17 +0100

> The above is key per Fred's call to action that started this thread  
> and to determine what we in the IETF can provide to support the  
> Alain new social contract do we only consider today or do we think  
> out of the box a bit too?  Also I dc not believe the IETF can  
> provide a deployment exact case for the new social contract that the  
> market must decide and then implement all we can do is provide the  
> ops tools or possibly new protocol work to assist it in the IETF.   
> We need to keep our scope correct and responsibility within the IETF  
> for what we do as an SDO correct.

The way I see it, we pretty much have all the protocols that we need.  
We probably need one or two additional ones, but at this stage, new  
protocols should be the exception rather than the rule. What we're  
missing is a deployment model, which is something close to Alain's  
social contract. With IPv4, CPE vendors have a fairly good handle on  
what to expect from ISPs, and ISPs know what to expect from their  
customer's hosts and CPEs. With IPv6, that's not the case, and the  
fact that we expect more than a single address to be given out to a  
customer and we have several ways to provision these addresses defined  
make this more complicated than with IPv4.

I'm pretty sure the IETF doesn't have all the answers here, but I  
don't see any other organization stepping in, so I guess we'll have to  
come up with something. Obviously that must be something that makes  
sense in the grand scheme of IETF/IPv6 things, and it must be  
something that the vendors that come to the IETF support. That's the  
part we can do in v6ops for the most part. But we also need ISPs and  
probably organizations like the DSL Forum to come on board. I'm not  
100% how we can accomplish that, but I think it will help if we can at  
least agree on a good number of issues here. A wide range of  
viewpoints is represented within the IETF, so rough consensus here  
probably means that we have something fairly solid.

> Again we cannot force this but a phenomena for IPv6 that needs to  
> change is that the provider needs to provide dual-stacked services  
> not just IPv4 or IPv6 native only.  The question is do we in v6ops  
> assume the provider provides dual stack services as an assumption  
> for the work threads Fred suggested?

There is a difference between dual stack services and dual stack  
network access. (Hopefully improved) NAT-PT does the former but not  
the latter. I'd say we should probably not assume dual stack from the  
ISP because being able to support a single stack model makes the  
solution stronger.

> Absolutely yes or as I state above permit IPsec to pass through.

It seems we have yet to reach consensus, rough or otherwise, on this  
point...

> I am not parsing entirely why this is a valid question for CPE edge,  
> but can see it as server in the home?  But, for the home environment  
> I strongly suggest that stateless IPv6 be used so can you re-phrase  
> the question at least for me?  Thanks.

With IPv4 broadband aggregation equipment snoops DHCP and inserts an  
option that holds some kind of port identifier. Obviously something  
very similar can be done for DHCPv6, but if this is hard to implement,  
it may be useful to consider alternatives.

> I don't think so and this should be transparent to v6ops mission for  

Reason for the question: if ISPs insist on CPEs with modem and router  
functionality integrated, we can skip some issues (RAs from ISP to  
customer) but that means the ISP - CPE interface becomes more  
important because if it doesn't work right the user is left without  
recourse.

> These would only be valid for CPE devices if DHCPv6 prefix  
> delegation is used and though I think that will happen we should not  
> assume this as the default but cover both.  I won't respond here on  
> the M and O context or indirection as that could be huge rat hole at  
> this point.

If we don't address the M/O issue this means the CPE will have to  
initiate DHCPv6 prefix delegation always.

> I really hope we don't have to work on this in v6ops or in the IETF  
> this is a standard problem regardless of IPv6 or IPv4?  Or am I  
> missing the specific IPv6 issue?  Thanks.

It's not our issue, but it's something that could impact what we can  
and can't do. For instance, "link layer NAT" that was mentioned as a  
solution to this issue requires an ND ALG.

> feature set for the vendors.

It's more an ISP issue. If ISPs want this to be exactly one, vendors  
can build in logic that avoids problems when a user tries to connect  
multiple devices anyway.

> Again all will be used we need to define what the technical details  
> are for each case if we want to take on that much work.

I don't think anyone has a pressing need for this to be any particular  
way, they just want things to work. If we can recommend an optimal  
choice, that makes life simpler for everyone.

> No one ignores DAD that is required to use DAD per the specs.

I think the spec is unclear here. If I send a DAD ND packet out for my  
IPv6 address and I then receive such a packet also for my address, but  
it turns out that this was a copy of my own packet that looped back in  
a way that isn't obvious locally, then assuming the address is in use  
by someone else is not a good idea, because that limits layer 2  
topologies for no good reason. A simple check to see whether the  
source MAC address is the local MAC address can solve this.

> As they do today.

Today ISPs often just give a name to every address. If you get that  
address, you get the name that goes with it. However, in IPv6 you  
can't populate a /32 with 2^96 DNS names so this will have to happen  
in some other way.

> Sorry not the IETF's  business.

True. But the answer is important for us: if it's "put them in a  
separate subnet" this means the CPE model must support multiple subnets.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 9 Jan 2008 11:58:00 +0100

> consume other resources including bandwidth of various kinds.

Bandwidth is not an issue: under normal circumstances, the bandwidth  
between the ISP and the CPE is the bottleneck, so filtering by the CPE  
doesn't help against an attacker trying to fill up the available  
bandwidth.

I suppose it's possible that an attacker gets to use up CPU resources  
on the receiving system, but only if that system has an IPsec  
implementation that doesn't have any protection against that. There  
are two types of IPsec packets (well, three really): the UDP port 500  
IKE/ISAKMP protocol for setting up security associations and the data  
packets that are signed and/or encrypted (ESP or AH). If there has  
been no SA negotation and no SAs have been created through some other  
mechanism, the SPI in the ESP or AH packets won't match existing state  
so the packets will be rejected without much work on the receiver's  
part. So the only avenue of attack is IKE/ISAKMP. I'm not intimately  
familiar with that, but it seems to me that a non-server host would  
know who it wants to communicate with in advance, and reject any SA  
establishment attempts from entities that present identities that  
don't match those that are expected.

The spam analogy doesn't apply here for several reasons. First of all,  
spam goes to servers. If you are sitting at a random IPv6 address, the  
chances of a spammer contacting you to deliver spam are incredibly  
tiny. (I don't even think they bother to scan the IPv4 address space  
for places to deliver spam.) Apart from that, the reason that spam  
exists is that it gets seen by people and leads to separation of a  
user from his money in one way or another in a small percentage of all  
cases. Spurious IPsec packets don't do that.

The reason to not want IPsec to go through stateful firewalls can be  
either:

1. DoS risks
2. Penetration risks

I can't definitively say that those two risks round down to zero, but  
I am fairly confident that if there is a single protocol that we can  
allow through safely, IPsec is that protocol. It would be helpful to  
hear from IPsec experts and vendors of OSes with IPsec, though.

---

From: "Bound, Jim" <[email-masked]>
Date: Wed, 9 Jan 2008 17:08:42 +0000

Responses in line and I maintained only previous text that had to be kept from me for context in my view.

> We probably need one or two additional ones, but at this
> stage, new protocols should be the exception rather than the
> rule. What we're missing is a deployment model, which is
> something close to Alain's social contract. With IPv4, CPE
> vendors have a fairly good handle on what to expect from
> ISPs, and ISPs know what to expect from their customer's
> hosts and CPEs. With IPv6, that's not the case, and the fact
> that we expect more than a single address to be given out to
> a customer and we have several ways to provision these
> addresses defined make this more complicated than with IPv4.
>
> I'm pretty sure the IETF doesn't have all the answers here,
> but I don't see any other organization stepping in, so I
> guess we'll have to come up with something. Obviously that
> must be something that makes sense in the grand scheme of
> IETF/IPv6 things, and it must be something that the vendors
> that come to the IETF support. That's the part we can do in
> v6ops for the most part. But we also need ISPs and probably
> organizations like the DSL Forum to come on board. I'm not
> 100% how we can accomplish that, but I think it will help if
> we can at least agree on a good number of issues here. A wide
> range of viewpoints is represented within the IETF, so rough
> consensus here probably means that we have something fairly solid.

I think the above is a good thing for the IETF to and present an IETF deployment model.  But realize deployment models will be presented and preliminary ones have been by others such as the IPv6 Forum, ATIS, 3GPP, 3GA, WIMAX Forum, etc.  The IETF will a view and an important one but not the only one.

>
> >> Transition
>
> There is a difference between dual stack services and dual
> stack network access. (Hopefully improved) NAT-PT does the
> former but not the latter. I'd say we should probably not
> assume dual stack from the ISP because being able to support
> a single stack model makes the solution stronger.
>
> It seems we have yet to reach consensus, rough or otherwise,
> on this point...

Again there will be other views of deployment for security options in the market and one size does not fit all. IPsec end-to-end where all that is seen is the IP header causes no more attacks than currently but it does put pressure on routers, switches, servers+storage, CPE, and other edge devices to compete with the emerging high-end processor DPI vendors (both hardware and software) which will enable end-to-end IPsec quite well.  What we need to do for a deployment model is speak to it objectively without vendor agendas, market agendas, or other biases.

On DS or DS Services I strongly believe that the Provider edge must support IPv6 services over IPv4 in addition to domiant IPv6 native attached virtual links to support emerging use of IPv6.

> similar to
> >> of broadband equipment, or is a provisioning solution where this
> >> isn't necessary preferable?
>
> > but can see it as server in the home?  But, for the home
> environment I
> > strongly suggest that stateless IPv6 be used so can you
> re-phrase the
> > question at least for me?  Thanks.
>
> With IPv4 broadband aggregation equipment snoops DHCP and
> inserts an option that holds some kind of port identifier.
> Obviously something very similar can be done for DHCPv6, but
> if this is hard to implement, it may be useful to consider
> alternatives.

Seems like a hack to me because IPv4 cannot perform the same form of stateless autoconfiguration that IPv6 does inherently within the architecture and most implementations I am aware of and one of IPv6 significant technical advantages over IPv4 that has not been back ported to IPv4.  So why not use this advantage will be me position once we begin to work on the model if that is our v6ops course.

> > I don't think so and this should be transparent to v6ops
> mission for
> > this thread is my input.
>
> Reason for the question: if ISPs insist on CPEs with modem
> and router functionality integrated, we can skip some issues
> (RAs from ISP to
> important because if it doesn't work right the user is left
> without recourse.

True but I still think that is transparent to the modem and this is really how are RAs/RSs going to work for a home environment.

Important question is this work or model to be only for the home CPE end and not other target markets for IPv6 deployment?

> delegation
> > is used and though I think that will happen we should not
> assume this
> > as the default but cover both.  I won't respond here on the M and O
> > context or indirection as that could be huge rat hole at this point.
>
> If we don't address the M/O issue this means the CPE will
> have to initiate DHCPv6 prefix delegation always.

Agree and the default I would suggest is stateless unless the bits are set.

> It's not our issue, but it's something that could impact what
> we can and can't do. For instance, "link layer NAT" that was
> mentioned as a solution to this issue requires an ND ALG.

OK but that is truly ugly and I cannot see any reason for a link-layer NAT just implement device drivers to handle decap/encap/translation/exclusive-or-rehash etc. and don't break the IP Layer.  That way v6ops is transparent within a model.

> It's more an ISP issue. If ISPs want this to be exactly one,
> vendors can build in logic that avoids problems when a user
> tries to connect multiple devices anyway.

Yep but still not the IETFs business.

> I don't think anyone has a pressing need for this to be any
> particular way, they just want things to work. If we can
> recommend an optimal choice, that makes life simpler for everyone.

That is fair to make a recommendation but not standards-track but informational or BCP.

> >> Should hosts and CPEs ignore their own DAD packets when they loop
> >> back to them?
>
> IPv6 address and I then receive such a packet also for my
> address, but it turns out that this was a copy of my own
> packet that looped back in a way that isn't obvious locally,
> then assuming the address is in use by someone else is not a
> good idea, because that limits layer 2 topologies for no good
> reason. A simple check to see whether the source MAC address
> is the local MAC address can solve this.

OK but that is just doing proper well behaved programming this is possibly good input to the 6MAN WG as a note.
> Today ISPs often just give a name to every address. If you
> get that address, you get the name that goes with it.
> However, in IPv6 you can't populate a /32 with 2^96 DNS names
> so this will have to happen in some other way.

Hmmm can you say more I don't see this limitation in DNS fields defined?  Thanks.

> True. But the answer is important for us: if it's "put them
> in a separate subnet" this means the CPE model must support
> multiple subnets.

Here I must disagree.  There is a difference between IP config for example multiple subnets and then securing devices.  I don't believe many now agree securing devices based on IP subnet is optimal or secure other than using the IP config to locate the devices.  One view against doing this is if the one subnet is compromised then all those 3rd party devices are compromised.  Also this breaks entirely the view of distributed networking across IP subnets for the advantages a subnet provides and that would be unavailable to those devices.

Thanks
/jim

---

From: james woodyatt <[email-masked]>
Date: Wed, 9 Jan 2008 10:25:50 -0800

On Jan 9, 2008, at 09:08, Bound, Jim wrote:
> [ Iljitsch van Beijnum wrote: ]
>> [ Jim Bound wrote: ]
>>> [ Iljitsch van Beijnum wrote: ]
>>>>
>> Reason for the question: if ISPs insist on CPEs with modem and  
>> router functionality integrated, we can skip some issues (RAs from  
>> ISP to customer) but that means the ISP - CPE interface becomes  
>> more important because if it doesn't work right the user is left  
>> without recourse.
>
> True but I still think that is transparent to the modem and this is  
> really how are RAs/RSs going to work for a home environment.
>
> Important question is this work or model to be only for the home  
> CPE end and not other target markets for IPv6 deployment?

I'm okay with a model that says CPE for the residential and small- 
office markets have different requirements than CPE for middle and  
large enterprise sites.

>> vendors can build in logic that avoids problems when a user tries  
>> to connect multiple devices anyway.
>

I suspect IETF ought to give some consideration to what might happen  
if ISP's deploy such logic and 3rd parties begin offering solutions  
to "connect" multiple devices that present to the ISP as if they are  
the single device for which they are billed for service.

> Here I must disagree.  There is a difference between IP config for  
> example multiple subnets and then securing devices.  I don't  
> believe many now agree securing devices based on IP subnet is  
> optimal or secure other than using the IP config to locate the  
> devices.  One view against doing this is if the one subnet is  
> compromised then all those 3rd party devices are compromised.  Also  
> this breaks entirely the view of distributed networking across IP  
> subnets for the advantages a subnet provides and that would be  
> unavailable to those devices.

This question has a very simple answer for the "simple CPE security  
model" side of the discussion.

Users authorize 3rd-party devices to consume their broadband resource  
by allowing them to receive router advertisements— typically by  
plugging in the ethernet cable or joining the wireless access network.

I think it would be wise to recommend that those 3rd-party devices,  
which can operate without access to the global Internet, should be  
configured by default not to assign global scope interface addresses  
upon receiving router advertisements (i.e. assign only link-local  
addresses to all interfaces and process router advertisements only to  
learn about on-link prefixes).

I can think of some additional ways to support network segregation  
inside residential and small-office sites, but I think we should  
settle the easier disputes before moving on to the harder ones.