Re: BCP38 is hard, was TWC (AS11351) blocking all NTP?

[Saku Ytti]

On (2014-02-05 00:29 -), John Levine wrote:
> >Why does it have to be hard? Restricting the filter to addresses which
> >(A) the customer asserts are theirs 
> 
> How does the customer do that in a way that scales?
> 
> I don't think any of this is rocket science, but it apparently is a
> real block to BCP38/84 implementatin.

Transit provider can do ACL, in some platforms it can be 100% same object as
used for BGP. Then setup ultimate rule to allow and log.
Then cooperate with customer to weed through the unexpected, until none remain
and flip the allow to deny.

But I guess no one is saying it cannot be done, more that there is no pay-off
in it. Transit provider is compensated for bits transferred, spending money to
receive less money may not appeal to people in charge.

You also wrote:

>>I was at a conference with people from some Very Large ISPs.  They
>>told me that many of their large customers absolutely will not let
>>them do BCP38 filtering.  ("If you don't want our business, we can
>>find someone else who does.")  The usual problem is that they have PA
>>space from two providers and for various reasons, not all of which are
>>stupid, traffic with provider A's addresses sometimes goes out through
>>provider B.  Adding to the excitement, some of these customers are
>>medium sized ISPs with multihomed customers of their own.

Someone who worked for such ISP, told they don't accept BCP38, because their
business is to sell services to instances who want to spoof for what ever
reason. The official reasons told to upstreams are different. He didn't
appreciate the business and no longer works for said ISP.
If what you say was actual reason, it could be solved by logging ACL.

We the community, could produce tooling to automate this in few popular
platforms. Automatically builds the ACL, web interface for humans to classify
the logged/unknown. When classified by human as legit source, automatically
create route object for it.
Recreate ACL from route-objects, submit to router. 

Repeat until human operator is confident no further classification is needed,
and ask tool to swap log+permit + deny.

Probably takes like maybe 50h development work.

-- 
  ++ytti, not it

Re: Why won't providers source-filter attacks? Simple.

[Saku Ytti]

On (2014-02-04 23:01 -0500), valdis.kletni...@vt.edu wrote:

> > Regulation and audits works well enough for butchers, resturants
> > etc.  Remember once BCP 38 is implemented it is relatively easy to
> > continue.  The big step is getting it turned on in the first place
> > which requires having the right equipment.
> >
> > Now if we could get equipement vendors to stop shipping models
> > without the necessary support it would help but that also may require
> > government intervention.
> 
> Time to name-and-shame.  It's 2014.  Who's still shipping gear that
> can't manage eyeball-facing BCP38?

If we keep thinking this problem as last-mile port problem, it won't be solved
in next 20 years. Because lot of those ports really can't do RPF and even if
they can do it, they are on autopilot and next change is market forced
fork-lift change. Company may not even employ technical personnel, only buy
consulting when making changes.

If we focus on transit borders, we can make spoofed DoS completely impractical
very rapidly, as spoofing is then restricted inside domain, and if target
isn't in same domain, you can't benefit from it. And as attacks are from
distributed botnets, you'll simply generate more attack traffic by not
spooffing, as you're not restricted inside spooffing domain.

However transit border doing ACL is something that seems to very
controversial, there is no universal consensus that it even should be done and
quite few seem to do it. I feel we need to change this, and make community at
large agree it is the BCP and solve the challenges presented.



-- 
  ++ytti

Re: Route Server Filters at IXPs and 4-byte ASNs

[Martin Pels]

Jeffrey,

On Tue, 4 Feb 2014 22:53:40 -0500
Jeffrey Haas  wrote:

> 
> 
> Sent from my iPad
> 
> > On Jan 25, 2014, at 1:37 PM, Nick Hilliard  wrote:
> > 
> >> On 25/01/2014 15:48, Sebastian Spies wrote:
> >> To make things worse: even if the IXPs ASN is 2-byte, I would assume,
> >> that RS implementors chose to interpret extended community strings as
> >> always being in the format 4-byte:2-byte (see RFC5668).
> > 
> > some ixp operators (e.g. me) are rather enthusiastic about the idea of a
> > modified form of draft-raszuk-wide-bgp-communities getting more traction.
> > This would solve this particular problem and many others.
> > 
> 
> Wide communities is the wrong tool here. You want this:
> http://tools.ietf.org/html/draft-ietf-idr-as4octet-extcomm-generic-subtype-06

This draft does not cater for the use case of describing a 32-bit ASN peering
with a 32-bit route server, which would require a 4-byte Global Administrator
as well as a 4-byte Local Administrator sub-field.

Kind regards,
Martin

Re: Route Server Filters at IXPs and 4-byte ASNs

[Randy Bush]

> The token to simplify is currently mine. The messy bit was an attempt
> to try to push policy algebra into the packet format.

jeezus!

> Cleaning up the document will take probably another two rounds but a
> terse description of where it should be going is "template based
> structured communities".

second system syndrome

Re: BCP38.info

[Arturo Servin]

Not working in the Internet access business but as Internet citizen
this sounds interesting.

You would need some motivations to make ISPs register and perhaps some
kind of validation in the future. But as initial step it sounds cool.

.as


On Wed, Jan 29, 2014 at 10:16 AM, Andrei Robachevsky
 wrote:
> Hi,
>
> Jared Mauch wrote on 1/28/14 9:03 PM:
>> I'd rather share some data and how others can observe this to determine how 
>> we can approach a fix.  Someone spoofing your IP address out some other 
>> carrier is something you may be interested to know about, even if you have a 
>> non-spoofing network.
>
> At the Internet Society we are flashing out an idea of an anti-spoofing
> "movement", where ISPs can list themselves as not spoofing-capable on
> our website. The requirement is that they can demonstrate that they
> block spoofed packets, for instance by successfully running the Spoofer
> test. I think your, Jared, test can add to this picture.
>
> Sort of a positive spin on the name and shame technique.
>
> It is not ideal, as one test is not a real proof of such capability, but
> might help raising awareness, at least. Does this sound as something
> that can be useful and fly?

Re: Cisco 7606 CPU Usage Problem

[Shawn L]

We had some similar issues whenever the BGP scanner process was running.
Ultimately we tracked down the issue to an access list that had the 'log'
statement appended to it, so it was logging all denies.  Removing that
cleared up the issue.


On Wed, Feb 5, 2014 at 2:34 AM, Shahab Vahabzadeh
wrote:

> Hi there,
> I have a Cisco 7606 with this module on it:
>
> WS-SUP32-GE-3B
>
>
> and I am using its own 8 port like this:
>
> 2 Port Layer two ether-channel uplink to my 4900 Cisco Switch and 1 Layer
> two uplink to Internet, and near 10 tunnel to my customers for internet
> exchange with BGP peering + some policy map for shaping tunnel interfaces.
> My ether-channel traffic on 600Mbps (each port 300Mbps) I get 90% cpu load
> and ping time problem on my router, what is the problem??
> And when I run: show processs cpu sorted
> I get a "Unknown" process eat the cpu process...
> I try lots of IOS version but it does not make difference.
>
> My IOS version is:
>
> c7600s3223-adventerprisek9-mz.150-1.S1.bin
>
>
>
> and some general configuration:
>
> no ip source-route
> > !
> > ip cef load-sharing algorithm original
> > no ip domain lookup
> > !
> > !
> > !
> > !
> > mls ip cef load-sharing full
> > no mls flow ip
> > no mls flow ipv6
> > mls qos
> > mls cef error action reset
> > multilink bundle-name authenticated
> > !
> > spanning-tree mode pvst
> > spanning-tree extend system-id
> > system flowcontrol bus auto
> > diagnostic bootup level minimal
> > port-channel load-balance src-ip
> > username admin secret 5 $1$g6WX$LaQbPyD3qIaHsF5qTqt8g0
> > !
> > redundancy
> >  main-cpu
> >   auto-sync running-config
> >  mode sso
> > !
> > !
> > !
> > !
> > vlan internal allocation policy ascending
> > vlan access-log ratelimit 2000
>
>
> Thanks
>
> --
> Regards,
> Shahab Vahabzadeh, Network Engineer and System Administrator
>
> Cell Phone: +1 (415) 871 0742
> PGP Key Fingerprint = 8E34 B335 D702 0CA7 5A81  C2EE 76A2 46C2 5367 BF90
>

Re: Route Server Filters at IXPs and 4-byte ASNs

[Jeffrey Haas]

Martin,

On Wed, Feb 05, 2014 at 10:06:31AM +0100, Martin Pels wrote:
> > Wide communities is the wrong tool here. You want this:
> > http://tools.ietf.org/html/draft-ietf-idr-as4octet-extcomm-generic-subtype-06
> 
> This draft does not cater for the use case of describing a 32-bit ASN peering
> with a 32-bit route server, which would require a 4-byte Global Administrator
> as well as a 4-byte Local Administrator sub-field.

I think that's the first clear articulation I've read about why some people
want wide comms vs. a simple replacement for existing regular communities as
extended communities.  Thanks.

Wide comms can do that, but they're intended to be a somewhat bigger hammer.

This case is probably worth chatting with the authors and others in IDR at
IETF to see if we should do something simpler.

-- Jeff

Re: Route Server Filters at IXPs and 4-byte ASNs

[Jared Mauch]

On Feb 5, 2014, at 8:52 AM, Jeffrey Haas  wrote:

>> This draft does not cater for the use case of describing a 32-bit ASN peering
>> with a 32-bit route server, which would require a 4-byte Global Administrator
>> as well as a 4-byte Local Administrator sub-field.
> 
> I think that's the first clear articulation I've read about why some people
> want wide comms vs. a simple replacement for existing regular communities as
> extended communities.  Thanks.

I suspect the operator confusion is that’s how they’ve been using 16-bit ASNs
all along, so how did the IETF end up with something different.

http://www.onesc.net/communities/ is a fairly comprehensive list of how they 
are used today.

- jared

Re: Route Server Filters at IXPs and 4-byte ASNs

[Jeffrey Haas]

On Wed, Feb 05, 2014 at 09:02:52AM -0500, Jared Mauch wrote:
> 
> On Feb 5, 2014, at 8:52 AM, Jeffrey Haas  wrote:
> 
> >> This draft does not cater for the use case of describing a 32-bit ASN 
> >> peering
> >> with a 32-bit route server, which would require a 4-byte Global 
> >> Administrator
> >> as well as a 4-byte Local Administrator sub-field.
> > 
> > I think that's the first clear articulation I've read about why some people
> > want wide comms vs. a simple replacement for existing regular communities as
> > extended communities.  Thanks.
> 
> I suspect the operator confusion is that?s how they?ve been using 16-bit ASNs
> all along, so how did the IETF end up with something different.
> 
> http://www.onesc.net/communities/ is a fairly comprehensive list of how they 
> are used today.

Thanks for the list.  Browsing the first several entries somewhat supports
the reason why I'm acting "surprised".  While there are some cases where the
right hand side of the community is an AS number, a significant amount of it
was either an arbitrary value or something more structured.

The generic 4-byte draft I'm part of is intended to be "low hanging fruit".
We don't need to deploy a new attribute, the format specifier is already
present in code.  All that was needed was a code point to say "go use this
like existing RFC 1997 comms".  

The wide comms draft (and flex comms, where some of the ideas were pulled in
from) was intended to address the messier case where the meaning of a
community was already structured.  To pick on one of the items in the list:
http://www.onesc.net/communities/as209/

Coding these using regexes is a PITA, both as an implementor of the
underlying policy and as a sender who has to remember what the magic value
means.  Ideally the operator should end up with something simple: 
Tell AS209, Do not announce to AS foo. Prepend N times to PST peers. Etc.
Right now, these things are magic values.

The last few rounds of wide comms were attempts to get encoding formats in
place that accommodated some amount of grouping logic 
(peer-class CUSTOMER & North America, e.g.).  We did manage to work out a
way to do that encoding correctly.  But it turned out that the real killer
was transitive manipulation - you can't meddle with such a thing without
breaking logic.  So, back to a simpler drawing board.

An update to the wide-comm draft should be out by end of this week.  We'd
welcome some constructive criticism on it.

-- Jeff

RE: Cogent <-> Verizon peering congestion

[Ben Bridges]

We've been having trouble with congestion between Verizon and Cogent in Chicago 
since May 2013.  We had to move some traffic off of our Verizon connection to 
get around it.  Verizon has apparently had an internal ticket open for the 
problem since February 2013.  Their response in August 2013 was "Cogent is 
designing an upgrade to turn up the bandwidth".  Their response a few weeks ago 
was "Verizon is working with Cogent on increasing more capacity there is no 
deadline of completion, issue ongoing since 2013 possible completion in 2014".  
In other words, they're blaming Cogent.

Ben Bridges
SpringNet

-Original Message-
From: Robert Glover [mailto:robe...@garlic.com] 
Sent: Tuesday, February 04, 2014 5:44 PM
To: nanog@nanog.org
Subject: Cogent <-> Verizon peering congestion

Hello,

For the last several months, we have been tracking a congestion issue between 
Cogent <-> Verizon

  Host Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. router.garlic.com 0.0%290.3   6.1   0.2 160.6  29.7
  2. vl203.mag03.sfo01.atlas.cogentco.com 0.0%292.2   8.1   2.1 
161.1  29.5
  3. te0-0-0-14.ccr22.sfo01.atlas.cogentco.com 0.0%292.9   2.7   
2.4   3.6   0.2
  4. be2165.ccr22.sjc01.atlas.cogentco.com 0.0%294.1   4.0   
3.7   4.8   0.2
  5. be2047.ccr21.sjc03.atlas.cogentco.com 0.0%294.5   4.7   
4.3   5.5   0.3
  6. verizon.sjc03.atlas.cogentco.com 22.2%28  169.3 171.5 168.1 
193.5   6.9
  7. so-1-0-0-0.SJC01-CORE-RTR2.verizon-gni.net 37.0%28  205.8 180.6 
171.6 271.6  24.8
  8. A12-0-135.SNFCCA-DSL-01.verizon-gni.net 33.3%28  172.3 177.5 
171.7 250.8  18.3
  9. pool-71-116-122-235.snfcca.btas.verizon.net 25.0%28  197.9 
197.6 195.5 199.2   0.8

We have smokeping's from our side showing 30%+ packet loss from us
(AS4307) to Verizon.

All I have gotten from Cogent is a canned response:

---
The latency and/or packet loss that you are experiencing to this destination is 
due to occasional high traffic with Verizon. We have repeatedly requested 
augments to these congestion points and hope Verizon will comply soon.  While 
this has been escalated internally to the CEO level, we encourage you to also 
contact Verizon customer support with your concerns and complaints.  Their 
delay is a major impediment to internet traffic overall and contrary to net 
neutrality requirements.  
Our peering engineers will continue to address this on a daily basis until 
resolved.
---

It seems to have gotten a lot worse in recent days, to the point where we have 
customers who are trying to access us from Verizon's network (i.e. they have 
Verizon DSL, or via Verizon 3G/4GLTE) complaining they are having a very hard 
to checking their email, etc.

