IP allocations / bogon - verification

[Kenny Kant]

Gang,

I apologize for a double post on this same topic tonight however I thought
that broadening my request may help our cause.  This month we had one of
our IP allocations revoked and just recently got everything squared away
with ARIN and things are "turned back" on so to speak.

However I still have some customers having issues hitting a number of
financial related websites ..etc and I assume its because of bogons ..etc

I saw some earlier posts on here where folks have posted their allocation
to ensure that others are routing it properly so I wanted to do the same.

My allocation which has recently been revived:  66.185.0.0/20

Test point traceroute .etc  66.185.0.198

We do seem to be having some issues with some level 3 routing our range to
some desitnations and can provide specifics off list.

Thanks all for  the help / verification.

Kenny

L3 Contact

[Kenny Kant]

Will an IP engineer from Level3 contact me off list.  We having trouble routing 
traffic through..  Possible bogon update issue ?

Thanks

Sent from my iPhone

Re: Revealed: NSA program collects 'nearly everything a user does on the internet'

[Nick Khamis]

I'll make this short. Is our OpenVPN server prone?

Re: BGP related question

[Andree Toonk]

Hi Parthiv,

.-- My secret spy satellite informs me that at 2013-08-01 7:00 AM  Shah,
Parthiv wrote:

> My apology if I am asking for a repeat question on the list. On 7/29/13 I 
> read an incident about accidental BGP broadcast see article here 
> https://isc.sans.edu/diary/BGP+multiple+banking+addresses+hijacked/16249 or 
> older 2008 incident http://www.renesys.com/2008/02/pakistan-hijacks-youtube-1/

This was the same issue as was discussed last week on Nanog:
http://mailman.nanog.org/pipermail/nanog/2013-July/059992.html
In summary there were 72 prefixes hijacked,  they also leaked a few
hundred more specifics of their own prefixes.
You can examples of similar events here: http://www.bgpmon.net/blog/


> 1)  I would like to understand how can we detect and potentially prevent 
> activities like this? I understand native BGP was not design to authenticate 
> IP owners to the BGP broadcaster. Therefore, issues like this due to a human 
> error would happen. How can activities like this be detected as this is 
> clearly a threat if someone decides to broadcast IP networks of an 
> organization and knock the real org. off the Net. 

There are a few BGP monitoring tools available, BGPMon.net is one such
service.

2) In reference to prevention, I recall there were discussions about
secure BGP (S-BGP), Pretty Good BGP, or Secure Original BGP but I don't
remember if any one of them was finalized (from practicality viewpoint)
and if any one of them is implementable/enforceable by ISPs (do anyone
have any insight)?

The thing we can improve today is providers doing a better job of
filtering. But that's still not full proof. Since many folks use
max-prefix filters only on for example Internet Exchange points, it's
easy to pick up a hijacked route from peers.
In the long term RPKI should solve this, but that's not full proof
either.  The next step is full path validation, that's going to take a
while. For more info see for example:
http://www.bgpmon.net/securing-bgp-routing-with-rpki-and-roas/ or
http://en.wikipedia.org/wiki/Resource_Public_Key_Infrastructure

Cheers,
 Andree

Re: nLayer IP transit

[Mark Tees]

Thanks for the replies.

I think I saw somewhere around the Cloudflare outage post someone mentioning 
that since the person at Juniper that was responsible for Flowspec left it all 
went down hill.

I take it then Flowspec is still used internally then? I am still wondering if 
its best to avoid Flowspec and roll your own firewall rules applied via Netconf 
for transit interfaces to achieve the same sort of functionality.

On 02/08/2013, at 3:30 AM, Richard A Steenbergen  wrote:

> On Thu, Aug 01, 2013 at 10:00:49AM +1000, Mark Tees wrote:
>> Howdy listers,
>> 
>> I remember reading a while back that customers of nLayer IP transit 
>> services could send in Flowspec rules to nLayer. Anyone know if that 
>> is true/current?
> 
> We were forced to stop offering flowspec connections to customers, after 
> we started experiencing a rash of issues with it. Among other things, we 
> found ways for flowspec generated rules to easily cause non line-rate 
> performance on Juniper MX boxes, and we had a couple of incidents where 
> customer generated routes were able to cause cascading failure behaviors 
> like crashing the firewall compiler processes across the entire network.
> 
> I previously mentioned some of this here:
> 
> http://mailman.nanog.org/pipermail/nanog/2011-January/030051.html
> 
> There have also been a few other high profile outages caused by bugs in 
> the Juniper implementation, for example:
> 
> https://support.cloudflare.com/entries/23294588-CloudFlare-Post-Mortem-from-Outage-on-March-3-2013
> 
> As a concept I still very much like Flowspec, and wish we could continue 
> to offer it to customers, but as with any "new" routing protocol there 
> are significant risks of network-wide impact if the implementation is 
> not stable.
> 
> IMHO Juniper has done a horrible job of maintaining support for Flowspec 
> in recent years, and has effectively abandoned doing the proper testing 
> and support necessary to run it in production. Until that changes, or 
> until some other major router vendors pick it up and do better with it, 
> I don't expect to see any major changes in this position any time soon.
> 
> -- 
> Richard A Steenbergenhttp://www.e-gerbil.net/ras
> GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)

[NANOG-announce] NANOG on The Road

[Betty Burke]

NANOGers,

You are invited to attend NANOG's first one-day meeting, "NANOG on the
Road"joint with ARIN
on September 10, 2013 in Portland, OR.

ARIN + NANOG on the Road Portland will provide an opportunity to network
with colleagues,  access to a day's worth of professional education and
current Internet operations. Content will be provided by speakers from both
ARIN and NANOG.
** **
Complete Event details are available on the NANOG website:

ARIN + NANOG on the Road in Portland,
Oregon
 will be held at the Courtyard by Marriott Portland Downtown/Convention
Center. 
* *
Registration is free but required, so make sure to register
now
!

Spend the morning getting up to speed on the history of the Regional
Registry System, Internet Governance, and ARIN technical services.  Find
out the latest about Internet number resource management – including IPv4
transfers and IPv6 adoption, and current ARIN policy developments. Then
spend some time networking with fellow attendees over lunch.  
** **
Kick off the afternoon with tutorials from ARIN on RPKI, NANOG on DNSSEC,
and additional NANOG educational content. NANOG will host a session on its
role in the network operator community and ways to engage with and take
part in its lively professional community of Internet engineers and
architects. The day will conclude with an Open Microphone / Q&A session,
followed by a networking Happy Hour where conversation can continue in a
more relaxed setting. 
** **
Attendees who complete a short survey about the event will be eligible to
win one of two $100 Amazon gift cards.  *Register
today*
!
** **
Please feel free to forward this invitation to friends and colleagues who
may be interested in attending this ARIN + NANOG on the Road event.  Contact
us at nanog-supp...@nanog.org  if you have any questions. 
** **
Regards, 
** **
ARIN + NANOG on the Road Team
American Registry for Internet Numbers (ARIN)  
North American Network Operators Group (NANOG) 








-- 
Betty Burke
NANOG Executive Director
48377 Fremont Boulevard, Suite 117
Fremont, CA 94538
Tel: +1 510 492 4030
___
NANOG-announce mailing list
nanog-annou...@mailman.nanog.org
http://mailman.nanog.org/mailman/listinfo/nanog-announce

Re: nLayer IP transit

[Richard A Steenbergen]

On Thu, Aug 01, 2013 at 10:00:49AM +1000, Mark Tees wrote:
> Howdy listers,
> 
> I remember reading a while back that customers of nLayer IP transit 
> services could send in Flowspec rules to nLayer. Anyone know if that 
> is true/current?

We were forced to stop offering flowspec connections to customers, after 
we started experiencing a rash of issues with it. Among other things, we 
found ways for flowspec generated rules to easily cause non line-rate 
performance on Juniper MX boxes, and we had a couple of incidents where 
customer generated routes were able to cause cascading failure behaviors 
like crashing the firewall compiler processes across the entire network.

I previously mentioned some of this here:

http://mailman.nanog.org/pipermail/nanog/2011-January/030051.html

There have also been a few other high profile outages caused by bugs in 
the Juniper implementation, for example:

https://support.cloudflare.com/entries/23294588-CloudFlare-Post-Mortem-from-Outage-on-March-3-2013

