RE: [admin] [summary] RE: YouTube IP Hijacking

[Barry Greene (bgreene)]

 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


Missing a tag in the trigger is why you put the Murphy Filters in the
trigger router's route-map (the point you were getting at but being even
more explicit).

In my route map on the trigger router, I would not allow any static
route triggers which did not have an exact match. I would also set the
BGP advertisement to have - by default - the no-export community, a
community range for all my triggers, and limit all my triggers to be
below /24 (i.e /25 - /32).

I then have three things to set my egress prefix filters to all my peers
and customers:

- comply with the default communities (no export)
- filter all communities in my trigger range
- filter anything in the /25 - /32 range.

BTW - "Murphy Filters" is my term for policy filters which expect
"Murphy's Law of Networking" to kick in. You have to expect human error.

In addition to this, I would have my upstream mirror my filters. Life
sucks when you advertise big blocks of the Internet and you become one
giant sink hole (until you go congestion collapse, drop the BGP session
and start flapping like crazy).


 

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On 
> Behalf Of Christopher Morrow
> Sent: Tuesday, February 26, 2008 8:59 AM
> To: hjan
> Cc: nanog@merit.edu
> Subject: Re: [admin] [summary] RE: YouTube IP Hijacking
> 
> 
> On Tue, Feb 26, 2008 at 10:40 AM, hjan <[EMAIL PROTECTED]> wrote:
> 
> >  I think that they should use remote triggered blackhole filtering 
> > with  no-export community.
> >  In this way they do the job with no impact on the rest of internet.
> 
> so, certainly this isn't a bad idea, but given as an example:
> 
> 
> (Sorry not a perfect example, but illustrates my point)
> 
> instead of:
> ip route my.offensive.material.0 255.255.255.0 Null0 tag 12345
> 
> the operator in question (person not place) types:
> ip route my.offensive.material.0 255.255.255.0 Null0 tag 1234
> 
> oops, a simple cut/paste mistake means that a route didn't 
> get tagged properly, didn't get community tagged properly, 
> didn't get set no-export and didn't get kept internally :(
> 
> There is no SINGLE fix for this, there is a belt+suspenders approach:
> 
> 1) Know what you are advertising (customer side of the puzzle)
> 2) Know what you are expecting to recieve (provider side of 
> the puzzle)
> 3) plan for failures in both parts of this puzzle.
> 
> -Chris
> 
-BEGIN PGP SIGNATURE-
Version: PGP 8.1

iQA/AwUBR8RSF7/UEA/xivvmEQJUKACfZB+typ7sIJMnDS+QrO0MqGED+CYAoKFC
iBmY+pq0CohSIJwtu5pgzCJt
=xiog
-END PGP SIGNATURE-

RE: [admin] [summary] RE: YouTube IP Hijacking

[Barry Greene (bgreene)]

 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

 
 
> There have been two or three panels on this exact topic in 
> the past, you can find them in the index of talks.
> Unfortunately, the problem hasn't changed at all.  Perhaps we 
> could just replay those video streams :-)

My $.02 - http://www.getit.org/wordpress/?p=82

The irony to one of those, is that in NANOG 25 right before my session
which pointed out this continued threat vector,  we had Protecting the
BGP Routes to Top Level DNS Servers
http://www.nanog.org/mtg-0206/bush.html.


-BEGIN PGP SIGNATURE-
Version: PGP 8.1

iQA/AwUBR8M5ib/UEA/xivvmEQISnwCgojEcUx7dyMBQPP59gZjdLgQeqqMAoL0p
seCMm+llF8tkr+pGf7LlyXrW
=6jfG
-END PGP SIGNATURE-

RE: YouTube IP Hijacking

[Barry Greene (bgreene)]

 

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On 
> Behalf Of Steven M. Bellovin
> How about state-of-the-art routing security?
> 
> Seriously -- a number of us have been warning that this could happen.
> More precisely, we've been warning that this could happen 
> *again*; we all know about many older incidents, from the 
> barely noticed to the very noisy.  (AS 7007, anyone?)  
> Something like S-BGP will stop this cold.
> 
> Yes, I know there are serious deployment and operational 
> issues.  The question is this: when is the pain from routing 
> incidents great enough that we're forced to act?  It would 
> have been nice to have done something before this, since now 
> all the world's script kiddies have seen what can be done.

BCPs stops this problem. soBGP may make it easier. 

FW: [menog] FLAG Cable Cut - Update

[Barry Greene (bgreene)]

 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

[Reposted with author's permission.] 

+ Notice that there are more issues than what is reported in the
popular press.
+ Notice that there are issues with more submarine systems (APCN),
but they are not "news."

As has been pointed out before, there are always issues with
submarine systems. That is why we have so many repair ships in the
global fleet:

http://www.iscpc.org/information/Cableships_1.htm
http://www.iscpc.org/information/Cableships_2.htm




http://www.flagtelecom.com/media/PDF_files/Submarine%20Cable%20Cut%20U
pdate%
20Bulletin%20Release%20050208.pdf

- -Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Sanghani, Bijal
Sent: Tuesday, February 05, 2008 1:26 AM
To: [EMAIL PROTECTED]
Subject: [menog] FLAG Cable Cut - Update

Dear All,

 

Thought I'd give you all an update on where we (FLAG) are with the
cable cuts -

 

FEA Segment D - The Cable ship CS Certamen is now expected to arrive
at the Alexandria repair ground on Wednesday 6th February. A Permit
for the repair is currently being expedited with the Egyptian
authorities.

 

FEA Segment M - The cable ship CS Asean Restorer has been booked for
this repair. It is currently out on an APCN repair and with current
plan will be ready to start any work on our cable on or after 11th
Feb. We have the OTDR traces from Penang and see that the fault is
around 28km out from the station. 

 

FALCON Segment 7b (Bandra Abbas - Al Seeb) - E-Marine continues to
await the permit to enter the Iranian waters and current forecast for
the ship to start a work is around 19th February.

 

FALCON Segment 2 - Fault 1st February 41km from repeater, which is
between the first two repeaters out of Dubai toward Muscat (Al Seeb).
The ship has left Abu Dhabi and is on route to the repair ground. The
repair is expected to start in the next 12 hours (weather
permitting).

 

FALCON Segment 7a - Fault 1st February between BND (Bandar Abbas,
Iran) and KWI (Kuwait), we are waiting for ship to go out and it
maybe fixed before going out the fault on 7b - to be confirmed. 

 

I hope this helps,

 

Regards,

 

Bijal Sanghani

Sr. IP Technical Support Engineer

Technical Services Group

FLAG Telecom

Tel. +442 082 821 564

www.flagtelecom.com

 

 


-BEGIN PGP SIGNATURE-
Version: PGP 8.1

iQA/AwUBR6hEeb/UEA/xivvmEQL5YgCg9tX2lZmq937MhRd65qm0wk9EYPUAniED
VAxSCsr92aysSkrs6dGspaVm
=45sb
-END PGP SIGNATURE-

RE: Blackholes and IXs and Completing the Attack.

[Barry Greene (bgreene)]

 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

 

> anyway, the idea behind multi-as blackholing has been (and 
> apparently continues to get) rehashed a few times over the 
> last 5-8 years... good luck!

It seems that way. People seem to forget about the conversations and
work around 2000 - 2002. We not only had RTBH (static), multi AS
RTBH, Source based RTBH (why uRPF Loose check was created), BGP
Community based packet filtering (QPPB - source or destination),
Backscatter Traceback (Chris and Brian's cool technique), Customer
triggered RTBH (another Chris and Brian trick), BGP Shunts
(originally created for the Great Firewall), MAPS's grow (which had
multi-AS eBGP multihops BGP RTBHs back in 1997 for anti-SPAM
filtering), and then all the BGP Flow-Spec work.

We even have a RFC - 3882 Configuring BGP to Block Denial-of-Service
Attacks. by D. Turk. published in September 2004.

This is a good conversation for NANOG, but we really need to build up
some FAQ so we don't keep going over the same things every year. 

Barry  

-BEGIN PGP SIGNATURE-
Version: PGP 8.1

iQA/AwUBR6Ys/7/UEA/xivvmEQK3pwCg/a7329AxsnBgmPT9kmHoSWXhd1AAnA8d
COSRO/CaIVnFOu0BIjbh5snD
=HANY
-END PGP SIGNATURE-

RE: Argument for cleaning up BGP announcements

[Barry Greene (bgreene)]

 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Check out:

http://www.nanog.org/mtg-0302/cidr.html

I still think the CIDR Report only has a impact if you have a team of
volunteers knocking people on the side of the head and getting them
to pay attention. People look at the top, but try looking at the
bottom 2/3.  

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On 
> Behalf Of Silas Moeckel
> Sent: Thursday, January 31, 2008 4:02 PM
> To: nanog@merit.edu
> Subject: Argument for cleaning up BGP announcements
> 
> 
> I have the misfortune of attempting to make the argument to 
> one of the top 20 worst offenders on the CIDR report 
> aggregation summary.  If anybody has some good PHB fodder and 
> info on general bad things that can happen by doing things 
> this way please email me off list.  I'll summarize what I get 
> in a few days.  There is no major TE or similar reason for 
> them to be on there just bad practices since the last time I 
> restructured there network.  Obviously since things work 
> today they are hesitant to change.
> 
> Silas Moeckel
> DSM Inc.

-BEGIN PGP SIGNATURE-
Version: PGP 8.1

iQA/AwUBR6KZ0L/UEA/xivvmEQLtCwCaAy2F8rp5IbfbfWzY3kDABJ6ejfEAn0Ff
pcaKf5KH8FDFjtkQ6l3ABiI4
=REYG
-END PGP SIGNATURE-

RE: Where are static bogon filters appropriate? was: 96.2.0.0/16 Bogons

[Barry Greene (bgreene)]

 

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On 
> Behalf Of Chris L. Morrow
> Sent: Thursday, March 01, 2007 6:23 AM
> To: Jon Lewis
> Cc: Eric Ortega; nanog@merit.edu
> Subject: Where are static bogon filters appropriate? was: 
> 96.2.0.0/16 Bogons
> 
> 
> On Thu, 1 Mar 2007, Jon Lewis wrote:
> 
> > On Wed, 28 Feb 2007, Eric Ortega wrote:
> >
> > > I'd like to thank the group for the responses and help with this 
> > > issue. I find it ironic that Randy's study actually uses 96 space.
> >
> > The amazing/sad thing is that people have been facing and 
> fixing the 
> > same problem for more than 4 years.  How many times does a network 
> > have to fix their static bogon filters before coming to the 
> > realization that those filters are a bad idea?
> 
> So, where are static bogon filters appropriate? (loaded 
> question perhaps) I ask because just about every 'security 
> expert' and 'security whitepaper'
> or 'security suggestions' has some portion that speaks to 
> "why it's a grand idea to have acl-lines/firewall-policy tp 
> block 'bogon' ip space"
> (for some definition of 'bogon' of course).
> 
> -Chris

Agreed. This "security experts copying each other - without knowing what
they are really talking about" started to happen 4 years ago. Which is
why some people working with SP all over moved evolving work of
Bogon/DUSA prefix filtering to two places, CYMRU's sponsored "Bogon"
project and RIPE (work like
http://www.ripe.net/ripe/docs/ripe-351.html). Both places allow for
policy practice suggestions to evolve. And they have evolved - working
with operators who are working to institute policies and practices in
their organization which is resistant to operational entropy. 

For example, http://www.cymru.com/Bogons/index.html describes the static
policies for people to get started. Static is not the way to go.
Operators who understand the impact of "operational entropy" (OPEX
growth) want dynamic tools. Hence, they spend time find a tool which is
a multipurpose dynamic prefix policy system (i.e. something that does
their customer's prefixes, anti-spoofing, DUSA, Bogon, Black Hole, and
Hijack). This is why the Bogon reference page has grown over the years
adding tricks and tools to build prefix filters dynamically:

-> The Bogon Route Server Project
(http://www.cymru.com/BGP/bogon-rs.html) allows SPs to take a feed or
build their own.
-> RADb
-> RIPE NCC
-> DNS Bogon Tracking
-> E-mail Bogon Tracking

To 'globally' monitor, we have
http://www.cymru.com/BGP/robbgp-bogon.html and
http://www.cymru.com/BGP/asnbogusrep.html and
http://www.cidr-report.org/ and http://www.routeviews.org/ and
http://www.completewhois.com/bogons/active_bogons.htm. 

(Steve B, you were looking for data, here are your sources. I'm sure
Geoff might be persuaded to do a historical graph on the 'Possible
Bogons.')

To organizationally monitor, J & C both have the ability to count the
prefix drops. It was operators who taught me both of these tricks -
which allow them to put in prefix filters which included bogons, then
count the packets originating from those filters prefixes get dropped --
one pulling all that data via SNMP and plugged it into MRTG so they know
the count of packets coming from their peers whose source is in the
Bogon/DUSA list. 

Just remember the real reason we do this. 7007 demonstrated an
operational risk to networks. That risk is a cascading risk (prefix
advertisements moving from one network to another). Jump on a miscreant
shopping mall, buy a bunch of BGP speaking "owned" routers, check out
which ones do not have any upstream prefix filters, and have fun. The
two reasons why this has not happened is 1) enough SPs do ingress prefix
filters with their peers to disrupt this attack vector and 2) there is
no way to 'extort' money from the Internet (Miscreant principle #3 -
never to anything for free). 

Has this risk gone away? When it has been demonstrated to NOT be a risk,
organizations will change their prefix filter policies. In the mean
time, each organization on the Internet who have perceived operational
risk mitigation benefits from ingress prefix filtering will keep on
doing it. 

RE: Where are static bogon filters appropriate? was: 96.2.0.0/16 Bogons

[Barry Greene (bgreene)]

 

> http://www.completewhois.com/hijacked/files/203.27.251.0.txt
> 
> http://www.completewhois.com/hijacked/index.htm
> 
> 
> This can proof the opposite.
> 
> Malware comes from redirected allocated blocks, not from bogons.

I don't think this is proof. The haphazard way that BCP38 and ingress
prefix filtering of Bogon/DUSA make 'spoofing' from these Bogon/DUSA
blocks unprofitable to a miscreant and forces them to work too hard. 

What this data does demonstrate is that hijacking of valid prefixes has
not been mitigated. And, there is most likely an economic motivation to
use the hijacked prefixes. In other words, the miscreants can use the
technique over and over - not get caught - not work too hard - and make
money (the first three and most important principles of miscreants). 

This data points to another problem - where SPs are not putting ingress
prefix filters on their BGP speaking customers. That is another area
where you have a lot of operational entropy issues. OPEX is increased on
the building of the prefix provision tool, the maintenance of the
policy, synchronization of that policy with the peer ingress filters,
and customers calls required when ever the customer gets prefix updates.
Hence many (most) operators rather not do the prefix filters on their
customers (usually 2 to 4 lines of policy on a J & C router). For many,
the OPEX is just too high.

RE: Bogon Filter - Please check for 77/8 78/8 79/8

[Barry Greene (bgreene)]

-> We have this source:
http://www.iana.org/assignments/ipv4-address-space

-> We "source" URLs for each of the RIRs in the prefix filter templates:


ftp://ftp-eng.cisco.com/cons/isp/security/Ingress-Prefix-Filter-Template
s/

http://www.cymru.com/gillsr/documents/junos-isp-prefix-filter-loose.htm

http://www.cymru.com/gillsr/documents/junos-isp-prefix-filter-strict.htm

-> We have the Bogon Router Server:

http://www.cymru.com/BGP/bogon-rs.html

-> We have the RIPE project to help with the migration:

http://www.ris.ripe.net/debogon/
 
-> We have the RADB Filters:


http://www.radb.net/cgi-bin/radb/whois.cgi?obj=MAINT-BOGON-FILTERS

-> We have the RIPE DB Filters:


http://www.ripe.net/perl/whois?searchtext=MAINT-BOGON-FILTERS&form_type=
simple


-> And there is DNS and E-mail notifications ..


All of this is listed at http://www.cymru.com/Bogons/index.html


So what would be helpful are people who say "I've done everything (or
some of the things) off the Bogon Team page and think there is a better
way." The core problem right now are that too many organizations are
doing nothing to maintain policy once that policy choice has been
selected.






> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On 
> Behalf Of David Conrad
> Sent: Thursday, December 14, 2006 4:50 PM
> To: [EMAIL PROTECTED]
> Cc: nanog@merit.edu
> Subject: Re: Bogon Filter - Please check for 77/8 78/8 79/8
> 
> 
> Hi,
> 
> > or LDAP could be used ...
> 
> I was wondering when this would show up... :-)
> 
> > If IANA and the RIRs would step up to the plate and provide an 
> > authoritative data source identifying which address ranges 
> have been 
> > issued for use on the Internet then bogon lists would not 
> be needed at 
> > all.
> > ... IANA would be the authoritative source for stuff like RFC 1918 
> > address ranges and other non-RIR ranges.
> 
> IANA has a project along these lines at the earliest stage of 
> development (that is, we're trying to figure out if this is a 
> good idea and if so, the best way to implement it).  I'd be 
> interested in hearing opinions (either publicly or privately) 
> as to what IANA should do here.
> 
> > One wonders whether it might not be more effective in the 
> long run to 
> > sue ICANN/IANA rather than suing completewhois.com.
> 
> Sigh.  What is the IOS command to disable lawyers again?
> 
> Rgds,
> -drc
> 

RE: advise on network security report

[Barry Greene (bgreene)]

Postings like this to NANOG will not have any impact. So if your goal is
instigate action, posting is not going to work. The core data point is
the weekly CIDR report. It only works if you have peers using the weekly
list to apply peer pressure to the networks listed to act. 

Sharing summaries to communities like dshield, NSP-SEC, DA, SANs and
other security mitigation communities along with a subscription web page
that would allow an organization to get enough details to take action.

Also, posting too much hear just helps the criminals/miscreants. Some of
the better ones who have any clue can be assumed to be on NANOG. They
would love details on how well their tools are working and which ones
are going under the detection radar.

  

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On 
> Behalf Of Rick Wesson
> Sent: Monday, October 30, 2006 8:53 AM
> To: nanog@merit.edu
> Subject: advise on network security report
> 
> 
> 
> I would appreciate a bit of advise on a service I am about to deploy. 
> I've spoken at different venues (including nanog) on global 
> infection rates of bots and the general degradation of well 
> behaved hosts.
> 
> I now track around 2.2M abuse events per day and now have the 
> capability to produce reports for the community on which 
> networks have the largest problems. I am prepared to make 
> reports monthly to the community ordering networks by their 
> volume of issues.
> 
> I'd like some hints of which might be the most valuable to 
> the community.
> 
> o are hosts counts or issue counts more important
> 
> o is a 7 or 30 day window sufficient for aggregation?
> 
> o I'm not repaired for graphs yet so don't go there.
> 
> o should I post sub-reports for regions, by RIR?
> 
> o which kinds of abuse are more interesting.
> 
> I'm expecting to post a weekly report once a month to nanog, 
> would this be disruptive? We have a mailing list set up for 
> weekly reports, once finalized I'll post the location for its 
> list manager.
> 
> The global report usually has about 6,000+ networks, the top 
> 100 from last week are below.
> 
> again, thanks for your feedback.
> 
> 
> -rick
> 
> 
> Table 1. Networks with abuse, ordered by #incidents
> +---+---+--+-+
> | asn   | incidents | cc   | left(asname,35) |
> +---+---+--+-+
> |  4134 |517830 | CN   | CHINANET-BACKBONE   |
> |  9121 |331955 | EU   | TTNet   |
> |  4837 |289984 | CN   | CHINA169-Backbone   |
> |  3320 |231516 | DE   | Deutsche Telekom AG |
> |  3352 |211504 | ES   | TELEFONICA-DATA-ESPANA Internet Acc |
> |  5617 |194685 | PL   | TPNET   |
> |  3215 |181686 | FR   | AS3215  |
> |  3269 |175858 | EU   | ASN-IBSNAZ  |
> |  4766 |129722 | KR   | KIXS-AS-KR  |
> | 19262 |125003 | US   | Verizon Internet Services   |
> |  8551 |116014 | EU   | ISDN-NET-AS |
> |  3209 | 94981 | DE   | UNSPECIFIED |
> |  3462 | 82089 | TW   | HINET   |
> |  9829 | 80538 | IN   | BSNL-NIB|
> |  8151 | 79223 | EU   | Uninet S.A. de C.V. |
> |  8359 | 73640 | RU   | MTUONLINE   |
> |  5486 | 65757 | EU   | Euronet Digital Communications  |
> | 12322 | 65638 | FR   | PROXAD AS for Proxad ISP|
> |  4788 | 53863 | MY   | TMNET-AS-AP |
> |  9116 | 53375 | IL   | Goldenlines main autonomous system  |
> |  4814 | 52712 | CN   | CHINA169-BBN|
> | 22927 | 51899 | AR   | Telefonica de Argentina |
> |  4812 | 46462 | CN   | CHINANET-SH-AP  |
> |  1680 | 45848 | IL   | NETVISION   |
> |  9105 | 44450 | UK   | TISCALI-UK  |
> | 15557 | 42792 | FR   | LDCOMNET|
> |  9498 | 42774 | IN   | BBIL-AP |
> |  8584 | 41914 | US   | Barak AS|
> |  2856 | 41820 | EU   | BT-UK-AS|
> | 13184 | 41688 | DE   | HANSENET HanseNet Telekommunikation |
> |  9318 | 40930 | KR   | HANARO-AS   |
> | 12479 | 39009 | EU   | UNI2-AS Uni2 Autonomous System  |
> |  6147 | 38716 | US   | Telefonica del Peru S.A.A.  |
> |  3243 | 38586 | PT   | RIPE NCC ASN block  |
> |  6713 | 35777 | EU   | IAM-AS  |
> | 12876 | 35068 | FR   | AS12876 |
> |  6739 | 32639 | ES   | ONO-AS

