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

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

Re: SIP on FTTH systems

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

Re: SIP on FTTH systems

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

RE: SIP on FTTH systems

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

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

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

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 sur

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

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

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

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

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

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 l

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

> 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

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

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

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

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

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

-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

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

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". M

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

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

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

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 l

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

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

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

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 cu

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

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

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

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

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

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 net

Re: Comcast NOC contact

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

BCP38 is hard; let's go shopping!

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

Comcast NOC contact

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

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

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 val

Re: BCP38

- 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

POLL: BCP38 Name And Shame

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

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

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

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

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:

Verizon Wireless NOC contact

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

RE: Done a physical security audit lately?

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 lis

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

RE: Done a physical security audit lately?

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

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 physica

Re: [iab-ch...@iab.org: 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 Revi

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

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 66

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

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, "Tech

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

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

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

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

Looking for Time Warner NOC contact

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 is hard, was TWC (AS11351) blocking all NTP?

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 comp

Done a physical security audit lately?

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?

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.

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

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.

RE: Cogent <-> Verizon peering congestion

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

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

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

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

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 cl

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

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

Re: Cisco 7606 CPU Usage Problem

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:

Re: BCP38.info

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 wro

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

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

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

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 impleme

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

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 t

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

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