RE: [admin] [summary] RE: YouTube IP Hijacking
-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: http://www.secsup.org/CustomerBlackHole/ (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: YouTube IP Hijacking
-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.
RE: [admin] [summary] RE: YouTube IP Hijacking
-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-
FW: [menog] FLAG Cable Cut - Update
-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.
-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
-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
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: Where are static bogon filters appropriate? was: 96.2.0.0/16 Bogons
-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: Bogon Filter - Please check for 77/8 78/8 79/8
- 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-FILTERSform_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
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 | | 8228 | 32352 | FR | CEGETEL-AS CEGETEL ENTREPRISES
RE: different flavours of uRPF [RE: register.com down sev0?]
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 CCs has become useless
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.
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
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
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
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
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
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?
(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?
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?
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
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
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?
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