RE: different flavours of uRPF [RE: register.com down sev0?]

[Barry Greene (bgreene)]

 

> > Strict mode uRPF is likely to be implemented by performing a full 
> > forwarding table lookup and then comparing the packet's incoming 
> > interface to the interface from the forwarding table result.

uRPF uses the same look up algorithm as you do when you look up the
destination address for next hop. 
 
> Pekka might have meant wouldn't you build a separate 'urpf 
> table' per interface perhaps? (just guessing at his intent) 
> though there is only one 'urpf table' which is the fib, right?

This is VRF Mode uRPF. Where you configure the uRPF to check a separate
VRF(FIB). This decouples the policy table for the active forwarding
table - providing more flexibility - at the cost of memory. You can set
it to one of two mode - white list (if exist pass) or black list (if
exist drop). The white list is what SPs have been interested in since
you can fill the VRF with the prefixes from a peering partner/customer -
then insure all source addressing coming from that customer matches the
BGP prefixes being sent. 

RE: different flavours of uRPF [RE: register.com down sev0?]

[Barry Greene (bgreene)]

 
> > > It was possible to implement BCP38 before the router 
> vendors came up 
> > > with uRPF.
> > 
> > Further, uRPF is frequently a very inefficient means of 
> implementing 
> > BCP 38.  Consider that you're going to either compare the source 
> > address against a table of 200,000 routes or against a handful of 
> > prefixes that you've statically configured in an ACL.
> 
> Isn't that only a problem if you want to run a loose mode uRPF?  
> Given that loose mode uRPF isn't very useful in most places 
> where you'd like to do ingress filtering, this doesn't seem 
> like a big issue..

