[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: AW: draft-wbeebee-ipv6-cpe-router-04 comments
My remembrance of why SPs aren't keen to localize routing is quite
Originally, cable operators had neighbors all on the same Ethernet
network. Neighbors were able to discover each other's computers and
printers (this was before routers were common), and sometimes sniff each
other's traffic. This was considered a bad thing, from a customer
security and privacy standpoint. Telco providers decided that they did
not want to it this way, and effectively made Ethernet connections from
customers "point-to-point" to an element in the access network.
Today, the access network elements are able to detect a lot of malware
traffic (especially DDoS attacks), and disconnect customers that are
infected with malware that presents a security / privacy /
performance-impacting risk to others. Unfortunately, this is not an
infrequent occurrence. If customer traffic were somehow able to bypass
these network elements, it would open up neighbors to attacks by
infected neighbors. That would be a very bad thing.
Furthermore, in general, there just isn't that much neighbor-to-neighbor
communication, that would make the savings outweigh the cost of
implementation. The only neighbor my home trades a lot of traffic with
(my kids and their kids, gaming) is on a separate network, since we use
different service providers.
Lack of cost justification and security concerns are the reasons why SPs
are unlikely to localize traffic within the access network, for general
> -----Original Message-----
> From: email@example.com [mailto:firstname.lastname@example.org] On
> Behalf Of Mark Smith
> Sent: Monday, March 30, 2009 5:48 AM
> To: Alan Kavanagh
> Cc: Alastair Johnson; Mikael Abrahamsson; Olaf.Bonness@telekom.de;
> Subject: Re: AW: draft-wbeebee-ipv6-cpe-router-04 comments
> Hi Alan,
> On Sun, 29 Mar 2009 21:09:37 -0400
> "Alan Kavanagh" <email@example.com> wrote:
> > Correct, and this is why SP's are not too keen to have routing
> > in the aggregation network before the BNG.
> I'd have thought they should be keen to avoid that, unless all of
> customers are all under or likely to all under surveilence at the same
> The technical requirement of LI is that traffic has pass the
> interception point. As the majority of people are honest, it seems to
> me that optimising the topology to pass the interception point, rather
> than for best throughput and lower latency, is wasteful, and an unfair
> performance and ultimately a network capex and opex cost burden on
> those subscribers who aren't under surveilence, and may never be. Only
> traffic that is to be lawfully intercepted should be forced past this
> interception point, if it doesn't already naturally traverse it.
> Some topologies would inherently make the BNG the best traffic
> interception point e.g. wholesale broadband aggregation via L2TP.
> However, for other topologies (e.g. a single VLAN interconnecting
> customers' ADSL routers, and an upstream default router for access to
> the Internet/other services), traffic can travel direct between
> subscribers / their CPE, as the CPEs have an on-link peer
> Should lawful interception be required, either that on-link path could
> be changed to traverse the interception point (e.g., by mechanisms
> such as forced forwarding), or better yet, the interception point be
> suspect subscriber's point of interconnection i.e. the specific ADSL
> service that they're using - as all their traffic is naturally going
> traverse that point.
> If an SP wants to have a topology that has all traffic traversing the
> BNG, or is forced to because of a legal requirement, that's fine.
> My argument is that other SPs won't have this requirement so they
> shouldn't also be forced to adopt this LI optimal topology - they
> should have the freedom to implement a topology optimised for
> throughput and low latency.
> So, getting back to the discussion point, I think there would be
> value in having a mechanism where downstream CPE can be informed of
> on-link peer-CPE's assigned prefixes, without the CPE themselves
> to trust each other's announcements. An idea I had a while back was a
> "prefix redirect", similar to an ND host redirect, issued by, and only
> accepted from, the upstream on-link default router. Not quite as
> optimal as the CPE themselves announcing their prefixes via a routing
> protocol, but it would be more scalable - the CPE would only be
> maintaining topological knowledge for destinations they're currently
> using, rather than for all the destinations they can reach via on-link
> peer CPE.
> > -----Original Message-----
> > From: firstname.lastname@example.org [mailto:email@example.com] On
> > Behalf Of Alastair Johnson
> > Sent: March 28, 2009 1:41 PM
> > To: Mark Smith
> > Cc: Mikael Abrahamsson; Olaf.Bonness@telekom.de; firstname.lastname@example.org
> > Subject: Re: AW: draft-wbeebee-ipv6-cpe-router-04 comments
> > Mark Smith wrote:
> > > On Thu, 26 Mar 2009 17:53:05 +0100 (CET) Mikael Abrahamsson
> > > <email@example.com> wrote:
> > >
> > >> On Thu, 26 Mar 2009, Olaf.Bonness@telekom.de wrote:
> > >>
> > >>> Normally the customers are separated from each other by split
> > horizont mchanisms and MAC adress translation techniques.
> > >> Yes, but that defeats the whole purpose of the proposal from Mark
> > >> Smith if I correctly interpret the scenario he proposed.
> > >>
> > >
> > > Yes it would defeat it. The only reason I can think of to require
> > > pinning of traffic between downstream on-link peer CPE is if your
> > > default router is your traffic billing point, and you want to bill
> > > (count) the traffic between those CPE. Otherwise you're probably
> > > unnecessarily forcing a P2P model connectivity model (i.e.
> > > an ATM ADSL backhaul model) onto a multi-access technology (an
> > > Ethernet/ADSL backhaul model).
> > Lawful Interception is another reason that a service provider may
> > all traffic from a subscriber aggregated to the default router.
> > may be no way around this, depending on the LI requirements that are
> > placed on the service provider, and where the logical interception
> > is (BNG vs. DSLAM).
> > aj
The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA622