RE: CPEs

["Bound, Jim" <Jim.Bound@hp.com>]

Response to Iljitsch mail below.

> -----Original Message-----
> From: owner-v6ops@ops.ietf.org
> [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Iljitsch van Beijnum
> Sent: Friday, January 04, 2008 7:35 AM
> To: IPv6 Operations
> Subject: CPEs
>
> 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.

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.
> (Maybe using an HTTP(S) proxy?)

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.

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

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.

>
> 12. How do we avoid problems caused by customer equipment MAC
> 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.

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

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

>
> DNS
>
> 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
> authentication work?

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