Loose mode is a RTBH Reaction tool - not BCP 38. Don't use a screw
driver to hammer a nail. 

> BTW, I still keep wondering why Cisco hasn't implemented 
> something like Juniper's feasible-path strict uRPF.  Works 
> quite well with multihomed and asymmetric routing as well -- 
> no need to fiddle with communities, BGP weights etc. to 
> ensure symmetry.

Wow - I'm going to need to dust off the tutorial materials on how uRPF
and using the FIB as a policy enforcement tool works. 

Does uRPF need to scan through the entire FIB? Saying this is saying
routers look through the entire FIB table to find the next hop? What
ever happened to TRIE techniques? uRPF's look up is at the same speed as
the forwarding look up. In fact, in many implementations, the
"forwarding lookup" gets the source and destination address values from
the FIB.

Now, are there other ways of doing BCP38 - yes lots:

- ACLs
- Radius loaded ACLs
- uRPF Strict-Feasible-VRF modes
- IP Source Verify
- DHCP Lease Query
- NAT on the home CPE

Why hasn't Cisco done uRPF Feasible path? Cause until recently, our CEF
structures would not allow for feasible/alternate paths. If the FIB is
your policy table, then _what_ you are limited to the capabilities of
that FIB when using it to police the packet. Cisco has that now, so
"feasible path" is just a matter of time to work through the coding
queues.

What I'm shaking my head over with this whole dialog is the 1990's
thinking. BCP38 is out of date. Anyone who works, mitigates, analysis,
and studies attack vectors on network systems know that checking the IP
source address is one of many "Anti-Spoof" checks you need to do on the
packet. With Ethernet and Cable, you need to do a MAC check. With all
mediums you need to check the Prec/DSCP value (porn at Prec 6 does
wonders for the routing protocols when there is congestion in the path).
Then there is TTL values, Fragments, and other values which need to be
policed on the edge. This is why uRPF - while helpful - is not the
primary BCP38 tool people should be considering on the edge.


 

  

RE: mitigating botnet C&Cs has become useless

[Barry Greene (bgreene)]

> 
> What?  That's what I'm trying to find out, but I'm not as 
> smart as most, so I can only point out the things that I 
> believe definitely won't work and why I think that. 
> Hopefully by the application of flame to my butt by smart 
> people for saying what I do will spark some thought toward the goal.


Start with:

http://www.nanog.org/mtg-0602/greene.html

RE: BGP and GLB.

[Barry Greene (bgreene)]

Anycast - it is a widget - not a solution.

Go here http://www.nanog.org/subjects.html, look for Anycast, and watch
the VODs. 

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On 
> Behalf Of Robert Sherrard
> Sent: Tuesday, August 01, 2006 5:54 PM
> To: nanog@merit.edu
> Subject: BGP and GLB.
> 
> Does anyone know of some good writeup that details using BGP 
> as a form of global load balancing, between multiple sites.
> 
> Rob
> 
> 

RE: key change for TCP-MD5

[Barry Greene (bgreene)]

> Why couldn't the network device do an AH check in hardware 
> before passing the packet to the receive path?  If you can 
> get to a point where all connections or traffic TO the router 
> should be AH, then, that will help with DOS.

There is no push from the operators to look at AH check or the SPI check
in before the receive path punt. The push was to get something the
lowest common denominator engineering in the NOC can handle with a BGP
key roll. Hence draft-bonica-tcp-auth. 

Many operators.
Build on the operator's requirements.
Build on experience with similar techniques.
Three vendors agree - all with working code.
 
> If you can limit what devices _SHOULD_ talk to the router and 
> at least define some subset of that from which you demand AH 
> on every packet, that helps but isn't a complete solution.