Has anyone else been experiencing these issues?  Or does anyone have more 
information that what Cogent provided me in their canned statement?

-Bobby

Re: Route Server Filters at IXPs and 4-byte ASNs

[Jared Mauch]

On Feb 5, 2014, at 9:21 AM, Jeffrey Haas  wrote:

> The wide comms draft (and flex comms, where some of the ideas were pulled in
> from) was intended to address the messier case where the meaning of a
> community was already structured.  To pick on one of the items in the list:
> http://www.onesc.net/communities/as209/
> 
> Coding these using regexes is a PITA, both as an implementor of the
> underlying policy and as a sender who has to remember what the magic value
> means.  Ideally the operator should end up with something simple: 
> Tell AS209, Do not announce to AS foo. Prepend N times to PST peers. Etc.
> Right now, these things are magic values.

When possible (e.g.: here at AS2914) we have used things like this:


65500:nnn   do not announce to peer

where the NNN is the peer ASN.  Using such literal numbering is easier for
the humans involved.  The ability to see what route is learned from specific ASN
is also helpful, as things like AS_PATH are just a bit-string that can be 
arbitrarily
set and sent by a peer.

I will try to keep my eye open for the draft.

(perhaps see you in Atlanta or London).

- Jared

Re: BCP38 is hard, was TWC (AS11351) blocking all NTP?

[Jared Mauch]

On Feb 5, 2014, at 3:35 AM, Saku Ytti  wrote:

> If what you say was actual reason, it could be solved by logging ACL.
> 
> We the community, could produce tooling to automate this in few popular
> platforms. Automatically builds the ACL, web interface for humans to classify
> the logged/unknown. When classified by human as legit source, automatically
> create route object for it.
> Recreate ACL from route-objects, submit to router. 

The problem is many of these can compile to larger than the physical amount of 
space in the router/LC have to handle it.  I’ve done presentations to vendors 
about what percentage (in bytes and per-line) of the configuration is of what 
component.  90%+ tends to be customer-specific prefix-list/set/filter lines.

These can easily reach many megabytes of configuration and tens or hundreds of 
thousands of lines.  Asking someone to duplicate that to also have an ingress 
ACL of equivalent size, and *assuming* the router can handle that ACL and 
compile it properly is a challenge to say the least.

> Repeat until human operator is confident no further classification is needed,
> and ask tool to swap log+permit + deny.

Similar to the above, doing the log permit, etc.. is all dependent on the 
platform and what scale is feasible.  Some devices you can’t do things like 
log-input and capture the ingress MAC that originated the packet as it’s been 
stripped off before it gets to that part of the engine.

Similar to Randys previous comments, I would like to see another operator talk 
about their efforts here that has actually implemented something and is willing 
to share.  Right now, I’ve seen a lot of people say what others should do with 
“their” network, and limited data about what they have done to help solve this 
problem.  It’s harder than it seems, and even those that invite regulation and 
other things, the technology isn’t capable because it’s not something folks 
“ask for”.

> Probably takes like maybe 50h development work.

Let me know how that goes.  I’ve found estimates for this stuff can be off by 
as much as 10x + once all the details are chased down.  my wife has regularly 
been very patient with me when i say “10 minutes” and it’s closer to 2+ hours.  
I know we can do better than what the state is today, but there’s only so much 
that one network can do.

- Jared

Done a physical security audit lately?

[Jay Ashworth]

http://www.npr.org/blogs/thetwo-way/2014/02/05/272015606/sniper-attack-on-calif-power-station-raises-terrorism-fears
-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

Re: BCP38 is hard, was TWC (AS11351) blocking all NTP?

[Saku Ytti]

On (2014-02-05 11:15 -0500), Jared Mauch wrote:

> The problem is many of these can compile to larger than the physical amount 
> of space in the router/LC have to handle it.  I’ve done presentations to 
> vendors about what percentage (in bytes and per-line) of the configuration is 
> of what component.  90%+ tends to be customer-specific prefix-list/set/filter 
> lines.

Absolutely. But the good thing is, we don't need to have it comprehensively
deployed in transit scenarios, just as long as spoofing domains are
sufficiently fragmented DoS attack gets get better pay off from not spoofing.

-- 
  ++ytti

Looking for Time Warner NOC contact

[Eric Sieg]

Need some assistance isolating a connectivity issue between their customer
and mine.  Any assistance/direction would be greatly appreciated as normal
paths have been exhausted.

Re: BCP38 [Was: Re: TWC (AS11351) blocking all NTP?]

[Livingood, Jason]

Cool, thanks for the pointed. Now if we could get the data by ASN and
publish it on a site like bcp38.info, that would be awesome.



On 2/4/14, 11:03 PM, "Frank Bulk"  wrote:

>Here's such a report:
>
>http://spoofer.cmand.org/summary.php
>
>Frank
>
>-Original Message-
>From: Livingood, Jason [mailto:jason_living...@cable.comcast.com]
>Sent: Tuesday, February 04, 2014 6:53 PM
>To: Octavio Alvarez; North American Network Operators' Group
>Subject: Re: BCP38 [Was: Re: TWC (AS11351) blocking all NTP?]
>
>On 2/4/14, 7:48 PM, "Octavio Alvarez"  wrote:
>
>>What I'm failing to understand, and again, please excuse me if I'm
>>oversimplifying, is what data do you need from researchers,
>>specifically. What specific actionable data would be helpful? Why does
>>the lack of the data prevent you from applying an ACL.
>
>What I am suggesting is that the community at large needs measurement
>data, rather than individual network operators (which already know if they
>do or do not implement BCP38). Only with a long list of operators that DO
>prevent spoofing and a list of those that DO NOT, backed up with a decent
>data set (enough measurement points, enough measurement tests, across
>enough time, with an openly shared methodology), can the community start
>to encourage non-adopters to change their position. Just my two cents
>though...
>
>Jason
>
>
>
>

Re: BCP38 [Was: Re: TWC (AS11351) blocking all NTP?]

[Christopher Morrow]

I here tell the spoofer project people are looking to improve their data
and stats... And reporting.
On Feb 5, 2014 1:08 PM, "Livingood, Jason" <
jason_living...@cable.comcast.com> wrote:

> Cool, thanks for the pointed. Now if we could get the data by ASN and
> publish it on a site like bcp38.info, that would be awesome.
>
>
>
> On 2/4/14, 11:03 PM, "Frank Bulk"  wrote:
>
> >Here's such a report:
> >
> >http://spoofer.cmand.org/summary.php
> >
> >Frank
> >
> >-Original Message-
> >From: Livingood, Jason [mailto:jason_living...@cable.comcast.com]
> >Sent: Tuesday, February 04, 2014 6:53 PM
> >To: Octavio Alvarez; North American Network Operators' Group
> >Subject: Re: BCP38 [Was: Re: TWC (AS11351) blocking all NTP?]
> >
> >On 2/4/14, 7:48 PM, "Octavio Alvarez"  wrote:
> >
> >>What I'm failing to understand, and again, please excuse me if I'm
> >>oversimplifying, is what data do you need from researchers,
> >>specifically. What specific actionable data would be helpful? Why does
> >>the lack of the data prevent you from applying an ACL.
> >
> >What I am suggesting is that the community at large needs measurement
> >data, rather than individual network operators (which already know if they
> >do or do not implement BCP38). Only with a long list of operators that DO
> >prevent spoofing and a list of those that DO NOT, backed up with a decent
> >data set (enough measurement points, enough measurement tests, across
> >enough time, with an openly shared methodology), can the community start
> >to encourage non-adopters to change their position. Just my two cents
> >though...
> >
> >Jason
> >
> >
> >
> >
>
>
>

[iab-ch...@iab.org: Call for Review of draft-iab-filtering-considerations-06.txt, "Technical Considerations for Internet Service Blocking and Filtering"]

[Jeffrey Haas]

It's IETF stuff.  Operator sanity check would probably be appreciated. :-)

-- Jeff

- Forwarded message from IAB Chair  -

Date: Wed, 29 Jan 2014 11:16:56 -0500
From: IAB Chair 
To: IETF Announce 
Cc: IAB , IETF 
Subject: Call for Review of draft-iab-filtering-considerations-06.txt, 
"Technical Considerations for Internet Service Blocking and Filtering"

This is a call for review of "Technical Considerations for Internet
Service Blocking and Filtering" prior to potential approval as an
IAB stream RFC.

The document is available for inspection here:
https://datatracker.ietf.org/doc/draft-iab-filtering-considerations/

The Call for Review will last until 26 February 2014.
Please send comments to i...@iab.org. 

On behalf of the IAB,
  Russ Housley
  IAB Chair

- End forwarded message -

Re: [iab-ch...@iab.org: Call for Review of draft-iab-filtering-considerations-06.txt, "Technical Considerations for Internet Service Blocking and Filtering"]

[Andrew Sullivan]

On Wed, Feb 05, 2014 at 02:17:27PM -0500, Jeffrey Haas wrote:
> It's IETF stuff.  Operator sanity check would probably be appreciated. :-)

Speaking as a member of the IAB but not for the IAB, I would certainly
appreciate that review.

A

-- 
Andrew Sullivan
Dyn, Inc.
asulli...@dyn.com
v: +1 603 663 0448

Re: [iab-ch...@iab.org: Call for Review of draft-iab-filtering-considerations-06.txt, "Technical Considerations for Internet Service Blocking and Filtering"]

[William Herrin]

> This is a call for review of "Technical Considerations for Internet
> Service Blocking and Filtering" prior to potential approval as an
> IAB stream RFC.
>
> The document is available for inspection here:
> https://datatracker.ietf.org/doc/draft-iab-filtering-considerations/
>
> The Call for Review will last until 26 February 2014.
> Please send comments to i...@iab.org.

Howdy,

Some initial thoughts:

I'm not sure about the difference between network blocking and
endpoint blocking, but I think differences between the three major
types of network blocking are at least as significant as the
difference between network blocking and rendezvous blocking. If the
document calls out rendezvous blocking, it should call out all three
types of network blocking as well. Each has very different
characteristics which would be more effectively graded on the
document's criteria if discussed separately.

The three major types of networking blocking are:

packet blocking - only packets meeting certain criteria are allowed,
(e.g. IP destination address 10.0.0.1, inbound TCP with the ACK flag
set)

stateful connection blocking - only packets belonging to layer-4
connections meeting certain criteria are allowed (e.g. TCP initiated
to port 80 outbound, TCP initiated to port 443 outbound)

protocol blocking - only connections containing specific known
protocols (e.g. http, ssl) are allowed, or alternately specific
identifiable protocols are blacklisted

The latter is a relatively new (within the last half decade) thing
that has become widely implemented in large enterprises. It started
out as deep packet inspection but has become much more.


Also, section 4.1.3 treats asymmetric routing as if it was usually or
always outside the control of the blocking entity. That's not
reasonable. There are as many network blocking scenarios where the
blocking authority can enforce symmetric routing as there are
scenarios where it can't. The efficacy discussion should recognize
that you have those two groups of scenarios and that the efficacy of
network blocking varies in each.

Further, the user's ability to tunnel around such blocks depends
heavily on the type of network blocking. Packet blocking can generally
be tunneled around given cooperating endpoints. When protocol blocking
is active, that proves far more challenging.

Regards,
Bill Herrin


-- 
William D. Herrin  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: 
Falls Church, VA 22042-3004

Re: Done a physical security audit lately?

[Christopher Morrow]

hard to do physical security protections on a 1.5mile radius around
your assets, eh?
reference: 

also, see vijay's presentation: (slide 12)


-chris
(point about general physical security reviews not withstanding)

On Wed, Feb 5, 2014 at 12:55 PM, Jay Ashworth  wrote:
> http://www.npr.org/blogs/thetwo-way/2014/02/05/272015606/sniper-attack-on-calif-power-station-raises-terrorism-fears
> --
> Sent from my Android phone with K-9 Mail. Please excuse my brevity.

RE: Done a physical security audit lately?

[Azinger, Marla]

http://www.youtube.com/watch?v=NOZM5ZwN0kM

nope not a problem

-Original Message-
From: Christopher Morrow [mailto:morrowc.li...@gmail.com] 
Sent: Wednesday, February 05, 2014 12:08 PM
To: Jay Ashworth
Cc: nanog list
Subject: Re: Done a physical security audit lately?

hard to do physical security protections on a 1.5mile radius around your 
assets, eh?
reference: 

also, see vijay's presentation: (slide 12) 


-chris
(point about general physical security reviews not withstanding)

On Wed, Feb 5, 2014 at 12:55 PM, Jay Ashworth  wrote:
> http://www.npr.org/blogs/thetwo-way/2014/02/05/272015606/sniper-attack
> -on-calif-power-station-raises-terrorism-fears
> --
> Sent from my Android phone with K-9 Mail. Please excuse my brevity.

Re: Done a physical security audit lately?

[Christopher Morrow]

On Wed, Feb 5, 2014 at 3:24 PM, Azinger, Marla  wrote:
> http://www.youtube.com/watch?v=NOZM5ZwN0kM
>
> nope not a problem

wait, wait, wait... check out the video at :54
is that an f'ing unicorn?? I think it is!

>
> -Original Message-
> From: Christopher Morrow [mailto:morrowc.li...@gmail.com]
> Sent: Wednesday, February 05, 2014 12:08 PM
> To: Jay Ashworth
> Cc: nanog list
> Subject: Re: Done a physical security audit lately?
>
> hard to do physical security protections on a 1.5mile radius around your 
> assets, eh?
> reference: 
>
> also, see vijay's presentation: (slide 12) 
> 
>
> -chris
> (point about general physical security reviews not withstanding)
>
> On Wed, Feb 5, 2014 at 12:55 PM, Jay Ashworth  wrote:
>> http://www.npr.org/blogs/thetwo-way/2014/02/05/272015606/sniper-attack
>> -on-calif-power-station-raises-terrorism-fears
>> --
>> Sent from my Android phone with K-9 Mail. Please excuse my brevity.
>

RE: Done a physical security audit lately?

[Azinger, Marla]

Can't get anything past you Chris!  :-)   

Um Yeah!  Why wouldn't it be!?

-Original Message-
From: christopher.mor...@gmail.com [mailto:christopher.mor...@gmail.com] On 
Behalf Of Christopher Morrow
Sent: Wednesday, February 05, 2014 12:34 PM
To: Azinger, Marla
Cc: Jay Ashworth; nanog list
Subject: Re: Done a physical security audit lately?

On Wed, Feb 5, 2014 at 3:24 PM, Azinger, Marla  wrote:
> http://www.youtube.com/watch?v=NOZM5ZwN0kM
>
> nope not a problem

wait, wait, wait... check out the video at :54 is that an f'ing unicorn?? I 
think it is!

>
> -Original Message-
> From: Christopher Morrow [mailto:morrowc.li...@gmail.com]
> Sent: Wednesday, February 05, 2014 12:08 PM
> To: Jay Ashworth
> Cc: nanog list
> Subject: Re: Done a physical security audit lately?
>
> hard to do physical security protections on a 1.5mile radius around your 
> assets, eh?
> reference: 
>
> also, see vijay's presentation: (slide 12) 
>  te.pdf>
>
> -chris
> (point about general physical security reviews not withstanding)
>
> On Wed, Feb 5, 2014 at 12:55 PM, Jay Ashworth  wrote:
>> http://www.npr.org/blogs/thetwo-way/2014/02/05/272015606/sniper-attac
>> k -on-calif-power-station-raises-terrorism-fears
>> --
>> Sent from my Android phone with K-9 Mail. Please excuse my brevity.
>

Verizon Wireless NOC contact

[Staudinger, Malcolm]

Can someone from Verizon contact me off-list? We're seeing DNS resolution 
issues to Earthlink domains from Verizon Wireless customers, and have only 
gotten the run around from our "usual" Verizon NOC contacts

Malcolm Staudinger
Information Security Analyst | EIS
EarthLink
www.earthlink.net

E: mstaudin...@corp.earthlink.com

Re: [iab-ch...@iab.org: Call for Review of draft-iab-filtering-considerations-06.txt, "Technical Considerations for Internet Service Blocking and Filtering"]

[Nick Hilliard]

On 05/02/2014 19:17, Jeffrey Haas wrote:
> It's IETF stuff.  Operator sanity check would probably be appreciated. :-)

Jeff, maybe run this past grow@ietf?

Nick

> - Forwarded message from IAB Chair  -
> 
> Date: Wed, 29 Jan 2014 11:16:56 -0500
> From: IAB Chair 
> To: IETF Announce 
> Cc: IAB , IETF 
> Subject: Call for Review of draft-iab-filtering-considerations-06.txt, 
> "Technical Considerations for Internet Service Blocking and Filtering"
> 
> This is a call for review of "Technical Considerations for Internet
> Service Blocking and Filtering" prior to potential approval as an
> IAB stream RFC.
> 
> The document is available for inspection here:
> https://datatracker.ietf.org/doc/draft-iab-filtering-considerations/
> 
> The Call for Review will last until 26 February 2014.
> Please send comments to i...@iab.org. 
> 
> On behalf of the IAB,
>   Russ Housley
>   IAB Chair
> 
> - End forwarded message -
> 

Re: BCP38 [Was: Re: TWC (AS11351) blocking all NTP?]

[Jay Ashworth]

- Original Message -
> From: "Octavio Alvarez" 

> Maybe I'm oversimplifying things but I'm really curious to know why
> can't the nearest-to-end-user ACL-enabled router simply have an ACL to
> only allows packets from end-users that has a valid source-address
> from the network segment they provide service to.

The common answer, Octavio, at least *used to* be "our line cards aren't 
smart enough to implement strict-unicast-RPF, and our boxes don't have 
enough horsepower to handle every packet through the CPU".

As I've noted, I'm not sure I believe that's true of current generation
gear, and if it *is*, then it should cost manufacturers business.

Cheers,
-- jra
-- 
Jay R. Ashworth  Baylink   j...@baylink.com
Designer The Things I Think   RFC 2100
Ashworth & Associates   http://www.bcp38.info  2000 Land Rover DII
St Petersburg FL USA  BCP38: Ask For It By Name!   +1 727 647 1274

POLL: BCP38 Name And Shame

[Jay Ashworth]

- Original Message -
> From: "Valdis Kletnieks" 

> Time to name-and-shame. It's 2014. Who's still shipping gear that
> can't manage eyeball-facing BCP38?

It sure is.



POLL: If you run "eyeball" equipment -- edge concentrators/routers/CMTSen,
would you please post, without employer attribution, what make & model it
is, and which firmware rev it's running, and whether it has a knob for
unicast-strict-RPF or an equivalent automatic filtering method which is
compatible with "flip the switch" BCP38 deployment, and preferably runs 
on the relevant line cards, not CPU.

At your option, you can mention whether it's already on, whether you 
had to look it up, and which network it is.  :-)

PLEASE RESPOND to jra+bc...@baylink.com, not the list; I will aggregate.

I do not plan to mention any people in the results, but if I'm told the
names of networks in sufficient specificity to avoid confusion, I will
include those.

Cheers,
-- jra
-- 
Jay R. Ashworth  Baylink   j...@baylink.com
Designer The Things I Think   RFC 2100
Ashworth & Associates   http://www.bcp38.info  2000 Land Rover DII
St Petersburg FL USA  BCP38: Ask For It By Name!   +1 727 647 1274

Re: BCP38

[Jay Ashworth]

- Original Message -
> From: "Frank Bulk" 

> Here's such a report:
> 
> http://spoofer.cmand.org/summary.php

And those results aren't bad; they amount to between 2/3 and 3/4 of 
real source address space already having something implemented, if I'm
reading them correctly.

Cheers,
-- jra
-- 
Jay R. Ashworth  Baylink   j...@baylink.com
Designer The Things I Think   RFC 2100
Ashworth & Associates   http://www.bcp38.info  2000 Land Rover DII
St Petersburg FL USA  BCP38: Ask For It By Name!   +1 727 647 1274

Re: BCP38 [Was: Re: TWC (AS11351) blocking all NTP?]

[joel jaeggli]

On 2/5/14, 1:24 PM, Jay Ashworth wrote:
> - Original Message -
>> From: "Octavio Alvarez" 
> 
>> Maybe I'm oversimplifying things but I'm really curious to know why
>> can't the nearest-to-end-user ACL-enabled router simply have an ACL to
>> only allows packets from end-users that has a valid source-address
>> from the network segment they provide service to.
> 
> The common answer, Octavio, at least *used to* be "our line cards aren't 
> smart enough to implement strict-unicast-RPF, and our boxes don't have 
> enough horsepower to handle every packet through the CPU".
> 
> As I've noted, I'm not sure I believe that's true of current generation
> gear, and if it *is*, then it should cost manufacturers business.

There are boxes that haven't aged out of the network yet where that's an
issue, some are more datacenter-centric than others. force10 e1200 was
one platform that had this limitation for example.

> Cheers,
> -- jra
> 




signature.asc
Description: OpenPGP digital signature

Comcast NOC contact

[Joe Marr]

I'm seeing an odd routing issue with Comcast and would like their help.
Does any have any contact information for them?

