>
> > It would seem that as ISPs implement DPI and protocol-specific traffic
> > shaping, they damage the arguments that they can make claiming they
> > have "common carrier" status with the inherent immunities that status
> > provides. I can hear the argument now: if an ISP can throttle
> > BitTorrent (or whatever) for specific nodes, why can't they also limit
> > the source addresses of packets coming from those nodes?
>
> They can and should. I suspect many of them do as they
> usually apply these filters to home networks.
>
> BCP 38 is ~10 years old now. It should have been factored
> into the purchasing decision of all the current equipement.
> If it wasn't then the operator was negligent.
>
Mark
>
>
BCP 38 isn't a license, it's a technique.
There are plenty of cases in common law where as a owner
of something and you havn't taken reasonable steps to protect
or prevent injury that, were well known, you will be proved
to be negligent.
BCP 38 is falling into that sort of category.
Every operator here should be worried about what will happen
when someone decides to sue them to recover damaged caused
by spoofed traffic. It's just a matter of time before this
happens. Remember every router inspects packets to the
level required to implement BCP 38. This is not deep packet
inspection. This is address inspection which every router
performs.
Did you know about "BCP 38"?
What steps did you take to implement "BCP 38"?
I suspect that a lawyer will be able to demonstrate to a
judge that even as a common carrier that a operator should
have been deploying BCP 38.
Mark
I think each point above is true -- BCP38 is indeed a technique, but
failure to universally implement it defaults to (almost) a tragedy of the
commons.
After ~10 years, it is surreal to me that we, as a community, are still
grappling with issues where it could be beneficial for the Internet
community at-large. I mean, it _is_ a BCP.
- - ferg
p.s. Even when Dan Senie and I drafted RFC2827/BCP38, we were doing nothing
more than documenting what everyone (well, maybe not everyone) already knew
anyway -- that we all need to bite the bullet and just do it.
I think each point above is true -- BCP38 is indeed a technique, but
failure to universally implement it defaults to (almost) a tragedy of the
commons.
After ~10 years, it is surreal to me that we, as a community, are still
grappling with issues where it could be beneficial for the Internet
community at-large. I mean, it _is_ a BCP.
The community isn't grappling with the issue. For the most part the NANOG
community has implemented BCP 38. The problem is that there are lots
of ISPs that are not part of the community and I get the sense that the
this number continues to grow. In a sense NANOG has a problem with
dwindling market-share. A shrinking percentage of ISPs are part of the
NANOG community, and NANOG participants have less and less influence
on decisions in the ISPs that they work for, probably because most of
them do not work for ISPs but work for telephone companies which have
expanded into the ISP business. And yes, I too work for a telco that
is now also a major ISP in its telco market area.
p.s. Even when Dan Senie and I drafted RFC2827/BCP38, we were doing nothing
more than documenting what everyone (well, maybe not everyone) already knew
anyway -- that we all need to bite the bullet and just do it.
Personally, I think that the network operations community represented in
NANOG
needs to do more outreach to forums where the telecoms community gather
rather
than ghettoizing Internet ops and engineering. It's all well and good to
have NANOG
lists and meetings, but once things like BCP-38 reach consensus, how many
NANOG
members would consider going to something like FutureNet Expo and presenting
on the topic?
--Michael Dillon