Comcast RPKI origin validation

[Tony Tauber]

Last week we at Comcast reached some substantial milestones in our RPKI
rollout (validation on inter-provider sessions, ROAs for our address-space).

Jason Livingood and I collaborated on a blog post, FWIW.

https://corporate.comcast.com/stories/improved-bgp-routing-security-adds-another-layer-of-protection-to-network

Please forgive the somewhat less-technical public-facing verbiage.

Thanks for all the support of people inside Comcast, particularly Courtney
Smith, and also folks in the community on this long journey.

(We have lots of address space spread over more than 20 regional networks
as well as our Backbone network which made the ROA part a bit complicated.
I issued over 9k ROAs or about a quarter of ARINs total.)

Cheers,
Tony

https://rpki.cloudflare.com/?ohlcTa=ARIN=18723=statistics=67.160.156.52%2F32=lspec
[image: image.png]

Re: plea for comcast/sprint handoff debug help

[Tony Tauber]

Yes, to Tim and the NLnet Labs folks,

Thanks for responding to the community concerns and experiences.

Tony

On Wed, Nov 11, 2020 at 10:48 AM Christopher Morrow 
wrote:

> On Wed, Nov 11, 2020 at 9:06 AM Tim Bruijnzeels  wrote:
> >
> > Hi Chris, list,
> >
> > > On 10 Nov 2020, at 05:22, Christopher Morrow 
> wrote:
> > >
> > > sure... it's just made one set of decisions. I was hoping with some
> > > discussion we'd get to:
> > > Welp, sure we can fallback and try rsync if we don't see success in
>  time.
> >
> > We will implement fallback in the next release of routinator.
>
> cool thanks!
>
> > We still believe that there are concerns why one may not want to fall
> back, but we also believe that it will be more constructive to have the
> technical discussion on this as part of the ongoing deprecate rsync effort
> in the sidrops working group in the IETF.
> >
>
> I look forward to chatting about this :)
> I think, yes with the coming (so soon!) deprecation of rsync having a
> smooth transition of power from rsync -> rrdp would be great.
>
> thanks for reconsidering!
> -chris
>

Re: plea for comcast/sprint handoff debug help

[Tony Tauber]

On Fri, Nov 6, 2020 at 1:28 AM Christopher Morrow 
wrote:


> I think a way forward here is to offer a suggestion for the software
> folk to cogitate on and improve?
>"What if (for either rrdp or rsync) there is no successful
> update[0] in X of Y attempts,
>attempt the other protocol to sync down to bring the remote PP back
> to life in your local view."
>
>
 100%  Please do this.
 I also agree with Job's pleas to consider this work as part of the plath
outlined in the RSYNC->RRDP transition draft mentioned below.

Tony


> This both allows the RP software to pick their primary path (and stick
> to that path as long as things work) AND
> helps the PP folk recover a bit quicker if their deployment runs into
> troubles.
>


> >
> > > This is a tradeoff. I think that protecting against replay should be
> > > considered more important here, given the numbers and time to fix
> > > HTTPS issue.
> >
> > The 'replay' issue you perceive is also present in RRDP. The RPKI is a
> > *deployed* system on the Internet and it is important for Routinator to
> > remain interopable with other non-nlnetlabs implementations.
> >
> > Routinator not falling back to rsync does *not* offer a security
> > advantage, but does negatively impact our industry's ability to migrate
> > to RRDP. We are in 'phase 0' as described in Section 3 of
> > https://tools.ietf.org/html/draft-sidrops-bruijnzeels-deprecate-rsync
> >
> > Regards,
> >
> > Job
>

Re: plea for comcast/sprint handoff debug help

[Tony Tauber]

As I've pointed out to Randy and others and I'll share here.
We planned, but hadn't yet upgraded our Routinator RP (Relying Party)
software to the latest v0.8 which I knew had some improvements.
I assumed the problems we were seeing would be fixed by the upgrade.
Indeed, when I pulled down the new SW to a test machine, loaded and ran it,
I could get both Randy's ROAs.
I figured I was good to go.
Then we upgraded the prod machine to the new version and the problem
persisted.
An hour or two of analysis made me realize that the "stickiness" of a
particular PP (Publication Point) is encoded in the cache filesystem.
Routinator seems to build entries in its cache directory under either
rsync, rrdp, or http and the rg.net PPs weren’t showing under rsync but
moving the cache directory aside and forcing it to rebuild fixed the issue.

A couple of points seem to follow:

   - Randy says: "finding the fort rp to be pretty solid!"  I'll say that
   if you loaded a fresh Fort and fresh Routinator install, they would both
   have your ROAs.
   - The sense of "stickiness" is local only; hence to my mind the
   protection against "downgrade" attack is somewhat illusory. A fresh install
   knows nothing of history.

Tony

On Fri, Oct 30, 2020 at 11:57 PM Randy Bush  wrote:

> > If there is a covering less specific ROA issued by a parent, this will
> > then result in RPKI invalid routes.
>
> i.e. the upstream kills the customer.  not a wise business model.
>
> > The fall-back may help in cases where there is an accidental outage of
> > the RRDP server (for as long as the rsync servers can deal with the
> > load)
>
> folk try different software, try different configurations, realize that
> having their CA gooey exposed because they wanted to serve rrdp and
> block, ...
>
> randy, finding the fort rp to be pretty solid!
>

Re: Register Now for NANOG 80 Virtual!

[Tony Tauber]

On Fri, Aug 14, 2020 at 4:05 PM Large Hadron Collider <
large.hadron.colli...@gmx.com> wrote:

> Can anyone describe the scholarship process to me please? What does one
> need to demonstrate to be eligible?
>

Ability to collide hadrons at scale may mean you're well on your way...

Alas, I do not know.

Re: ARIN RPKI TAL deployment issues

[Tony Tauber]

Sounds reasonable to me but IANAL, nor an RIR, nor an IXP.

IXPs however do seem to be the sites of some number of recent
mis-originations (putting it as charitably as possible).

Let's try and make it harder for bad actors to do their mischief.

Thanks,
Tony


On Tue, Sep 25, 2018 at 3:36 PM Job Snijders  wrote:

> On Tue, Sep 25, 2018 at 03:07:54PM -0400, John Curran wrote:
> > On Sep 25, 2018, at 1:30 PM, Job Snijders  wrote:
> > >
> > >"""Using the data, we can also see that the providers that have not
> > >downloaded the ARIN TAL. Either because they were not aware that
> > >they needed to, or could not agree to the agreement they have with
> > >it.
> >
> > Is it possible to ascertain how many of those who have not downloaded
> > the ARIN TAL are also publishing ROA’s via RIPE’s CA?
>
> I'm sure we could extend the data set to figure this out. But given the
> assymmetric relation between applying Origin Validation based on RPKI
> data and publishing ROAs, the number will be between 0% and 100% and
> over time may go up or down. So, out of curiosity, what is your
> underlaying question?
>
> (An example: a route server operator generally doesn't originate any BGP
> announcements themselves, but route servers are in an ideal position to
> perform RPKI based BGP Origin Validation.)
>
> What I'm hoping for is that there is a way for the ARIN TAL to be
> included in software distributions, without compromising ARIN's legal
> position.
>
> Perhaps an exception for software distributors would already go a long
> way?
>
> "You can include the ARIN TAL in your software distribution as long
> as you also include an unmodified copy of the
> https://www.arin.net/resources/rpki/rpa.pdf file alongside it."
>
> Kind regards,
>
> Job
>

Re: Proof of ownership; when someone demands you remove a prefix

[Tony Tauber]

On Tue, Mar 13, 2018 at 1:59 PM, Job Snijders  wrote:

> Dear Sean,
>
> On Tue, Mar 13, 2018 at 10:38:49AM -0700, Sean Pedersen wrote:
> > This is more or less the situation we're in. We contacted the customer
> > and they informed us the matter is in dispute with the RIR and that
> > their customer (the assignee) is in the process of resolving the
> > issue. We have to allow them time to accomplish this. I've asked for
> > additional information to help us understand the nature of the
> > dispute. In that time we received another request to stop announcing
> > the prefix(s) in addition to a new set of prefixes, and a threat to
> > contact our upstream providers as well as ARIN - which is not the RIR
> > the disputed resources are allocated to.
>
> I've seen disputes too between end users and RIRs - usually this is due
> to non-payment. It can be helpful to do two things: set a reasonable
> deadline for the customer to resolve this, and verify with the RIR
> whether the dispute is actually ongoing or whether the RIR closed the
> case. Example case: customer said they were in dispute, but RIR
> indicated that the case was closed. If the RIR closed the case, I'd lean
> to dropping the announcement.
>

What are people's experiences with the various RIRs discussion of these
situations?
I believe sometimes (though could be mistaken) they consider these matters
confidential.

Perhaps there are official RIR policies stated on how they handle such.
It can be frustrating I'm sure.
For the situation you describe, I'd be inclined to say that if the RIR's
posted registration matches what you've got and has been so for a while,
that ought to stand.

Tony

Re: Acquiring unused IP range. Some questions

[Tony Tauber]

It would be helpful also if the whois record is updated with the Origin AS
listed.
See ARIN's post on the topic: https://www.arin.net/resources/originas.html

Tony

On Fri, Dec 2, 2016 at 10:08 PM, Faisal Imtiaz 
wrote:

> > My question is, what do they and we need to do to accomplish that in
> > the proper way, so that the internet at large would accept the
> advertisement
> > from a different ASN,
>
> The internet in terms of IP Prefix advertisements is a 'Trust' based
> system.
>
>
> > and not view as some sort of hijacking, etc.
>
> The difference between Hijacking vs a valid advertisement is the simple
> LOA document a.k.a having permission to do so..
>
>
> >  I am guessing they may need to update some RADB or something like that,
> but i’ll be
> > honest my knowledge of how those things work and their complete function
> is
> > pretty slim.
>
>
> Only if you are using it for yourself or if your upstream is using it to
> create their prefix Filter lists.
> RADB is not the only RRDB provider, ARIN also provides this service
>
> > This would be a short term thing as we expect the purchase process to
> complete
> > pretty quickly, but it would be advantageous to us to be able to
> advertise the
> > space immediately.  We just want to make sure we start off on the right
> foot.
> >
>
> All you need is permission from the IP block owner (LOA) and the
> appropriate upstream filters to be setup or opened.
> Which could be a manual process (provide them a copy of the LOA) or could
> be a 'Trust' based using RRDB Record which someone has to create and update.
>
> Best of luck.
>
> Faisal Imtiaz
> Snappy Internet & Telecom
>
>
> - Original Message -
> > From: "William McLendon" 
> > To: "nanog list" 
> > Sent: Friday, December 2, 2016 5:43:57 PM
> > Subject: Acquiring unused IP range.  Some questions
>
> > Hi everyone,
> >
> > we are about to acquire a block of IP’s from another organization that
> has
> > unused space, and being fairly new to these procedures, I was hoping for
> some
> > guidance.
> >
> > We have already been pre-approved by ARIN for the block size we are
> acquiring,
> > and finalizing the deal with the current owner of the address space.
> First
> > question is, once they initiate the transfer request to transfer the IP
> range
> > to us, how long does that typically take for ARIN to complete?
> >
> > Secondly, our relationship with the IP block owner is a very good one,
> such that
> > I think they would be ok with us advertising this block before we
> technically
> > own it.  My question is, what do they and we need to do to accomplish
> that in
> > the proper way, so that the internet at large would accept the
> advertisement
> > from a different ASN, and not view as some sort of hijacking, etc.  I am
> > guessing they may need to update some RADB or something like that, but
> i’ll be
> > honest my knowledge of how those things work and their complete function
> is
> > pretty slim.
> >
> > This would be a short term thing as we expect the purchase process to
> complete
> > pretty quickly, but it would be advantageous to us to be able to
> advertise the
> > space immediately.  We just want to make sure we start off on the right
> foot.
> >
> >
> > Thanks,
> >
> > Will
>

Re: [c-nsp] SFP DOM SNMP Polling?

[Tony Tauber]

I'm no expert in EEPROMs but recall awhile back we had an optical vendor
(transport-side, not router-side) that did do frequent writes (maybe it was
for performance info) to EEPROM and burned them out that way after a couple
of years.  Maybe your vendor is saying they don't support reporting this
way because they would do it via writing to the EEPROM which is bad for
it.  Not saying whether they could do it some different way that would make
it supportable, but who knows.  May be some fundamental
shortcoming/limitation of their design (or their OEM's design).

$0.02
Tony

On Tue, Nov 22, 2016 at 12:11 PM, Michael Loftis  wrote:

> On Tue, Nov 22, 2016 at 6:32 AM, Tim Durack  wrote:
> > I have a vendor that does not support SFP DOM SNMP polling. They state
> this
> > is due to EEPROM read life cycle. Constant reads will damage the SFP.
>
> Complete and total garbage.  Reading from EEPROM and Flash both DO NOT
> WEAR.  It is the erase+write cycle that wears them.  Further typical
> EEPROM life cycle is ~1M erase/write cycles.  If you wrote it every
> minute you could conceivably wear it out in a couple years...but thats
> flat out not how it works.  The EEPROM, if any, is not going to be
> used for statistics datamaybe fail counts of some kind, lifetime
> (hours) maybe...that sort of thing.
>
>
> >
> > We SNMP poll SFP DOM from Cisco equipment without issue.
> >
> > Not heard this one before. Trying to see if there is some validity to the
> > statement. Thoughts?
> >
> > Tim:>
> > ___
> > cisco-nsp mailing list  cisco-...@puck.nether.net
> > https://puck.nether.net/mailman/listinfo/cisco-nsp
> > archive at http://puck.nether.net/pipermail/cisco-nsp/
>
>
>
> --
>
> "Genius might be described as a supreme capacity for getting its possessors
> into trouble of all kinds."
> -- Samuel Butler
>

[NANOG-announce] Fwd: NANOG 66 - San Diego - Call for Presentations is Open!

[Tony Tauber]

Hi folks,

A reminder of today being the due date for Abstracts for NANOG66 in San
Diego.

We'd like to see things submitted the PC Tool <https://pc.nanog.org>.
Don't sweat it if the idea isn't all the way fleshed out.
The PC meets bi-weekly to review submissions and assign a "Shepherd" w/in
the PC to help develop and refine the content.

If you did happen to have materials such as a draft slide deck ready,
please upload it to the PC Tool as well as it helps give the PC a sense of
the scope and level of detail of the proposal.

Thanks,
Tony
Chair, NANOG Program Committee


-- Forwarded message --
From: Tony Tauber <ttau...@1-4-5.net>
Date: Tue, Oct 27, 2015 at 5:07 PM
Subject: NANOG 66 - San Diego - Call for Presentations is Open!
To: nanog-annou...@nanog.org


Greetings NANOG Folks,

The last two NANOG meetings (San Francisco and Montreal) set records for
attendance and we hope and expect the trend of strong attendance numbers to
continue for the NANOG 66 meeting February 8-10, 2016 in San Diego, CA
which will be hosted by IIX, Inc.


The detailed NANOG66 Call For Presentations
<http://nanog.org/meetings/nanog66/callforpresentations> has more info but
below is some information that might be useful for quick digestion.

Cheers,

Tony Tauber
Chair, NANOG Program Committee
===

Timeline for submission and proposal review


   1.

   Submitter enters Abstract (and draft slides if possible) in Program
   Committee Site <https://pc.nanog.org/>.
   1.

  Any time following Call for Presentations and before deadline for
  Abstracts
  2.

   PC performs initial review and assigns a “Shepherd” to help develop the
   submission.
   1.

  Within about 2-3 weeks
  3.

   Submitter develops draft slides (minimally showing proposed outline and
   level of detail).
   1.

  Please submit initial draft slides before published deadline for
  slides
  2.

  Panels and Track submissions should provide topic list and
  intended/confirmed participants
  4.

   PC reviews slides and iteratively works with Submitter to help develop
   topic.
   5.

   PC accepts or declines submission
   6.

   Agenda assembled and posted
   7.

   Submitters notified


If you think you have an interesting topic but want some feedback or
assistance working it into a presentation, please email the Program
Committee <nano...@nanog.org>, and a representative on the Program
Committee will give you the feedback needed to work it into a presentation.
Otherwise, don't delay in submitting your talk, keynote, track, or panel
proposal to the <http://pc.nanog.org/>Program Committee Site
<https://pc.nanog.org/>.  We look forward to reviewing your submission.


Key Dates For NANOG 66

Event/Deadline

Date

Registration for NANOG 66 Opens

Monday, 10/26/2015

CFP Opens for NANOG 66

Monday, 10/26/2015

CFP Deadline #1: Presentation Abstracts Due

Monday, 11/30/2015

CFP Topic List  and NANOG Highlights Page Posted

Friday, 12/18/2015

CFP Deadline #2: Presentation Slides Due

Monday, 1/4/2016

Meeting Agenda Published

Monday, 1/11/2016

Speaker FINAL presentations to Program Committee Site
<https://pc.nanog.org/>

Wednesday, 2/3/2016

On-site Registration

Sunday, 2/7/2016

Lightning Talk Submissions Open (Abstracts Only)

Sunday, 2/7/2016

Further Presentation Guidelines can be found under "Present at a NANOG"
<https://www.nanog.org/meetings/presentation> and some general advice is
available in Tips on Giving a Talk
<https://www.nanog.org/meetings/presentation/tips>.
___
NANOG-announce mailing list
nanog-annou...@mailman.nanog.org
http://mailman.nanog.org/mailman/listinfo/nanog-announce

[NANOG-announce] NANOG 66 - San Diego - Call for Presentations is Open!

[Tony Tauber]

Greetings NANOG Folks,

The last two NANOG meetings (San Francisco and Montreal) set records for
attendance and we hope and expect the trend of strong attendance numbers to
continue for the NANOG 66 meeting February 8-10, 2016 in San Diego, CA
which will be hosted by IIX, Inc.


The detailed NANOG66 Call For Presentations
<http://nanog.org/meetings/nanog66/callforpresentations> has more info but
below is some information that might be useful for quick digestion.

Cheers,

Tony Tauber
Chair, NANOG Program Committee
===

Timeline for submission and proposal review


   1.

   Submitter enters Abstract (and draft slides if possible) in Program
   Committee Site <https://pc.nanog.org/>.
   1.

  Any time following Call for Presentations and before deadline for
  Abstracts
  2.

   PC performs initial review and assigns a “Shepherd” to help develop the
   submission.
   1.

  Within about 2-3 weeks
  3.

   Submitter develops draft slides (minimally showing proposed outline and
   level of detail).
   1.

  Please submit initial draft slides before published deadline for
  slides
  2.

  Panels and Track submissions should provide topic list and
  intended/confirmed participants
  4.

   PC reviews slides and iteratively works with Submitter to help develop
   topic.
   5.

   PC accepts or declines submission
   6.

   Agenda assembled and posted
   7.

   Submitters notified


If you think you have an interesting topic but want some feedback or
assistance working it into a presentation, please email the Program
Committee <nano...@nanog.org>, and a representative on the Program
Committee will give you the feedback needed to work it into a presentation.
Otherwise, don't delay in submitting your talk, keynote, track, or panel
proposal to the <http://pc.nanog.org/>Program Committee Site
<https://pc.nanog.org/>.  We look forward to reviewing your submission.


Key Dates For NANOG 66

Event/Deadline

Date

Registration for NANOG 66 Opens

Monday, 10/26/2015

CFP Opens for NANOG 66

Monday, 10/26/2015

CFP Deadline #1: Presentation Abstracts Due

Monday, 11/30/2015

CFP Topic List  and NANOG Highlights Page Posted

Friday, 12/18/2015

CFP Deadline #2: Presentation Slides Due

Monday, 1/4/2016

Meeting Agenda Published

Monday, 1/11/2016

Speaker FINAL presentations to Program Committee Site
<https://pc.nanog.org/>

Wednesday, 2/3/2016

On-site Registration

Sunday, 2/7/2016

Lightning Talk Submissions Open (Abstracts Only)

Sunday, 2/7/2016

Further Presentation Guidelines can be found under "Present at a NANOG"
<https://www.nanog.org/meetings/presentation> and some general advice is
available in Tips on Giving a Talk
<https://www.nanog.org/meetings/presentation/tips>.
___
NANOG-announce mailing list
nanog-annou...@mailman.nanog.org
http://mailman.nanog.org/mailman/listinfo/nanog-announce

[NANOG-announce] NANOG 65 - Montréal - Call for Presentations is Open!

[Tony Tauber]

Hello NANOG Folks,

Thanks to all those who made NANOG 64 in San Francisco our largest meeting
ever (by well over 25% margin)!

Our 65th meeting will be held in Montréal, Quebec on June 5-7th.
Our meeting sits between the DNS-OARC workshop (Sat-Sun) and the ARIN 36
meeting (Thu-Fri) so will be ripe for fruitful interaction among these
various constituencies.

The NANOG Program Committee is now seeking proposals for presentations,
panels, tutorials, tracks sessions, and keynote materials for the NANOG 65
program. We invite presentations highlighting issues relating to technology
already deployed or soon-to-be deployed in the Internet, . Vendors are
encouraged to work with operators to present real-world deployment
experiences with the vendor's products and interoperability.  Key dates to
track if you wish to submit a presentation:

Key Dates For NANOG 65

Event/Deadline

Date

Registration for NANOG 65 Opens

Monday, 6/29/2015

CFP Opens for NANOG 65

Monday, 6/29/2015

CFP Deadline #1: Presentation Abstracts Due

Monday, 7/27/2015

CFP Topic List  and NANOG Highlights Page Posted

Friday, 8/14/2015

CFP Deadline #2: Presentation Slides Due

Monday, 8/31/2015

Meeting Agenda Published

Monday, 9/7/2015

Speaker FINAL presentations to PC Tool https://pc.nanog.org/

Friday, 10/2/2015

On-site Registration

Sunday, 10/4/2015

Lightning Talk Submissions Open (Abstracts Only)

Saturday, 10/3/2015

NANOG 65 submissions are welcome on the Program Committee Site
https://pc.nanog.org/ or email me if you have questions.

See the detailed NANOG65 Call for Presentations
https://www.nanog.org/meetings/nanog65/callforpresentations for more
information.


Thanks,

Tony Tauber
Chair, Program Committee
North American Network Operator Group (NANOG)
___
NANOG-announce mailing list
nanog-annou...@mailman.nanog.org
http://mailman.nanog.org/mailman/listinfo/nanog-announce

Re: [NANOG-announce] NANOG 65 - Montréal - Call for Presentations is Open!

[Tony Tauber]

Dang!  Yes, correct.  It's October 5-7th.

Our 65th meeting will be held in Montréal, Quebec on June 5-7th.


Thanks for the eagle eyes out there.


Tony
___
NANOG-announce mailing list
nanog-annou...@mailman.nanog.org
http://mailman.nanog.org/mailman/listinfo/nanog-announce

Re: BCOP appeals numbering scheme -- feedback requested

[Tony Tauber]

Totally.  Also, then what if something is in the intersection of multiple
areas.

Complexity that's not needed.

Tony

On Thu, Mar 12, 2015 at 3:12 PM, Job Snijders j...@instituut.net wrote:

 On Mar 12, 2015 8:08 PM, joel jaeggli joe...@bogus.com wrote:
 
  On 3/12/15 12:01 PM, Yardiel D. Fuentes wrote:
   In the above page, the idea is to introduce a 100-th range for each
 category and as the BCOPs. This way a 100th number range generally
 identifies each of the categories we currently have. An example is:
 
  identifier/locator overload.
 
  giving intergers intrinsic meaning is generally a mistake imho.

 I agree with Joel

[NANOG-announce] NANOG 64 - San Francisco - Call for Presentations is Open!

[Tony Tauber]

Greetings NANOG Folks,

NANOG 63 in San Antonio is still a fairly fresh memory (for those who were
there).

NANOG will hold its 64th meeting in San Francisco, CA on June 1-3, 2015,
hosted by Netflix.

The NANOG Program Committee is now seeking proposals for presentations,
panels, tutorials, tracks sessions, and keynote materials for the NANOG 64
program. We invite presentations highlighting issues relating to technology
already deployed or soon-to-be deployed in the Internet, . Vendors are
encouraged to work with operators to present real-world deployment
experiences with the vendor's products and interoperability.  Key dates to
track if you wish to submit a presentation:



 Key Dates For NANOG 64

Event/Deadline

Date

Registration for NANOG 64 Opens

March 2, 2015 (Monday)

CFP Opens for NANOG 64

March 2, 2015 (Monday)

CFP Deadline #1: Presentation Abstracts Due

March 30, 2015 (Monday)

CFP Topic List  and NANOG Highlights Page Posted

April 13, 2015 (Monday)

CFP Deadline #2: Presentation Slides Due

April 27, 2015 (Monday)

Meeting Agenda Published

May 4, 2015 (Monday)

Speaker FINAL presentations to PC Tool https://pc.nanog.org/

May 29, 2015 (Friday)

On-site Registration

May 31, 2015 (Sunday)

Lightning Talk Submissions Open (Abstracts Only)

June 1, 2015 (Monday)














NANOG 64 submissions are welcome on the Program Committee Site
https://pc.nanog.org/ or email me if you have questions.

See the detailed NANOG64 Call for Presentations
https://www.nanog.org/meetings/nanog63/callforpresentations for more
information.

You can also view the NANOG events calendar
https://www.google.com/calendar/embed?src=newnog.org_n52e4de4cce58v1lv41m6o0u68%40group.calendar.google.comctz=America/Los_Angeles
(including the key dates above and more) import in ICS format
https://www.google.com/calendar/ical/newnog.org_n52e4de4cce58v1lv41m6o0u68%40group.calendar.google.com/public/basic.ics
.

Thanks,

Tony Tauber
Chair, Program Committee
North American Network Operator Group (NANOG)
___
NANOG-announce mailing list
nanog-annou...@mailman.nanog.org
http://mailman.nanog.org/mailman/listinfo/nanog-announce

[NANOG-announce] Fwd: CFP Test

[Tony Tauber]

Greetings NANOG Folks,

NANOG 63 in San Antonio is still a fairly fresh memory (for those who were
there).

NANOG will hold its 64th meeting in San Francisco, CA on June 1-3, 2015,
hosted by Netflix.

The NANOG Program Committee is now seeking proposals for presentations,
panels, tutorials, tracks sessions, and keynote materials for the NANOG 64
program. We invite presentations highlighting issues relating to technology
already deployed or soon-to-be deployed in the Internet, . Vendors are
encouraged to work with operators to present real-world deployment
experiences with the vendor's products and interoperability.  Key dates to
track if you wish to submit a presentation:



 Key Dates For NANOG 64

Event/Deadline

Date

Registration for NANOG 64 Opens

March 2, 2015 (Monday)

CFP Opens for NANOG 64

March 2, 2015 (Monday)

CFP Deadline #1: Presentation Abstracts Due

March 30, 2015 (Monday)

CFP Topic List  and NANOG Highlights Page Posted

April 13, 2015 (Monday)

CFP Deadline #2: Presentation Slides Due

April 27, 2015 (Monday)

Meeting Agenda Published

May 4, 2015 (Monday)

Speaker FINAL presentations to PC Tool https://pc.nanog.org/

May 29, 2015 (Friday)

On-site Registration

May 31, 2015 (Sunday)

Lightning Talk Submissions Open (Abstracts Only)

June 1, 2015 (Monday)














NANOG 64 submissions are welcome on the Program Committee Site
https://pc.nanog.org/ or email me if you have questions.

See the detailed NANOG64 Call for Presentations
https://www.nanog.org/meetings/nanog63/callforpresentations for more
information.

You can also view the NANOG events calendar
https://www.google.com/calendar/embed?src=newnog.org_n52e4de4cce58v1lv41m6o0u68%40group.calendar.google.comctz=America/Los_Angeles
(including the key dates above and more) import in ICS format
https://www.google.com/calendar/ical/newnog.org_n52e4de4cce58v1lv41m6o0u68%40group.calendar.google.com/public/basic.ics
.

Thanks,

Tony Tauber
Chair, Program Committee
North American Network Operator Group (NANOG)
___
NANOG-announce mailing list
nanog-annou...@mailman.nanog.org
http://mailman.nanog.org/mailman/listinfo/nanog-announce

Re: Comcast New England dropped for 5-15 min? Anyone

[Tony Tauber]

Hi folks,

There was a problem with some prefixes New England rerouting properly
during a topology change.
We feel that problem has been corrected and would like to know if there
were other problems seen overnight (after  UTC) in that region.
If you send to me, please include specific time and source/destination IP
address information.

Thanks,
Tony

On Wed, Feb 11, 2015 at 1:50 PM, Chuck Anderson c...@wpi.edu wrote:

 I saw a problem only with my 50.176.16.0/21 subnet IP.  My
 24.147.20.0/21 subnet IP was working fine throughout.

 On Wed, Feb 11, 2015 at 01:44:53PM -0500, Robert Webb wrote:
  Looks like there were at least a couple of others that saw issues also.
 
 
 http://www.dslreports.com/forum/r29852647-Connectivity-Comcast-down-Quincy-MA
 
  Robert
 
  On Tue, 10 Feb 2015 21:52:29 -0500
   Andrey Khomyakov khomyakov.and...@gmail.com wrote:
  My boss has comcast at home in Milton, MA, said all was fine. Must
  have
  been prefix specific. Trace would die somewhere in level3 at the
  time. Was
  tracing to 8.8.8.8
  
  On Tuesday, February 10, 2015, Dan Brisson dbris...@uvm.edu wrote:
  
  FWIW...no problems here in Vermont on Comcast business.
  
  -dan
  
  
  Dan Brisson
  Network Engineer
  University of Vermont
  
  
  On 2/10/15 8:45 PM, Kevin Kadow wrote:
  
  On Tue, Feb 10, 2015 at 7:27 PM, Andrey Khomyakov 
  khomyakov.and...@gmail.com wrote:
  
   Hey, anyone had problems just now? My team and I at homes
  lost internet
  access for about 10 min. I also had many sites drop off.
  Still digging,
  but
  maybe trouble upstream? I'm in 50.133.128.0/17 at home.
  
   You were only out for 10-15 minutes?  More like an hour in New
  Hampshire.
  
  traceroutes would die out in Needham, Woburn, or  whatever
  4.68.127.229
  is.

Re: [NANOG-announce] NANOG 63 - San Antonio - Call for Presentations is Open!

[Tony Tauber]

Hi folks,

I'm writing as a reminder that the NANOG Program Committee is still
soliciting proposals for NANOG63.
This Friday, December 5th, is when we'd like to have at least an Abstract
posted to the PC Tool https://pc.nanog.org website.
The Abstract needn't be that detailed but then we on the PC can reach out
to you and work to help develop your ideas.
If it's possible to post some draft slides as well, that would help us
further.

In either case, don't worry at this point that the submission is finalized
or polished; that can come later.

We look forward to hearing from you.
As always, send questions either to the PC nano...@nanog.org or to me.

Thanks,
Tony

On Mon, Oct 27, 2014 at 5:20 PM, Tony Tauber ttau...@1-4-5.net wrote:

 Greetings NANOG Folks,

 It was great to see so many of you (~700) at NANOG 62 in Baltimore.
 NANOG will hold its 63rd meeting in San Antonio, TX on February 2-4, 2015,
 hosted by CyrusOne.

 The NANOG Program Committee is now seeking proposals for presentations,
 panels, tutorials, tracks sessions, and keynote materials for the NANOG 63
 program. We invite presentations highlighting issues relating to technology
 already deployed or soon-to-be deployed in the Internet, . Vendors are
 encouraged to work with operators to present real-world deployment
 experiences with the vendor's products and interoperability.  Key dates to
 track if you wish to submit a presentation:

 Date Event/Deadline  Oct. 27, 2014 CFP Opens for NANOG 63  Dec. 05, 2014 CFP
 Deadline #1: Presentation Abstracts Due  Dec. 12, 2014 CFP Topic List
 Posted  Jan. 02, 2015 CFP Deadline #2: Presentation Slides Due  Jan. 09,
 2015 Meeting Agenda Published  Jan. 30, 2015 Speaker FINAL presentations
 to PCTool or speaker-support  Feb. 02, 2015 Lightning Talk Submissions
 Open (Abstracts Only)
 NANOG 63 submissions are welcome on the Program Committee Site
 https://pc.nanog.org/ or email me if you have questions.

 See the detailed NANOG63 Call for Presentations
 https://www.nanog.org/meetings/nanog63/callforpresentations for more
 information.

 Let's see each other in San Antonio where, apparently, the typical high
 temps in February are 65F/18C.

 Thanks,

 Tony Tauber
 Chair, Program Committee
 North American Network Operator Group (NANOG)

___
NANOG-announce mailing list
nanog-annou...@mailman.nanog.org
http://mailman.nanog.org/mailman/listinfo/nanog-announce

[NANOG-announce] NANOG 63 - San Antonio - Call for Presentations is Open!

[Tony Tauber]

Greetings NANOG Folks,

It was great to see so many of you (~700) at NANOG 62 in Baltimore.
NANOG will hold its 63rd meeting in San Antonio, TX on February 2-4, 2015,
hosted by CyrusOne.

The NANOG Program Committee is now seeking proposals for presentations,
panels, tutorials, tracks sessions, and keynote materials for the NANOG 63
program. We invite presentations highlighting issues relating to technology
already deployed or soon-to-be deployed in the Internet, . Vendors are
encouraged to work with operators to present real-world deployment
experiences with the vendor's products and interoperability.  Key dates to
track if you wish to submit a presentation:

Date Event/Deadline  Oct. 27, 2014 CFP Opens for NANOG 63  Dec. 05, 2014 CFP
Deadline #1: Presentation Abstracts Due  Dec. 12, 2014 CFP Topic List
Posted  Jan.
02, 2015 CFP Deadline #2: Presentation Slides Due  Jan. 09, 2015 Meeting
Agenda Published  Jan. 30, 2015 Speaker FINAL presentations to PCTool or
speaker-support  Feb. 02, 2015 Lightning Talk Submissions Open (Abstracts
Only)
NANOG 63 submissions are welcome on the Program Committee Site
https://pc.nanog.org/ or email me if you have questions.

See the detailed NANOG63 Call for Presentations
https://www.nanog.org/meetings/nanog63/callforpresentations for more
information.

Let's see each other in San Antonio where, apparently, the typical high
temps in February are 65F/18C.

Thanks,

Tony Tauber
Chair, Program Committee
North American Network Operator Group (NANOG)
___
NANOG-announce mailing list
nanog-annou...@mailman.nanog.org
http://mailman.nanog.org/mailman/listinfo/nanog-announce

Re: question about bogon prefix

[Tony Tauber]

On Tue, Jun 10, 2014 at 12:57 AM, Robert Drake rdr...@direcpath.com wrote:



snip


 My guess is one of two things.  Maybe they renumbered out of the /20 but
 left a VPN server up and haven't managed to migrate off it yet, but they
 have asked to return the block.. or, they forgot to pay their bill to ARIN
 and the block has been removed from whois but Qwest isn't as diligent
 because they're still being paid.


This brings up a good point which came to mind recently.

What process(es) do folks use for cases where an address block and/or ASN
seems no longer have whois info associated (eg. where authorization to use
may have been revoked)?
Do the RIRs have a process for notifying the community or at least the
upstream providers that something has changed?

Thanks for insight from the community.

Tony

Re: BGPMON Alert Questions

[Tony Tauber]

On Thu, Apr 10, 2014 at 9:26 AM, Mark Tinka mark.ti...@seacom.mu wrote:

 On Thursday, April 10, 2014 12:30:51 PM Randy Bush wrote:

  as folk start to roll out rejection of invalids, we might
  think about how we report problems with folk registering
  inadequate roas, covering their customers, covering
  their deaggs (maybe deaggs get what they deserve), etc.
  if they are not clued enough to generate prudent roas,
  they will not be clued enough to generate ghostbusters
  (and neither ripe's nor apnic's software supports gbrs
  today).

 snip


 It would be useful to use BGPmon's free RPKI validation
 feature, which e-mails you, incessantly, about validation
 failures due to un-ROA'd de-aggregates.


This seems like good idea and would also be good to know how else to know
I've broken something..

There's a BGP Visibility Project http://visibility.it.uc3m.es/
which perhaps could be brought to bear.

Other thoughts out there?

Tony

Re: BGPMON Alert Questions

[Tony Tauber]

On Thu, Apr 3, 2014 at 11:13 AM, Christopher Morrow morrowc.li...@gmail.com
 wrote:

 On Thu, Apr 3, 2014 at 11:05 AM, Mark Tinka mark.ti...@seacom.mu wrote:
  On Thursday, April 03, 2014 03:55:11 PM Christopher Morrow
  wrote:
 
  I'm going to guess:
1) who's going to pay for the filtering setup work?
 
  Well, your customers are paying you to ensure they don't get
  cut off due to your negligence.

 I think you mean they are paying me to carry their bits across the
 network...
 and they are paying me to do it with minimal hassle to THEM... telling
 me prefixes to add to their list is hassle.


I know this old saw and sales people will apply pressure to Ops if their
customers balk at the extra overhead.
The time is now to push back, hard, against that practice.
I realize you know this, Chris but are trying to characterize the mindset.


  The new strategy is not just
  shiny, it could actually save you loss of customers and
  community respect.

 agreed.

 
  But that's just me...

 it's not just you


Yes, let's seize the bull by the horns.

Tony

Re: Everyone should be deploying BCP 38! Wait, they are ....

[Tony Tauber]

I agree that Barry's post can be read in misleading ways and I seem to
recall chatting about that with him at some point.

As to one poster's comment about random sampling, I'm pretty sure the
Spoofer project likely fell short in a number of ways (e.g. being
documented in not every language).

So, if NATs prevent (many? most?) end-user machines for being able inject
spoofed IPv4 source addresses (IPv6 home gateways may well not provide such
protection), maybe we should conclude that most of the spoofing is coming
from somewhere else; perhaps including colo and cloud providers.

I wonder how many users/admins of those kinds of machines ran the Spoofer
test SW.

Tony


On Tue, Feb 18, 2014 at 2:22 PM, Jared Mauch ja...@puck.nether.net wrote:


 On Feb 18, 2014, at 1:40 PM, Patrick W. Gilmore patr...@ianai.net wrote:

  Barry is a well respected security researcher. I'm surprised he posted
 this.
 
  In his defense, he did it over a year ago (June 11, 2012). Maybe we
 should ask him about it. I'll do that now

 I'm not surprised in any regard.  There are too many names for BCP-38,
 SAV, SSAC-004, BCP-84, Ingress Filtering, etc..

 There are many networks that perform this best practice either by
 default through NAT/firewalls or by explicit configuration of the devices.

 There are many networks that one will never be able to measure nor audit
 as well, but that doesn't mean we shouldn't continue to work on tracking
 back spoofed packets and reporting the attacks, and securing devices.

 - Jared

Re: Question on Route-Set for Arin DB

[Tony Tauber]

The origin stands alone; no aut-num needed in many cases.

The way many providers use the IRR info is to take the adjacent ASN and do
a reverse index lookup on the origin field.
That is, for AS1234, what are all the route and route6 objects with that as
an origin.
If you need something more complicated, you can use an aut-num object to
say that an as-set, route-set or combinations of these ought to be folded
in when creating the filters.

Tony


On Thu, Feb 13, 2014 at 6:30 PM, Faisal Imtiaz fai...@snappytelecom.netwrote:

 I am a newbie at it as well, having said that.. the short answer to your
 question is  YES to aut-num and NO to  route-set ..
 but the longer answer will always be based on how you are using the IRR

 If you are doing this for the most common, basic reason, that one of your
 upstream is requiring it.. then you may have to ask them.
  (in most cases aut-num for your ASN and route object for your routes is
 needed at minimum)

 BTW, I am curious, if you did not create an aut-num object, what did you
 enter as origin: for your route objects ?


 Regards

 Faisal Imtiaz
 Snappy Internet  Telecom
 7266 SW 48 Street
 Miami, FL 33155
 Tel: 305 663 5518 x 232

 Help-desk: (305)663-5518 Option 2 or Email: supp...@snappytelecom.net

 - Original Message -
  From: Joseph Jenkins j...@breathe-underwater.com
  To: nanog@nanog.org
  Sent: Thursday, February 13, 2014 5:28:39 PM
  Subject: Question on Route-Set for Arin DB
 
  So the Routing Database is something that I am just learning about and
 trying
  to find out if I need to create a Route-set or not.  I just created my
  MNTNER ID and I also created the Route Objects for my two /24s that were
  given to my by my carriers.  Do I need a route-set or aut-num object
  created?
 
  Still trying to get my head wrapped around the need for this.  I read
 through
  this tutorial:
 
 
 http://www.nanog.org/meetings/nanog51/presentations/Sunday/NANOG51.Talk34.NANOG51%20IRR%20Tutorial.pdf
 
  and didn't get a really clear idea as to if I needed these.
 
  TIA,
 
  Joe
 

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

[Tony Tauber]

On Tue, Feb 4, 2014 at 1:47 PM, valdis.kletni...@vt.edu wrote:


 Can somebody explain to me why those who run eyeball networks are able
 to block outbound packets when the customer hasn't paid their bill,
 but can't seem to block packets that shouldn't be coming from that
 cablemodem?


The DOCSIS spec has source address verification (as I understand it, for
about a decade.)
It is deployed within at least one large cable access provider network I am
familiar with (though I don't personally work on the DOCSIS side of things).

Why don't enterprises, hosting and cloud providers do it?  (I don't know
that they don't, but I figured I'd just keep with the tone.)
Enterprises know what prefixes they have so should drop outbound packets
with source IPs other than those, right?
Likewise hosting providers ought to put in some safeguards.
What about cloud providers who also provide virtual OSes and other
software?
Are those VMs and their third-party software kept patched?

All those folks also provide access at the network edge.

Tony

Re: BCP38.info

[Tony Tauber]

Good stuff on this topic assembled by Barry Greene here:
http://confluence.senki.org/pages/viewpage.action?pageId=1474569

Tony


On Sat, Jan 25, 2014 at 7:57 PM, Chris Grundemann cgrundem...@gmail.comwrote:

 Perhaps instead of trying to do this as a new independent activity (with
 all of the difficulties that entails), the community would be better served
 by documenting this information as a BCOP or two or three???

  http://bcop.nanog.org/ 

 $0.02
 ~Chris




 On Sun, Jan 26, 2014 at 4:08 AM, Jay Ashworth j...@baylink.com wrote:

  Well, coming up with a Mediawiki registration protocol that's hard to
  spam is apparently more difficult than I'd thought.
 
  For the moment, anyone who wants to contribute to the wiki, and to the
  expanded deployment of BCP38, is invited to toss a note to moderator [at]
  bcp38.info with a username, and we'll tell it to set you up an account
 and
  mail you a password manually.
 
  Sorry for the speedbump.
 
  I just want to tell you good luck.  We're all counting on you.
 
  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
 
 


 --
 @ChrisGrundemann
 http://chrisgrundemann.com

Re: How big is the Internet?

[Tony Tauber]

All this goes to the point that the original question was poorly worded and
I daresay ill-conceived.
There's no one number or one metric, much less one definition.
It all depends on what the real question is that you're trying to answer
and why.

There is plenty of room for study; though it's necessary to start with some
circumscribed question.
Of course the answers you may get won't likely then be readily applicable
to answering some other question that may come in the future.

Tony


On Thu, Aug 15, 2013 at 12:30 PM, Scott Howard sc...@doc.net.au wrote:

 You'd almost think this was a technology mailing list given some of the
 answers...  (ohh.. wait!)

 How about this - the size of the Internet is just short of 3 billion.

 That's the number of people that have access to it.  To me, that's a far
 more telling number than anything around IP address or Exabytes of data.

   Scott

Re: 204.17.16.0/20 Unreachable via Comcast ASN 7992; Looking for Help or Contacts

[Tony Tauber]

It's a fair question and had nothing to do with the other network (TW
Telecom, in this case, not TIme Warner Cable).
Sorry for not filling in details sooner.

We recently needed to adjust the scale profile on some of our Cisco ASR9k
trident chip (80gig) Line Cards as we reached . The default profile only
supports up to 512k routes and will notify that CEF has run out of
DATA_TYPE_TABLE_SET space as a result. The profile change required (profile
13) requires a reload of the chassis. please be advised.  You might want to
review with your local support team.

The symptom involved BGP neighbor instability and unreachability of some
destinations.
Shutting down that particular BGP session was a temporary work-around until
the adjustment could be made during a demand maintenance window to minimize
disruption.

Thanks,
Tony


On Wed, Aug 7, 2013 at 5:31 PM, Phil Fagan philfa...@gmail.com wrote:

 BGP Noob question here; but wouldn't Time Warner not recieve a prefix if it
 wasn't reachable? Is this an artifact?


 On Mon, Aug 5, 2013 at 11:32 AM, Chad Reid chad.r...@apollogrp.edu
 wrote:

  Thanks for the assistance everyone. This issue was resolved by shutting
  down a BGP peering session between Time Warner and Comcast. --Chad
 
  Chad M. Reid, Network Administrator II
  Work Hours: Sun. - Tue. 6AM-6PM and  Wed. 6AM-3PM (MST -7)
  Apollo Group | IT Services │ IT Operations Center (ITOC)
  4025 S. Riverpoint Parkway │ MS: AA-M002 │ Phoenix, AZ 85040
  phone: 602.557.6746 │ fax: 602.557.6606 │ email: chad.r...@apollogrp.edu
 
 
  -Original Message-
  From: Chad Reid
  Sent: Sunday, August 04, 2013 7:41 AM
  To: 'nanog@nanog.org'
  Subject: 204.17.16.0/20 Unreachable via Comcast ASN 7992; Looking for
  Help or Contacts
 
  Hello NANOG,
 
  A few hundred of our users that use Comcast in the South East United
  States (other regions aren't affected) are unable to access our websites
 in
  the IP block 204.17.16.0/20. Based upon testing with the users, they're
  getting a destination unreachable from a Comcast backbone router in ASN
  7922:
  be-16-pe03.56marietta.ga.ibone.comcast.net [68.86.83.134] reports:
  Destination net unreachable.
 
  We're not a customer of Comcast, nor are any of our ISPs. Because of
 this,
  we can't find anyone at Comcast to look at this issue nor do we have good
  contact info to even reach someone. Our users in the South East can open
  tickets with Comcast technical support, but you can imagine how
 successful
  they are trying to explain this to frontline support and getting
 frontline
  support to understand.
 
  Is anyone from Comcast on the list that can assist or know of a contact?
 
 
  Chad M. Reid, Network Administrator II
  Work Hours: Sun. - Tue. 6AM-6PM and  Wed. 6AM-3PM (MST -7) Apollo Group |
  IT Services │ IT Operations Center (ITOC)
  4025 S. Riverpoint Parkway │ MS: AA-M002 │ Phoenix, AZ 85040
  phone: 602.557.6746 │ fax: 602.557.6606 │ email: chad.r...@apollogrp.edu
 
 
 
  This message is private and confidential. If you have received it in
  error, please notify the sender and remove it from your system.
 
 
 
 


 --
 Phil Fagan
 Denver, CO
 970-480-7618

Re: 32-bit ASes at routeviews

[Tony Tauber]

+1

On Tue, Dec 18, 2012 at 9:23 PM, Randy Bush ra...@psg.com wrote:

  Off topic, this reminds me I would rather have ASPLAIN
  again.  We switched a couple of years ago on a particular
  user request.

 listening to those pesky users, eh?

  If there is no objection, I would love to switch back
  ASAP.  This would be on route-views, and on route-views3.
  Just asking if others concur?

 makes sense to me

 randy

Re: Are NAT'ed networks part of the Internet?

[Tony Tauber]

 Are networks behind NAT/ALG or that use RFC 1918 or the v6 equivalent
 address space,
 part of the 'Internet' or are they in networks where access to
 addresses/service ports
 must be explicitly granted?


RFC4084 (Terminology for Describing Internet
Connectivity)http://tools.ietf.org/html/rfc4084,
IMHO, does a decent job of trying to enumerate/unpack these kinds of
questions.
I'm sure it's not uncontroversial, but may provide some common vocabulary.

Tony

Re: ROVER routing security - its not enumeration

[Tony Tauber]

Shane A. gave a Lightning Talk the slides for which will be posted at some
time soon.
They came in at the last minute which is why they're not up already.

Tony

On Tue, Jun 5, 2012 at 3:28 PM, Christopher Morrow
morrowc.li...@gmail.comwrote:

 On Tue, Jun 5, 2012 at 2:42 PM, Daniel Massey mas...@cs.colostate.edu
 wrote:


  ROVER is not trying to do exactly what RPKI is doing.  Much of this
 seems to be an
  attempt to build a form of enumeration into ROVER.See the Level3
 NANOG talk
  from Monday (6/4/12) for a concrete example of a different model.
  There are many different

 you referenced this a few times:
  http://www.nanog.org/meetings/nanog55/agenda.php

 doesn't mention a talk from L3 on 6/4 ... got link?

 -chris

Re: Problems getting to Verisign's whois server on IPv6

[Tony Tauber]

Path is not the same, but the last few replies similarly suggest
packet-filters (!X in my case vs. !P).
I can get to the whois port (TCP/43):

$ telnet -6 2001:503:3227:1060::74 whois
Trying 2001:503:3227:1060::74...
Connected to 2001:503:3227:1060::74.
Escape character is '^]'.

Can you?

Tony

On Tue, May 1, 2012 at 8:01 AM, TR Shaw ts...@oitc.com wrote:

 Anyone else having problems getting to Verisign's whois server on IPv6?

 $ host com.whois-servers.net
 com.whois-servers.net is an alias for whois.verisign-grs.com.
 whois.verisign-grs.com has address 199.7.59.74
 whois.verisign-grs.com has IPv6 address 2001:503:3227:1060::74

 $ traceroute6 2001:503:3227:1060::74
 traceroute6 to 2001:503:3227:1060::74 (2001:503:3227:1060::74) from
 2001:470:5:4ed:cabc:c8ff:fea1:560c, 64 hops max, 12 byte packets
  1  2001:470:5:4ed:226:bbff:fe6d:426e  0.311 ms  0.374 ms  0.260 ms
  2  ipv6oitc-1.tunnel.tserv12.mia1.ipv6.he.net  21.128 ms  21.052 ms
  17.389 ms
  3  gige-g2-3.core1.mia1.he.net  20.055 ms  16.198 ms  22.699 ms
  4  10gigabitethernet4-3.core1.atl1.he.net  40.166 ms  33.887 ms  32.547
 ms
  5  10gigabitethernet6-4.core1.ash1.he.net  49.821 ms  45.999 ms  52.751
 ms
  6  2001:504:0:2::2641:1  47.197 ms  46.748 ms  47.289 ms
  7  xe-1-2-0.r1.bb-fo.chi2.vrsn.net  65.094 ms
xe-0-2-0.r2.bb-fo.chi2.vrsn.net  66.441 ms
xe-1-2-0.r1.bb-fo.chi2.vrsn.net  66.320 ms
  8  2001:503:3227:14ff::2  66.448 ms
2001:503:3227:13ff::2  101.761 ms  86.864 ms
  9  2001:503:3227:13ff::2  69.818 ms !P
2001:503:3227:14ff::2  69.311 ms !P
2001:503:3227:13ff::2  68.662 ms !P

Re: Common operational misconceptions

[Tony Tauber]

Not understanding RFC1918 also gets my vote.
Don't call them unroutable, ever.
I like it when I hear people say if you type a net 10 address into a
router, it will reject it.
What do they think people do with those networks anyway?
Call them private or RFC1918 networks/address spaces/ranges.

I don't know if it's really a common misconception, but worth underlining
to people, especially in these days of IPv4 kinkiness, the expectation of
global address uniqueness in the IP model.  (Yes, NATs are probably here to
stay, but they corrupt the model in a number of ways and hacks result.)

Encourage people to use technically precise language.
When reporting or discussing problems, at the IP layer at least, always get
the answers to these questions:

   - What is the source IP addresses (including external NAT IP if
   applicable)?
   - What is the destination IP address
   - What is the application being used?
   - What is the error message or behavior if any?
   - Did this ever work and, if so, what date and time did it stop working?

Tony

On Wed, Feb 15, 2012 at 10:26 PM, Charles Mills w3y...@gmail.com wrote:

 Not understanding RFC1918.  Actually got read the riot act by someone
 because I worked for an organization that used 10.0.0.0/8 and that was
 their network and they owned it.

 Chuck

Re: Common operational misconceptions

[Tony Tauber]

Right, asymmetric paths are the norm for many inter-provider
communications.
A related misconception is that asymmetric paths are problematic.
Another mis-conception related to path is that more (visible) hops are bad
with the corollary that routers introduce (significant) latency.
Of course, propagation delay is the most significant contributor to latency
in WAN environments (or serialization delay for low-speed links).

Tony

On Thu, Feb 16, 2012 at 3:35 PM, Wayne E Bouchard w...@typo.org wrote:

 Or more to the point, it is a misconception that traffic is
 symetrical (the path out and the path back are the same) whereas in
 the present network, symetrical paths are the exception rather than
 the rule, especially as your radius increases.

 On Wed, Feb 15, 2012 at 07:17:57PM -0500, Lee wrote:
  traceroute shows _a_ path.  Your packets might have taken a different
  path.  ( the return traffic yet another)

Re: Route Management Best Practices

[Tony Tauber]

To elaborate slightly on what others have said in terms of protecting
against leaks;
it's a good idea to filter outbound in a conservative way such that you
only send
what you expect in terms of community values and/or prefixes and/or
AS-paths.

For instance, if something gets into your BGP that isn't tagged with one of
your expected
communities (e.g. applied where you inject your aggs), don't re-advertise
it.
If something has the right community, but not an expected AS-path (e.g.
contains the AS
of one of your transit providers), don't re-advertise.
Implicitly deny all unexpected cases.

Building that kind of restrictive logic will be less likely to you becoming
a path for traffic you
didn't expect (and might swamp you) and also you'll be a better citizen in
general.

Cheers,
Tony

On Tue, Jan 31, 2012 at 1:52 PM, Joe Marr jimmy.changa...@gmail.com wrote:

 Thanks Mark,

 This helps and definitely shows Im heading in the right direction.

 Thanks,


 On Tue, Jan 31, 2012 at 2:17 AM, Mark Tinka mti...@globaltransit.net
 wrote:

  On Tuesday, January 31, 2012 03:04:15 PM Joe Marr wrote:
 
   What do you use for reflectors, hardware(Cisco/Juniper)
   or software daemons(Quagga)?
 
  We operate 2x networks.
 
  One of them runs Cisco 7201 routers as route reflectors,
  while the other runs Juniper M120 routers.
 
  The large Juniper routers were due to particular BGP AFI's
  that Cisco IOS does not support (yet).
 
   I've been toying with the idea of using Quagga route
   servers to announce our prefixes to our edge routers and
   redistribute BGP annoucements learned from downstream
   customers.
 
  You can certainly use any device in your network to
  originate your allocations. We just use the route reflectors
  because it is a natural fit, but you can use any device
  provided it would be as stable and independent as a route
  reflector.
 
  The last thing you want is a blackhole or a route going away
  because your backhaul failed or your customer DoS'ed your
  edge router :-).
 
   Only drawback is the lack of support for
   tagged static routes, so it looks like I'm going to have
   to use a network statement w/ route-map to set the
   attributes.
 
  There was a time when networks were ran without prefix
  lists, BGP communities or even route maps. I'm too young to
  have ever experienced those times, but I always joke with a
  friend (from those times) about how good we have it today,
  and how hard life must have been for Internet engineers of
  old :-).
 
  If you have the opportunity, I'd advise against operating
  without these very useful tools.
 
   Has anyone tried this, or is it suicide?
 
  I'm sure there are several networks out there that are
  intimidated by additional BGP features such as communities,
  advanced routing policy, e.t.c. They do survive without
  having to deal with this, probably because they're networks
  are small and the pain is better than trying something new.
  But I certainly wouldn't recommend it to anyone (except, as
  Randy would say, my competitors).
 
  Mark.
 

Re: AS and advertisen questions

[Tony Tauber]

On Sat, Jun 25, 2011 at 9:39 PM, Joel Jaeggli joe...@bogus.com wrote:


 On Jun 25, 2011, at 6:03 PM, Deric Kwok wrote:

  Can we use same AS to advertise different networks in different location?

 Assuming you want the two instances to be able talk to each other you just
 have to relax loop detection so that you will accept prefixes from your
 AS...


You can also have each AS carry default toward the cloud between.  Of
course, that approach might not be appropriate for all circumstances.

Tony

Re: HIJACKED: 148.163.0.0/16 -- WTF? Level3 is now doing IP hijacking??

[Tony Tauber]

I don't believe this record indicates that Level3 proxy registered the route
object.
It means that someone used the DBANK-MNT maintainer ID in the Level3 RR to
enter a route object 18 months ago.

It looks like Level3 is originating the route in AS3356, not accepting it
from AS13767 (which is what the object would suggest to do.)

Oops, looks like the route is now gone.  Guess it got cleaned.

Tony

On Thu, Mar 31, 2011 at 5:49 AM, Christopher Morrow morrowc.li...@gmail.com
 wrote:


 I forgot:
 $ whois -h whois.radb.net 148.163.0.0
 route: 148.163.0.0/16
 descr: /16 for Celanese
 origin:AS13767
 mnt-by:DBANK-MNT
 changed:   jp...@databank.com 20090818
 source:LEVEL3

 (this means l3 proxy'd in the record, I think... maybe an L3 person
 can speak to this bit?)

  -chris
  (being able to validate 'ownership', really authorization to route,
  automatically will sure be nice, eh?)
 

Re: Comcast routes seen from the cheap seats

[Tony Tauber]

This is part of normal cleaning up of more-specifics (lessening our routing
table footprint).

Apologies for any downstream effects.

Please feel free to contact me if there’s a problem you’re seeing and need
help with.

Thanks,
Tony

(speaking on behalf of AS7922)


On Fri, Dec 17, 2010 at 3:07 PM, Tim Howe ti...@bendtel.com wrote:

 I apologize in advance if this information is uninteresting.  Since
 there was talk about Comcast I thought I might share what I have been
 looking at for the last couple weeks with how I see Comcast route
 announcements from my network.

 On November 22nd (early morning US/Pacific time) we noticed a
 significant increase in traffic over our backup transit connection.

 Looking at the traffic, I found it was mostly to Comcast.  The announced
 prefixes from Comcast on our backup were more specific (smaller prefix
 length) than those from our main link.  So x.x/16 from our main link
 might be x.x/16 but also x.x.m/17 and x.x.z/17 from our backup.

 This probably isn't too strange.  It's a pretty effective way to
 control inbound traffic.  What I don't recall ever seeing is using
 different source AS numbers for the more specific prefixes.

 The routes kind of all end up looking like this for a given network:

 x.x/16 from source-as foo on main   AS path ends with foo

 x.x/16 from source-as foo on backup AS path ends with foo

 x.x.m/17 from source-as bar on backup   AS path ends with foo bar
 x.x.z/17 from source-as bar on backup   AS path ends with foo bar

foo is AS7922 in every case.  bar is any one of at least 24 AS
 numbers assigned to Comcast, many of which are in sequential blocks
 (they don't look like customer reassignments to me, in other words) and
 combine to advertise all of Comcast in smaller prefixes (or so it
 seems).

I didn't see any advertisements from the bar AS numbers on
 our main link (well VERY few, and they were redundant).  That single
 point of data would be pretty easy to filter (by design?) which would
 leave you with the more equitable distribution comprised of something
 like the first two routes above.

Maybe this isn't that weird; I don't usually look this closely
 at it.  The built-in, single data point is handy...  Well, single point
 per network; I tested a single filter rule with all 24 AS #'s I found.

 --
 TimH

Re: History of 4.2.2.2. What's the story?

[Tony Tauber]

I'll add to what Johno writes.  I worked on the anycast routing side to
the server side which he describes.

The 4.2.0.0/16 prefix was set aside by John Hawkinson in our reservation
system under the label Numerology since he had the wisdom to see that
the numbers in themselves could be valuable.  He really wanted 4.4.4.4.

Unfortunately someone had already taken 4.4.0.0/16 for some of our first
DSL assignments (when it still seemed suprising that anyone would need
tens of thousands of IP addresses at a shot).  The first two /16s in 4/8
were already used for infrastucture.

I don't necessarily recall the service being intended for non-customers
(hence no care about seeing multiple paths outside the AS which
originates it.)

The real gains were:

- More graceful failover

- Shorter trips to resolvers (quicker lookups)

- Ability to split load w/o re-configuring clients

That's the story.  Others did it before and since but jhawk really
deserves the credit for squatting on super-easy to type and remember
addresses.  I use it to this day for a quick thing to ping when I need
to test connectivity.

Cheers,

Tony

On Sun, Feb 14, 2010 at 09:16:13AM -0500, John Orthoefer wrote:
 Since I'm watching B5 again on DVD 
 
 I was there at the dawning of the age of 4.2.2.1 :)  
 
 We did it, and we I mean Brett McCoy and my self.   But most of the
 credit/blame goes to Brett...  I helped him, but at the time I was
 mostly working on getting out Mail relays working right.  This was
 about 12 years ago, about 1998, I left Geunitity in 2000, and am back
 at BBN/Raytheon now.  I remember we did most of the work after we
 moved out of Cambridge and into Burlington.
 
 Genuity/GTEI/Planet/BBN owned 4/8.  Brett went looking for an IP that
 was simple to remember, I think 4.4.4.4 was in use by neteng already.
 But it was picked to be easy to remember, I think jhawk had put a hold
 on the 4.2.2.0/24 block, we got/grabbed 3 address 4.2.2.1, 4.2.2.2,
 and 4.2.2.3 so people had 3 address to go to.At the time people
 had issues with just using a single resolver.  We also had issues with
 both users and registers since clearly they aren't geographically
 diverse, trying to explain routing tricks to people KNOW all IPs come
 in and are routed as Class A/B/C blocks is hard.
 
 NIC.Near.Net which was our primary DNS server for years before I
 transferred to planet from BBN.  It wasn't even in 4/8, I think it was
 128.89 (BBN Corp space), but I'm not sure.   BBN didn't start to use
 4/8 till the Planet build out, and NIC.near.net predates that by at
 least 10 years.
 
 I still have the power cord from NIC.near.net in my basement.   That
 machine grew organically with every service known to mankind running
 on it, and special one-off things for customers on it.   It took us
 literally YEARS to get that machine turned off, when we finally got it
 off I took the power cord so no one would help us by turning it back
 on, I gave the cord to Chris Yetman, who was the director of
 operations and told him if a customer screams he has the power to turn
 it back on.  A year or so later, he gave the cord back to me.  
 
 Yes we set up 4.2.2.1 as a public resolver.   We figured trying to
 filter it was larger headache than just making it public.
 
 It was always pretty robust due to the BIND code, thanks to ISC, and
 the fact it was always IPV4 AnyCast.  
 
 I don't know about now, but originally it was IPV4 AnyCast.  Each
 server advertised a routes for 4.2.2.1, .2, and .3 at different costs
 and the routers would listen to the routes.   Originally the start up
 code was, basically: advertise route to 4.2.2.1, 4.2.2.2, and 4.2.2.3
 run bind in foreground mode
 drop route to 4.2.2.1, 4.2.2.2, and 4.2.2.3
 
 then we had a Tivoli process that tried to restart bind, but rate
 limited the restarts.  But that way if the bind died the routes would
 drop.
 
 johno
 
 On Feb 14, 2010, at 4:16 AM, Sean Reifschneider wrote:
 
  I've wondered about this for years, but only this evening did I start
  searching for details.  And I really couldn't find any.
  
  Can anyone point me at distant history about how 4.2.2.2 came to be, in my
  estimation, the most famous DNS server on the planet?
  
  I know that it was originally at BBN, what I'm looking for is things like:
  
How the IP was picked.  (I'd guess it was one of the early DNS servers,
  and the people behind it realized that if there was one IP address
  that really needed to be easy to remember, it was the DNS server,
  for obvious reasons).
Was it always meant to be a public resolver?
How it continued to remain an open resolver, even in the face of
  amplifier attacks using DNS resolvers.  Perhaps it has had
  rate-limiting on it for a long time.
There's a lot of conjecture about it using anycast, anyone know anything
  about it's current configuration?
  
  So, if anyone has any stories about 4.2.2.2, I'd love to hear them.
  
  

Re: Yahoo outage summary

[Tony Tauber]

On Mon, Jul 09, 2007 at 02:31:10PM +0800, Randy Bush wrote:
 
  following existing BCPs with currently-deployed
  techniques/functionality/features would have prevented the issue
  described in the post.
 
 knowing that level(3) is one of the most serious deployments of
 irr-based route filters and other prudent practices, perhaps we should
 wait for a post mortem from level(3) before jumping to conclusions?
 
 randy

Level3's filter implmentation is indeed well-done, however, the fact
remains that the IRR (which I use and endorse) has no linkage to any
other source of information for purposes of validation.
It's fundamentally garbage in, garbage out.

Say some ISP has a provisioning tool which updates their router
configs and the IRR in one fell swoop.  If the provisioner makes a typo
the IRR will gladly accept the entry for, say, 12/8, and the upstream
will rebuild their filters with that entry automatically and you get the
same result.

There's no magic bullet in updating BGP if a fundamental, verifiable
data model is not accepted and agreed upon.

Tony

Re: Yahoo outage summary

[Tony Tauber]

On Mon, Jul 09, 2007 at 04:50:56PM -0400, Joe Abley wrote:

 SIDR is only of any widespread use if it is coupled with policy/ 
 procedures at the RIRs to provide certificates for resources that are  
 assigned/allocated. However, this seems like less of a hurdle than  
 you'd think when you look at how many RIR staff are involved in  
 working on it.

 So, if you consider some future world where there are suitably  
 machine-readable repositories of number resources (e.g. IRRs) are  
 combined with machine-verifiable certificates affirming a customer's  
 right to use them, how far out of the woods are we? Or are we going  
 to find out that the real problem is some fundamental unwillingness  
 to automate this stuff, or something else?

Going to a model with reasonable and well-defined policies and
procedures is a good thing.  However, it renders all the existing IRR
information suspect.  Even the RRs run by RIRs are worthless as they
stand.  For instance ARIN runs an RR but does no validation of what goes
in there today.

A reasonable approach might be to pick up with tools based on the new
SIDR work and leave the existing IRR info behind.

Tony