BCP38 is hard; let's go shopping!

[Jay Ashworth]

- Original Message -
> From: "joel jaeggli" 

> > As I've noted, I'm not sure I believe that's true of current generation
> > gear, and if it *is*, then it should cost manufacturers business.
> 
> There are boxes that haven't aged out of the network yet where that's an
> issue, some are more datacenter-centric than others. force10 e1200 was
> one platform that had this limitation for example.

So making sure manufacturers are producing gear that's BCP38-compliant,
and buyers have it on their tick-list, is still a productive goal, too.

Cheers,
-- jra
-- 
Jay R. Ashworth  Baylink   j...@baylink.com
Designer The Things I Think   RFC 2100
Ashworth & Associates   http://www.bcp38.info  2000 Land Rover DII
St Petersburg FL USA  BCP38: Ask For It By Name!   +1 727 647 1274

Re: Comcast NOC contact

[John Neiberger]

Sure. Send me the details and I'll take a look or reach out to another more
appropriate team.

Thanks,
John


On Wed, Feb 5, 2014 at 2:45 PM, Joe Marr  wrote:

> I'm seeing an odd routing issue with Comcast and would like their help.
> Does any have any contact information for them?
>

Re: BCP38 is hard; let's go shopping!

[joel jaeggli]

On 2/5/14, 1:46 PM, Jay Ashworth wrote:
> - Original Message -
>> From: "joel jaeggli" 
> 
>>> As I've noted, I'm not sure I believe that's true of current generation
>>> gear, and if it *is*, then it should cost manufacturers business.
>>
>> There are boxes that haven't aged out of the network yet where that's an
>> issue, some are more datacenter-centric than others. force10 e1200 was
>> one platform that had this limitation for example.
> 
> So making sure manufacturers are producing gear that's BCP38-compliant,
> and buyers have it on their tick-list, is still a productive goal, too.

it is...  The products are probably close to the end of their sales
life, but they'll likely be around for a while.

> Cheers,
> -- jra
> 




signature.asc
Description: OpenPGP digital signature

Re: BCP38 is hard; let's go shopping!

[Christopher Morrow]

On Wed, Feb 5, 2014 at 4:46 PM, Jay Ashworth  wrote:
> - Original Message -
>> From: "joel jaeggli" 
>
>> > As I've noted, I'm not sure I believe that's true of current generation
>> > gear, and if it *is*, then it should cost manufacturers business.
>>
>> There are boxes that haven't aged out of the network yet where that's an
>> issue, some are more datacenter-centric than others. force10 e1200 was
>> one platform that had this limitation for example.
>
> So making sure manufacturers are producing gear that's BCP38-compliant,
> and buyers have it on their tick-list, is still a productive goal, too.

but, if it's a datacenter deployment there are mitigations you can
perform aside from uRPF... right?

you COULD just use a simple acl on the interface: "my local network
is..." which you could even automate.

you COULD do dhcp-snooping/mac-locking/etc and ensure that the
end-host is only using the one address(es) it's permitted to use.
(potentially harder to do on some gear)

you COULD clamp the outbound path from edge-L3 box -> code with the
right acl, since you konw what traffic should come out of the local L3
edge piece.

the answer doesn't' have to be uRPF.

Re: Why won't providers source-filter attacks? Simple.

[Mark Andrews]

In message 
, Landon Stewart writes:
> --f46d042c63a5ad12dd04f1abc724
> Content-Type: text/plain; charset="ISO-8859-1"
> Content-Transfer-Encoding: quoted-printable
> 
> On 4 February 2014 17:18, Mark Andrews  wrote:
> 
> > > That would never fly, because it would put the politicians at odds with
> > > the telecom buddies that make huge political donations.   Hard to throw
> > > someone in jail then hit them up for campaign money.  What will
> > > probably happen is the same thing we do with everything else that might
> > > be used for evil purposes but where we don't want to tackle the real
> > > underlying problem -- just write a law banning something and hope the
> > > problem goes away.
> >
> > No, you write a law requiring something, e.g. BCP 38 filtering by
> > ISPs, and you audit it.  You also make the ISPs directors liable
> > for the impact that results from spoofed traffic from them.
> >
> > Making it law puts all the ISP's in the country on a equal footing
> > with respect to implementation costs.
> >
> 
> This is a slippery slope if I've ever seen one.  If we start having
> legislators making laws for how packets are served we are just begging for
> them to put their feet into all kinds of doors that we don't want them in.

Well when industries don't self regulate governments step in.  This
industry is demonstratably incapble of regulating itself in this
area despite lots of evidence of the problems being caused for lots
of years.  This has been DOCUMENTED BEST CURRENT PRACTICE for 13.5
years.  Everybody else is having to deal the problems caused by
these bad actors.

Hell, I suspect you could send the directors to gaol or make them
pay a heavy fine today by properly examining the existing laws.  A new
law would just make the problem more explicit.

Mark

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

Re: BCP38 [Was: Re: TWC (AS11351) blocking all NTP?]

[Seth Mattinen]

On 2/5/14, 13:24, Jay Ashworth wrote:

The common answer, Octavio, at least*used to*  be "our line cards aren't
smart enough to implement strict-unicast-RPF, and our boxes don't have
enough horsepower to handle every packet through the CPU".

As I've noted, I'm not sure I believe that's true of current generation
gear, and if it*is*, then it should cost manufacturers business.



In Cisco 6500 land - which were very popular - Earl7 uRPF is limited to 
one of strict or loose (no mixing modes) for IPv4 only. Otherwise you 
have to rely on ACLs and the possibility of running out of TCAM space 
for them depending on density.


The Sup2T (Earl8) does fix these limitations: uRPF is configurable 
per-interface basis and independent of IPv4/IPv6, and can be a mix of 
loose or strict mode. But Sup2T only came out in 2011.


~Seth

Re: Why won't providers source-filter attacks? Simple.

[Randy Bush]

> Well when industries don't self regulate governments step in.  This
> industry is demonstratably incapble of regulating itself in this
> area despite lots of evidence of the problems being caused for lots
> of years.  This has been DOCUMENTED BEST CURRENT PRACTICE for 13.5
> years.  Everybody else is having to deal the problems caused by
> these bad actors.
> 
> Hell, I suspect you could send the directors to gaol or make them
> pay a heavy fine today by properly examining the existing laws.  A new
> law would just make the problem more explicit.

and the reason for the extreme hyperbole is that this problem is
seriously affecting the service provider where you work?

Re: Why won't providers source-filter attacks? Simple.

[Jimmy Hess]

On Wed, Feb 5, 2014 at 2:46 AM, Saku Ytti  wrote:

>
> If we keep thinking this problem as last-mile port problem, it won't be
> solved

in next 20 years. Because lot of those ports really can't do RPF and even
> if

[snip]


The last-mile ports don't necessarily need RPF; a simple inbound access
list on the ISP side...  Or even outbound on CPE side, with all valid
source addresses allowed,  and nothing else:  is just perfect.

In essence; it is a last-mile problem, and that is part of  the challenge.
 The last-mile is the best possible place to filter, without breaking
things. As for the idea, that the world can take a shortcut,  and
 filter in some manner at transit services is tantalizing, but also: is not
quite adequate,  and that's probably not going to happen either.


> [snip]
>
However transit border doing ACL is something that seems to very
> controversial, there is no universal consensus that it even should be