As a concept I still very much like Flowspec, and wish we could continue 
to offer it to customers, but as with any "new" routing protocol there 
are significant risks of network-wide impact if the implementation is 
not stable.

IMHO Juniper has done a horrible job of maintaining support for Flowspec 
in recent years, and has effectively abandoned doing the proper testing 
and support necessary to run it in production. Until that changes, or 
until some other major router vendors pick it up and do better with it, 
I don't expect to see any major changes in this position any time soon.

-- 
Richard A Steenbergenhttp://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)

FCC 477 and FCC499 forms

[Sam Moats]

Good Morning Nanog List,
I'm not normally the tinfoil hat type howerver I do want to know other 
operators opinions on the FCC 477, 499 and the 214 license requirements 
in light of the recent revealations.
Do you think the info is actually for the stated purposes? I'm trying 
hard not to become a member of the tin foil club but it's getting hard 
each day.


Thanks.
Sam

Feds snooping and FCC 477 and FCC 499 forms and 214 licenses

[Sam Moats]

On 2013-08-01 10:57, Sam Moats wrote:
Good Morning Nanog List,
I'm not normally the tinfoil hat type howerver I do want to know
other operators opinions on the FCC 477, 499 and the 214 license
requirements in light of the recent revealations.
Do you think the info is actually for the stated purposes? I'm trying
hard not to become a member of the tin foil club but it's getting hard
each day.

Thanks.
Sam

RE: BGP related question

[Otis L. Surratt, Jr.]

-Original Message-
From: Shah, Parthiv [mailto:parthiv.s...@theclearinghouse.org] 
Sent: Thursday, August 01, 2013 9:00 AM
To: nanog@nanog.org
Subject: BGP related question

>1)  I would like to understand how can we detect and potentially
prevent activities like this? I understand native BGP was not design to
authenticate IP owners to the BGP broadcaster. Therefore, issues like
this due to a human error would happen. How >can activities like this be
detected as this is clearly a threat if someone decides to broadcast IP
networks of an organization and knock the real org. off the Net. 

The most basic short answer would be use of proper filtering and LOAs. 

Transit providers should be checking whether or not customers have
permission to act as a transit provider for prefixes or originate the
prefixes not registered to them by the RIRs.
If every operator would have controls in place to ensure folks are
originating the routes they are supposed to then you wouldn't have a
problem. However, it seems the best course of action is to implement
"checks and balances" internally to each organization which usually
prevents all together or mitigate things as much as possible. Human
error is inevitable. We have outside monitoring (bgpmon) for our
prefixes.

>2) In reference to prevention, I recall there were discussions about
secure BGP (S-BGP), Pretty Good BGP, or Secure Original BGP but I don't
remember if any one of them was finalized (from practicality viewpoint)
and if any one of them is >implementable/enforceable by ISPs (do anyone
have any insight)? 

If I had to pick one based on practicality it would be secure original
BGP. You can create a fairly secure BGP session by using multiple
mechanisms (prefix lists/filters/routemaps, password, iACL,
TTL-security, AS limits etc.)
However, there are caveats to anything.

Feds snooping and FCC 477 and FCC 499 forms and 214 licenses

[sam]

Good Morning Nanog List,
I'm not normally the tinfoil hat type howerver I do want to know
other operators opinions on the FCC 477, 499 and the 214 license
requirements in light of the recent revealations.
Do you think the info is actually for the stated purposes? I'm trying
hard not to become a member of the tin foil club but it's getting hard
each day.

Thanks.
Sam

* Moderators please delete the copy of this I sent from s...@circlenet.us.

Re: BGP related question

[chip]