This is a major path. Everything from recoloring the packets coming into
your network to BCP38 to new tricks. But that is a different
conversation.

RE: key change for TCP-MD5

[Barry Greene (bgreene)]

At the same time, you are not going to find the SP core swapping out
their equipment for hardware with crypto chips.  SPs do not seem to want
to pay for this sort of addition. So even new equipment is not getting
hardware crypto that can be used.

So a BGP IPSEC option has to work with what hardware we've got deployed
today - not wishing the community would "just upgrade."  

> -Original Message-
> From: Bora Akyol [mailto:[EMAIL PROTECTED] 
> Sent: Friday, June 23, 2006 2:02 PM
> To: [EMAIL PROTECTED]
> Cc: Barry Greene (bgreene); Ross Callon; nanog@merit.edu
> Subject: RE: key change for TCP-MD5
> 
> Assumptions, assumptions.
> 
> If your IPSEC is being done in hardware and you have 
> appropriate QoS mechanisms in your network, you will probably 
> not be able to pass your best effort traffic but the rest 
> should be OK.
> 
> Can we get back to the regularly scheduled programming 
> instead of throwing big numbers around?
>  
> Barry had a point, if you do IPSEC stupidly, it does not protect you.
> If you pay attention to detail, it does help. It is not the panacea.
> 
> For the purpose of securing BGP, I think IPSEC is easy to 
> configure (at least on IOS which is what I'm used to), and 
> will do the job. And for this application, I don't see why 
> cert's can't be used either.
> 
> Regards
> 
> Bora
> 
> 
> > -Original Message-----
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> > Sent: Friday, June 23, 2006 1:46 PM
> > To: Bora Akyol
> > Cc: Barry Greene (bgreene); Ross Callon; nanog@merit.edu
> > Subject: Re: key change for TCP-MD5
> > 
> > On Fri, 23 Jun 2006 13:35:20 PDT, Bora Akyol said:
> > 
> > > The validity of your statement depends tremendously on 
> how IPSEC is 
> > > implemented.
> > 
> > If 113 million packets all show up at once, you're going to get 
> > DoS'ed, whether or not you have IPSEC enabled.
> > 
> 

RE: key change for TCP-MD5

[Barry Greene (bgreene)]

Walk through the code with the current MD5 spec. You need to terminate
the TCP session, check the MD5, then do the next checks. That is why
we're doing TTL check for GTSM and other classifying/queuing before the
TCP session termination. In the big equipment that ranges from
specialized ASIC checks, to raw queue classifiers, to ACLs  All
before the packet gets punted out of the forwarding chip to the Route
Processor. In other equipment you do the check on the Line Card's CPU
after the punt - compartmentizing the impact of an attack. There is even
code in the 'coding queue' to do the check on CPU routers before you
terminate (still get the CPU clock cycle hit for dropping the packet). 

Granted, you need to put this in context of how vendors should be
building security into their devices - layered - with a combination of
classification (i.e. ACLs), queuing (containing the impact), and systems
practices.

So go back to the instigating presentation:

http://www.nanog.org/mtg-0302/gill.html

Also check on one vendor's roadmap:

ftp://ftp-eng.cisco.com/cons/isp/security/BGP-Security/GTSM.pdf

So lets keep focused on the right issue - can you TTL filter before the
TCP session terminates vs worrying over the order of the multitude of
checks which take up processing the TCP packet.



> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On 
> Behalf Of Todd Underwood
> Sent: Friday, June 23, 2006 1:43 PM
> To: nanog@merit.edu
> Subject: Re: key change for TCP-MD5
> 
> 
> 
> 
> On Fri, Jun 23, 2006 at 11:49:33AM -0700, Barry Greene 
> (bgreene) wrote:
> >
> > Yes Jared - our software does the TTL after the MD5, but 
> the hardware 
> > implementations does the check in hardware before the packet gets 
> > punted to the receive path. That is exactly where you need 
> to do the 
> > classification to minimize DOS on a router - as close to the point 
> > where the optical-electrical-airwaves convert to a IP 
> packet as possible.
> 
> i'm not that bright, so maybe i'm missing something, but i've 
> heard this claim from cisco people before and never understood it.
> 
> just to clarify:  you're saying that doing the (expensive) 
> md5 check before the (almost free) ttl check makes sense because that
> *minimizes* the DOS vectors against a router?  can someone 
> walk me through the logic here using small words?  i am 
> obviously not able to follow this due to my distance from the 
> "optical-electrical-airwaves". 
> 
> t.
> 
> 
> --
> _
> todd underwood +1 603 643 9300 x101
> renesys corporationchief of 
> operations & security 
> [EMAIL PROTECTED]   
> http://www.renesys.com/blog/todd.shtml
> 

RE: key change for TCP-MD5

[Barry Greene (bgreene)]

This "RFC1918 for control plane/management plane" technique is
vulnerable to a TCP reflection attack. The miscreants know about it. So
the assumption that the chance of a RFC 1918 packet reaching your router
being "zero" is not something an you should assume.

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On 
> Behalf Of Iljitsch van Beijnum
> Sent: Friday, June 23, 2006 4:18 PM
> To: Owen DeLong
> Cc: NANOG list
> Subject: Re: key change for TCP-MD5
> 
> 
> On 24-jun-2006, at 0:43, Owen DeLong wrote:
> 
> > Why couldn't the network device do an AH check in hardware before 
> > passing the packet to the receive path?  If you can get to a point 
> > where all connections or traffic TO the router should be AH, then, 
> > that will help with DOS.
> 
> If you care that much, why don't you just add an extra 
> loopback address, give it an RFC 1918 address, have your peer 
> talk BGP towards that address and filter all packets towards 
> the actual interface address of the router?
> 
> The chance of an attacker sending an RFC 1918 packet that 
> ends up at your router is close to zero and even though the 
> interface address still shows up in traceroutes etc it is 
> bullet proof because of the filters.
> 
> (This works even better with IPv6 link local addresses, those 
> are guaranteed to be unroutable.)
> 

RE: key change for TCP-MD5

[Barry Greene (bgreene)]

 

> If DOS is such a large concern, IPSEC to an extent can be 
> used to mitigate against it. And IKEv1/v2 with IPSEC is not 
> the horribly inefficient mechanism it is made out to be. In 
> practice, it is quite easy to use.

IPSEC does nothing to protect a network device from a DOS attack. You
know that.

DOS prevention on a network device needs to happen before the TCP/Packet
termination - not the Key/MD5/IPSEC stage. The signing or encrypting of
the BGP message protects against Man in the Middle and replay attacks -
not DOS attacks. Once a bad packet gets terminated, your DOS stress on
the router kicks in (especially on ASIC/NP routers). The few extra CPU
cycles it takes for walking through keys or IPSEC decrypt are irrelevant
to the router's POV. You SOL if a miscreant can get a packet through
your classification & queuing protections on the router and have it
terminated. 

The key to DOS mitigation on a network device is to have many fields in
the packet to classify as possible before the TCP/Packet termination.
The more you have to classify on, the more granular you can construct
your policy. This is one of the reasons for GTSM - which adds one more
field (the IP packet's TTL) to the classification options. 

Yes Jared - our software does the TTL after the MD5, but the hardware
implementations does the check in hardware before the packet gets punted
to the receive path. That is exactly where you need to do the
classification to minimize DOS on a router - as close to the point where
the optical-electrical-airwaves convert to a IP packet as possible.

RE: Is your ISP Influenza-ready?

[Barry Greene (bgreene)]

 

> (Back in the days of dial-up, I had a lot of trouble 
> connecting to Bell Labs on snow days.  No rule, and the place 
> was officially open for business.  But everyone just did the 
> rational thing.)

I think the point is to start capacity and contingency planning now. Is
your VPN infrastructure set up to have every employee connecting back to
the office? Are your upstreams sized to take this load? Are you VPN
concentrators sized to take this load?

RE: Did anyone else notice the CAIDA skitter poster in the background of George Bush's speech at the NSA?

[Barry Greene (bgreene)]

 
Maybe now the US Gov can open their pocket book and pay for Skitter? :-)

> -Original Message-
> From: Martin Hannigan [mailto:[EMAIL PROTECTED] 
> Sent: Sunday, February 05, 2006 10:55 PM
> To: Etaoin Shrdlu
> Cc: Barry Greene (bgreene)
> Subject: Re: Did anyone else notice the CAIDA skitter poster 
> in the background of George Bush's speech at the NSA?
> 
> At 06:02 PM 2/5/2006, Etaoin Shrdlu wrote:
> 
> >Joe McGuckin wrote:
> >
> >>http://tinyurl.com/doy6r
> >
> >
> >Um... (noticed on other lists, by the way)
> >
> >http://securitywizardry.com/radar.htm
> >
> 
> 
> 
> I like the skitter chart, but at the Vegas NANOG, Barry 
> Greene disclaimed it and said it was "out of date". I hope 
> the NSA is using up to date data. It would be horrific if 
> they weren't.
> 
> 
> 
> 
> Martin Hannigan(c) 617-388-2663
> Renesys Corporation(w) 617-395-8574
> Member of the Technical Staff  Network Operations
> [EMAIL PROTECTED]  
> 

RE: Is my router owned? How would I know?

[Barry Greene (bgreene)]

Here are some other new things (Cisco IOS specific):

Login Security Enhancements. The Cisco IOS Login Enhancements feature
allows users to better secure their Cisco IOS devices when creating a
virtual connection, such as Telnet, secure shell (SSH), or HTTP. Thus,
users can help slow down dictionary attacks and help protect their
router from a possible denial-of-service (DoS) attack.

http://www.cisco.com/en/US/products/sw/iosswrel/ps5207/products_feature_
guide09186a00801d1cb3.html 


Configuration Change Notification and Logging. Releases of Cisco IOS
software prior to 12.3(4)T/12.2(25)S lack the ability to track the
origin of changes to the running configuration. The only way to
determine if a Cisco IOS software configuration has been changed is to
pull the running and startup configurations offline and do a
line-by-line comparison. This comparison will identify all the changes
that have occurred between the two configurations, but it will not
specify the sequence in which the changes occurred or the person
responsible for the changes.

The Configuration Change Notification and Logging (Configuration
Logging) feature allows the tracking of configuration changes entered on
a per-session and per-user basis by implementing a configuration log.
The configuration log will track each configuration command that is
applied, who applied the command, the parser return code for that
command, and the time that the command was applied. This feature also
adds a notification mechanism that sends asynchronous notifications to
registered applications whenever the configuration log changes. 

http://www.cisco.com/en/US/products/sw/iosswrel/ps5207/products_feature_
guide09186a00801d1e81.html


And then there is 'security passwords min-length'. If you set this to 6
more more, it would knock out 'cisco' as a possible password on the
router. 



> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On 
> Behalf Of Rob Thomas
> Sent: Thursday, January 12, 2006 10:19 AM
> To: NANOG
> Subject: Is my router owned? How would I know?
> 
> 
> Hi, NANOGers.
> 
> You all know how I love a good segue...  ;)
> 
> How can you tell if your router has been owned?  In general 
> the configuration will be modified.  This is why we advocate 
> using rancid (or something akin to it) as both a 
> configuration backup tool AND an early warning tool.  If you 
> have a router running BGP, it also pays to peer with it 
> externally.  You can use a private ASN and rackspace with a 
> buddy.  You can use this peering to detect announcements you 
> don't expect or necessarily condone.
> 
> How else can you tell?  Here are some tips:
> 
> If there is a new user account, or if the enable and access 
> passwords have changed, look out!  The miscreants love to 
> scan and find routers with "cisco" as the access and enable 
> passwords.  They know that other miscreants are doing the 
> same thing.  In fact this is even more widespread thanks to a 
> module found in rBot and rxBot.  Yes, even bots are scanning 
> for routers now.
> 
> If there are new or changed ACLs, look out!  The miscreants 
> love to use routers as IRC bounces.  To avoid detection by 
> IRC server proxy monitors, the miscreants will block access 
> to the router (generally all access, sometimes just TCP 23) 
> from those proxy monitors using ACLs.
> 
> If there are new or changed SNMP RW community strings, look out!
> One of the tricks they employ is to leave a SNMP RW community 
> backdoor.  Is this to avoid the actions of we good folk?  No, 
> it's usually employed in the case where a compromised router 
> is stolen from one miscreant by another.
> 
> If the banner has changed, look out!  As with the ACLs, this 
> is a method by which the miscreants attempt to fool any proxy 
> monitors.
> The most common banner we see identifies the router as a FreeBSD box.
> 
> If tunnels suddenly appear on the router, look out!  Chaining 
> together lots of routers is also common now.  This provides 
> obfuscation and sometimes encryption.
> 
> Most of the changes are based on templates.  Consider this 
> bundled clue, where the prowess of the template user isn't at 
> all a factor.
> 
> Use the flows.  :)
> 
> Thanks,
> Rob.
> --
> Rob Thomas
> Team Cymru
> http://www.cymru.com/
> ASSERT(coffee != empty);
> 

RE: md5 for bgp tcp sessions

[Barry Greene (bgreene)]

 

> my understanding is that md5 is still checked before the 
> ttl-hack check takes place on cisco (and perhaps most router 
> platforms).  new attack vector for less security than you had 
> before.  oh well.  ras:
> can you confirm that it is possible to implement ttl-hack and 
> have it check *before* md5 signature checks?

You do not have a correct understanding of how GPTM is suppose to work.
If you can, you need to do this check as close to the punt out of the
data plane as possible. Optimally in the ASIC (if the ASIC can be coded
to do a TTL check). On Cisco gear we're coding from inside out - doing
GPTM in the routing code (BGP) - then in the receive path wrapper (rACL
and CoPP) - then in the ASIC raw queue (if it can) - then in the ASIC's
receive path primitives. The GPTM was all about dropping the packet
before they got near the route process. 

If you want more details, let me know and I'll send them privately.
 

RE: OSPF -vs- ISIS

[Barry Greene (bgreene)]

 


> For more information, see the talk by Dave Katz at 
> http://www.nanog.org/mtg-0006/katz.html
> 
> Also, AOL's experience in switching from OSPF to ISIS is 
> covered at http://www.nanog.org/mtg-0310/gill.html
> the PDF on that page is actually an older version. The full 
> version I used at NANOG is available at 
> http://www.vijaygill.com/oi.pdf

Add Ryan's talk about other security benefits of ISIS:

Implications of Securing Backbone Router Infrastructure
http://www.nanog.org/mtg-0405/mcdowell.html

Also look at the other ISIS talks and tutorials here:

http://www.nanog.org/subjects.html#I

RE: Best practice ACLs for a internet facing border router?

[Barry Greene (bgreene)]

I do not think there is a "best practice." In fact, "Operational
Entropy"(1) has a big factor with packet filtering ACLs on the
interconnect side of an SP. So you are not going to find a lot of packet
filtering on SP-SP links.

There are links and presentations you can refer to help build a iACL
(Infrastructure protecting ACL). 

Whitepaper on Infrastructure ACLs (iACLs)
http://www.cisco.com/en/US/products/sw/iosswrel/ps1838/products_white_pa
per0900aecd802b8f21.shtml
(principles in this one can be converted to any packet filter)

Team CYMRU's Secure Templates:
http://www.cymru.com/Documents/secure-ios-template.html
http://www.qorbit.net/documents/junos-template.pdf

Next Gen Peering Architectures and Tools
ftp://ftp-eng.cisco.com/cons/isp/security/CPN-Summit-2004/Paris-Sept-04/
File:
SE12-NEXT-GENERATION-PEERING-AND-INTERCONNECTION-ARCHITECTURES-10120_08_
2004_c1_SE12.pdf


(1) Operational Entropy is the process of natural decay that starts the
moment the policy gets applied. OPEX resources need to be allocated to
insure the entropy does not lead to operational consequence (i.e. the
decayed policy breaks things).


> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On 
> Behalf Of Drew Weaver
> Sent: Monday, June 13, 2005 7:28 AM
> To: nanog@merit.edu
> Subject: Best practice ACLs for a internet facing border router?
> 
> 
>   I'm just curious if anyone has ever published a list of 
> what is an agreed upon best practice list of ACLs for an 
> internet facing border router. I'm talking about things like 
> bogons, private Ip addresses, et cetera. If anyone is aware 
> of anything like this I'd like to see it.
> 
> Thanks,
> -Drew
>  
>