Anything that is likely to blackhole legitimate traffic is going to be
controversial.

IP source based filtering on transit links may very well fall into that
category of greatly increasing that risk in many cases.

   Restricting the source IP address range in from transit links is a bad
idea, unless you can be certain that no other source IPs will show up
legitimately,   which you cannot necessarily be.

  If i am a transit provider,  and I connect with a peer network buying
transit from me,  then they get to route traffic over that link: according
to the routes my network announced to their router.

If my router discards any of that traffic based on source,  then the route
I propagated to my peer was dishonest ---  that is,   it would mean my
route announcement was a lie: the filtering would in essence make some
routes blackhole routes, and I am disrupting the connectivity for the
unexpected source addresses,  just by turning up that link.

Or I am at risk of disrupting connectivity in the future, to any network
that my downstream peer later interconnects with,  if they will also
provide transit in that relationship,  and also... it would be a common
practice on many networks to  turn up such interconnections  at a date
before  I or  any other transit upstreams are informed.

It is likely from time to time, that many transit downstreams will  obtain
additional address allocations, or  that they will make additional network
connections:  especially, if in fact,  my downstream peer is multihomed,
possibly with numerous providers,  and they may themselves be a transit
provider.

At a certain level;   "RPF"   does not work,   because:  by design,
routing IN and OUT can very well be asymmetric  traffic flows for networks
 that are multihomed.

Not announcing the source  to a specific network,  doesn't make it OKAY for
the adjacent transit network to drop traffic from that source.



> done and
> quite few seem to do it. I feel we need to change this, and make community
> at
> large agree it is the BCP and solve the challenges presented.
>

--
-JH

Re: Why won't providers source-filter attacks? Simple.

[Paul Ferguson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 2/5/2014 7:06 PM, Jimmy Hess wrote:

> The last-mile is the best possible place to filter, without
> breaking things.

I could not agree more. :-)

- - ferg


- -- 
Paul Ferguson
VP Threat Intelligence, IID
PGP Public Key ID: 0x54DC85B2

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iF4EAREIAAYFAlLy/5gACgkQKJasdVTchbKXbAEAqFswL2qtqIgRcALVMLdQA0H/
dRLvmDhCoXEmRtOB2B8BAMbH489q8lB/qdiEofYviAAnNA6aqpT38ASXDzBUKO/K
=xjIk
-END PGP SIGNATURE-

Re: Why won't providers source-filter attacks? Simple.

[Mark Andrews]

In message <52f2ff98.2030...@mykolab.com>, Paul Ferguson writes:
> On 2/5/2014 7:06 PM, Jimmy Hess wrote:
> 
> > The last-mile is the best possible place to filter, without
> > breaking things.
> 
> I could not agree more. :-)
> 
> - - ferg

Remember "last mile" includes "datacenter" and "noc".

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

Re: Why won't providers source-filter attacks? Simple.

[Paul Ferguson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 2/5/2014 7:35 PM, Mark Andrews wrote:

> In message <52f2ff98.2030...@mykolab.com>, Paul Ferguson writes:
>> On 2/5/2014 7:06 PM, Jimmy Hess wrote:
>> 
>>> The last-mile is the best possible place to filter, without 
>>> breaking things.
>> 
>> I could not agree more. :-)
>> 
>> - - ferg
> 
> Remember "last mile" includes "datacenter" and "noc".
> 

Whatever gets it done.

I'm just sick of hearing why people can't do it, instead of reasons
why they can.

- - ferg



- -- 
Paul Ferguson
VP Threat Intelligence, IID
PGP Public Key ID: 0x54DC85B2

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iF4EAREIAAYFAlLzBE8ACgkQKJasdVTchbL6mQEAo6p/QQxyEdiQkf1/91nteK1u
z3zyR9QbO7dtDuEBftkBANAlfy+zqbMuOp03rIiPu/pk3Ixt+mo58Yjs3fOHfqUG
=9wRN
-END PGP SIGNATURE-

Re: Why won't providers source-filter attacks? Simple.

[Randy Bush]

>> The last-mile is the best possible place to filter, without breaking
>> things.
> I could not agree more. :-)

very large consumer populations are on metro-ether-like things.  and it
gets kinkier from there, don't eat before looking at what ntt-east has
done with ngn.

i fear we really have most of the easy big deployments and all of the
cool kids.  we're down to statistically small stubborn do-nothings and
some folk with equipment that will take years to be pushed off net.

randy

Re: Why won't providers source-filter attacks? Simple.

[Paul Ferguson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 2/5/2014 7:43 PM, Randy Bush wrote:

>>> The last-mile is the best possible place to filter, without
>>> breaking things.
>> I could not agree more. :-)
> 
> very large consumer populations are on metro-ether-like things.
> and it gets kinkier from there, don't eat before looking at what
> ntt-east has done with ngn.
> 
> i fear we really have most of the easy big deployments and all of
> the cool kids.  we're down to statistically small stubborn
> do-nothings and some folk with equipment that will take years to be
> pushed off net.
> 

Maybe. Maybe not.

I think it really depends how we approach the problem -- apparently
our approaches up until now have been failures to a certain degree. At
least 20-30% failure, if you believe the Spoofer Project numbers.

I'd like to think (and I am not happy smiley person as you well know)
that perhaps we can motivate some younger, brighter, ingenious people
who have not been tilting at this for 15 years to consider new ways to
approach this problem. :-)  <-- Smiley!

- - ferg


- -- 
Paul Ferguson
VP Threat Intelligence, IID
PGP Public Key ID: 0x54DC85B2

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iF4EAREIAAYFAlLzBggACgkQKJasdVTchbL8hwEAwXbejfCFaOQnqYz6v8xcXfb7
uTmSIWZj+kuiGh976lUA/A5gGGrrAzaVyp3SqX57p5AR8w9kfMQEEbVMLCn7il4R
=FE9f
-END PGP SIGNATURE-

Re: Why won't providers source-filter attacks? Simple.

[Randy Bush]

> I'd like to think (and I am not happy smiley person as you well know)
> that perhaps we can motivate some younger, brighter, ingenious people
> who have not been tilting at this for 15 years to consider new ways to
> approach this problem. :-)  <-- Smiley!

we should definitely scream at them and threaten legal action and
lightning strikes from the gods.

randy

Re: BCP38 [Was: Re: TWC (AS11351) blocking all NTP?]

[Mark Tinka]

On Wednesday, February 05, 2014 11:24:42 PM Jay Ashworth 
wrote:

> As I've noted, I'm not sure I believe that's true of
> current generation gear, and if it *is*, then it should
> cost manufacturers business.

But only matters if you're refreshing or just starting out.

A lot of operators have a large installed base of such kit, 
and given horsepower is still plenty, getting that swapped 
out is a tall ask.

Mark.


signature.asc
Description: This is a digitally signed message part.

Re: BCP38 [Was: Re: TWC (AS11351) blocking all NTP?]

[Jay Ashworth]

Sure.  Part of the data collection task.  Making sure all the current new gear 
knows how, still a good idea.

On February 5, 2014 11:32:26 PM EST, Mark Tinka  wrote:
>On Wednesday, February 05, 2014 11:24:42 PM Jay Ashworth 
>wrote:
>
>> As I've noted, I'm not sure I believe that's true of
>> current generation gear, and if it *is*, then it should
>> cost manufacturers business.
>
>But only matters if you're refreshing or just starting out.
>
>A lot of operators have a large installed base of such kit, 
>and given horsepower is still plenty, getting that swapped 
>out is a tall ask.
>
>Mark.

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