For detection, there are a few solutions, but mostly it's just monitoring
the route table for your specific routes and being alerted when things
change.  For prevention there are things like RPKI (
https://www.arin.net/resources/rpki/index.html) that can help.  There are a
few other possibilities as well, each with their own pros and cons and
various cases of weakness.  RPKI seems to be the current favorite and most
widely supported.  Well, by vendors at least...

--chip


On Thu, Aug 1, 2013 at 10:00 AM, Shah, Parthiv <
parthiv.s...@theclearinghouse.org> wrote:

> My apology if I am asking for a repeat question on the list. On 7/29/13 I
> read an incident about accidental BGP broadcast see article here
> https://isc.sans.edu/diary/BGP+multiple+banking+addresses+hijacked/16249or 
> older 2008 incident
> http://www.renesys.com/2008/02/pakistan-hijacks-youtube-1/
>
> My questions:
>
>
> 1)  I would like to understand how can we detect and potentially
> prevent activities like this? I understand native BGP was not design to
> authenticate IP owners to the BGP broadcaster. Therefore, issues like this
> due to a human error would happen. How can activities like this be detected
> as this is clearly a threat if someone decides to broadcast IP networks of
> an organization and knock the real org. off the Net. 2) In reference to
> prevention, I recall there were discussions about secure BGP (S-BGP),
> Pretty Good BGP, or Secure Original BGP but I don't remember if any one of
> them was finalized (from practicality viewpoint) and if any one of them is
> implementable/enforceable by ISPs (do anyone have any insight)? 3) If I was
> to ask for an opinion, from your viewpoint which one is better and why and
> which one is not doable and why not?
>
> Thank you in advance,
> Parthiv
>
>
> This e-mail may contain information that is privileged or confidential. If
> you are not the intended recipient, please delete the e-mail and notify us
> immediately.
>



-- 
Just my $.02, your mileage may vary,  batteries not included, etc

BGP related question

[Shah, Parthiv]

My apology if I am asking for a repeat question on the list. On 7/29/13 I read 
an incident about accidental BGP broadcast see article here 
https://isc.sans.edu/diary/BGP+multiple+banking+addresses+hijacked/16249 or 
older 2008 incident http://www.renesys.com/2008/02/pakistan-hijacks-youtube-1/

My questions:


1)  I would like to understand how can we detect and potentially prevent 
activities like this? I understand native BGP was not design to authenticate IP 
owners to the BGP broadcaster. Therefore, issues like this due to a human error 
would happen. How can activities like this be detected as this is clearly a 
threat if someone decides to broadcast IP networks of an organization and knock 
the real org. off the Net. 2) In reference to prevention, I recall there were 
discussions about secure BGP (S-BGP), Pretty Good BGP, or Secure Original BGP 
but I don't remember if any one of them was finalized (from practicality 
viewpoint) and if any one of them is implementable/enforceable by ISPs (do 
anyone have any insight)? 3) If I was to ask for an opinion, from your 
viewpoint which one is better and why and which one is not doable and why not?

Thank you in advance,
Parthiv


This e-mail may contain information that is privileged or confidential. If you 
are not the intended recipient, please delete the e-mail and notify us 
immediately.

Re: nLayer IP transit

[Saku Ytti]

On (2013-08-01 11:35 +0400), Alexandre Snarskii wrote:

> You can match flow actions by extended communities and not accept
> actions you do not like. For example, to permit only "discard" action
> you can match 
> 
> community flow_discard members traffic-rate:*:0;
> 
> Or am I missing something ? 

No you're not missing anything. This is what I implied with 'likely', I
feel validation check should guarantee eBGP safety as most operators won't
deploy additional security via manual config, because issue isn't mentioned
in RFC or vendor docs.

-- 
  ++ytti

Re: nLayer IP transit

[Alexandre Snarskii]

On Thu, Aug 01, 2013 at 09:13:59AM +0300, Saku Ytti wrote:
> On (2013-08-01 10:00 +1000), Mark Tees wrote:
> 
> > I remember reading a while back that customers of nLayer IP transit
> > services could send in Flowspec rules to nLayer. Anyone know if that is
> > true/current?
> 
> Anyone planning to do this might want to be aware that the validation
> process of flowspec does not limit actions.
>
> In practice this means, if you do run flowspec to your customers, your
> customers likely can inject traffic to arbitrary VRFs.

You can match flow actions by extended communities and not accept
actions you do not like. For example, to permit only "discard" action
you can match 

community flow_discard members traffic-rate:*:0;

Or am I missing something ? 

> I feel RFC should have explicitly stated valid actions for validation
> process, which operator MAY change, and any other action MUST cause
> validation process to fail.
> 
> 
> -- 
>   ++ytti

-- 
In theory, there is no difference between theory and practice. 
But, in practice, there is.