Re: BCP38 [Was: Re: TWC (AS11351) blocking all NTP?]

[Mark Tinka]

On Thursday, February 06, 2014 06:34:16 AM Jay Ashworth 
wrote:

> Sure.  Part of the data collection task.  Making sure all
> the current new gear knows how, still a good idea.

Yep - like Joel said; current kit supports it (well, the 
ones I buy, anyway), and certainly a good idea for operators 
to make sure their favorite vendor can support this when 
they run their next purchase cycle.

Mark.


signature.asc
Description: This is a digitally signed message part.

Re: BCP38 [Was: Re: TWC (AS11351) blocking all NTP?]

[Jay Ashworth]

I'm going to be somewhat of a pain in everybody's ass this year, pounding on 
the drum whenever the topic pops up. :-)

On February 5, 2014 11:38:08 PM EST, Mark Tinka  wrote:
>On Thursday, February 06, 2014 06:34:16 AM Jay Ashworth 
>wrote:
>
>> Sure.  Part of the data collection task.  Making sure all
>> the current new gear knows how, still a good idea.
>
>Yep - like Joel said; current kit supports it (well, the 
>ones I buy, anyway), and certainly a good idea for operators 
>to make sure their favorite vendor can support this when 
>they run their next purchase cycle.
>
>Mark.

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

SIP on FTTH systems

[Jean-Francois Mezei]

Quick question:

I am thinking in a possible wholesale FTTH environment operated by a
telco where the end user is connected to ISP-X via PPPoE.

ONTs have built-in ATAs that can provide POTS service to a house and do
SIP/VoIP over the fibre with QoS system to ensure VoIP traffic gets through.

In a scenario where the data PPPoE connection is done by an external
router, what are the options to operate the VoIP service so that

- VoIP still uses the special lane on the GPON with QoS

- VoIP gets IP from ISP-X and traffic flow via ISP-X so that telco is
not involved in routing such traffic or allocating an IP address ?


Is the only option to program the ONT to establish its own PPPoE session
to the ISP that carries only SIP traffic (and can such a setup make use
of the special "lane" reserved for VoIP traffic ? on the gPON system ?)


What other scenarios exist ?


In normal incumbent-only FTTH systems, does the OLT provision a special
IP to the ATA via DHCP and intercepts that traffic to hand off to a
local SIP server and never touches the internet ?

In the USA,  do CLECs have access to homes served only by FTTH ? If so,
how it is accomplisehd ?

RE: SIP on FTTH systems

[Frank Bulk]

In our vendor's implementation, the main access shelf hands out IPs to the
"ATAs" integrated in the ONTs over a separate VLAN.  No PPPoE required.

Frank

-Original Message-
From: Jean-Francois Mezei [mailto:jfmezei_na...@vaxination.ca] 
Sent: Wednesday, February 05, 2014 10:53 PM
To: nanog@nanog.org
Subject: SIP on FTTH systems

Quick question:

I am thinking in a possible wholesale FTTH environment operated by a
telco where the end user is connected to ISP-X via PPPoE.

ONTs have built-in ATAs that can provide POTS service to a house and do
SIP/VoIP over the fibre with QoS system to ensure VoIP traffic gets through.

In a scenario where the data PPPoE connection is done by an external
router, what are the options to operate the VoIP service so that

- VoIP still uses the special lane on the GPON with QoS

- VoIP gets IP from ISP-X and traffic flow via ISP-X so that telco is
not involved in routing such traffic or allocating an IP address ?


Is the only option to program the ONT to establish its own PPPoE session
to the ISP that carries only SIP traffic (and can such a setup make use
of the special "lane" reserved for VoIP traffic ? on the gPON system ?)


What other scenarios exist ?


In normal incumbent-only FTTH systems, does the OLT provision a special
IP to the ATA via DHCP and intercepts that traffic to hand off to a
local SIP server and never touches the internet ?

In the USA,  do CLECs have access to homes served only by FTTH ? If so,
how it is accomplisehd ?

Re: SIP on FTTH systems

[Jean-Francois Mezei]

On 14-02-06 00:07, Frank Bulk wrote:
> In our vendor's implementation, the main access shelf hands out IPs to the
> "ATAs" integrated in the ONTs over a separate VLAN.  No PPPoE required.

Thanks. This would imply that in a wholesale environment,  use of the
integrated ATA would have to be charged separatly with the telco then
handing off SIP traffic from the OLT to (likely) a nearby CLEC SIP
server that is colocated (or pay for transit to internet to reach
distant SIP server)

I know that in the australian NBN plan, they do charge separatly to
access the "dedicated" VoIP service,  but this is meant more as a means
to access the QoS managed bandwidth than to deal with handoff and IP
management service that is performed locally instead of by the ISP.

Re: SIP on FTTH systems

[Måns Nilsson]

Subject: SIP on FTTH systems Date: Wed, Feb 05, 2014 at 11:52:51PM -0500 
Quoting Jean-Francois Mezei (jfmezei_na...@vaxination.ca):
> Quick question:
> 
> I am thinking in a possible wholesale FTTH environment operated by a
> telco where the end user is connected to ISP-X via PPPoE.
> 
> ONTs have built-in ATAs that can provide POTS service to a house and do
> SIP/VoIP over the fibre with QoS system to ensure VoIP traffic gets through.
> 
> In a scenario where the data PPPoE connection is done by an external
> router, what are the options to operate the VoIP service so that
> 
> - VoIP still uses the special lane on the GPON with QoS
> 
> - VoIP gets IP from ISP-X and traffic flow via ISP-X so that telco is
> not involved in routing such traffic or allocating an IP address ?

Or, one could make sure everything has a globally unique IP address and is
using reasonably secured communications. The downside is that one
then can't defend the existence  of those empire-building middleboxes. It
is not the telco way, so is of course unthinkable. Like anything beyond
WAP was on cell phones a decade ago.

Warum soll man es einfach machen, 
wenn man es so schön komplizieren kann?

(Why make things simple when you can 
 build them so beautifully complicated?)

-- 
Måns Nilsson primary/secondary/besserwisser/machina
MN-1334-RIPE +46 705 989668
We are now enjoying total mutual interaction in an imaginary hot tub ...


signature.asc
Description: Digital signature

Re: BCP38 [Was: Re: TWC (AS11351) blocking all NTP?]

[Robert Drake]

On 2/5/2014 1:20 PM, Christopher Morrow wrote:

I here tell the spoofer project people are looking to improve their data
and stats... And reporting.
I know it's not possible due to the limitations of javascript 
sandboxing, but this really needs to be browser based so it can be like 
DNSSEC or MX or IPV6 testing.  Users (and reddit) can be coerced into 
clicking a link if it shows a happy green sign when they pass the test.  
Asking them to download an executable is too much for most of them.


I'd also love a way as a network administrator that I could audit my own 
network.  Even with all the correct knobs tweaked I occasionally find a 
site where someone turned up an interface and forgot some template 
commands, or in the case of gear that doesn't support it there might not 
be a filter on an upstream device even though there should be.


It'd be nice to have a CM profile that would attempt to spoof something 
to a control server then alert if it works.