June 2005 - NANOG - lists.nanog.org

RE: md5 for bgp tcp sessions
by Hannigan, Martin 23 Jun '05

23 Jun '05

> -----Original Message----- > From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of > Todd Underwood > Sent: Thursday, June 23, 2005 5:57 AM > To: Richard A Steenbergen > Cc: nanog(a)merit.edu > Subject: Re: md5 for bgp tcp sessions > > > > ras, all, > > On Thu, Jun 23, 2005 at 12:14:12AM -0400, Richard A Steenbergen wrote: > > On Wed, Jun 22, 2005 at 10:04:09PM -0400, Todd Underwood wrote: > > rolling out magic code because your > vendor tells you to is a bad idea; That's mostly the result of the calamitous failure in vulnerability release methodology, not Operator stupidity. -M<

3 2

Level3
by Robert Mathews 23 Jun '05

23 Jun '05

Good morning.. Have any noted significant performance issues (routing loops etc.) in interconnects with Level3 infrastructure - particularly in Chicago, New York or Seattle within the last 4 days? Any feedback offline would be great. Thank you.

1 0

Re: Localized mail servers, global scope
by Dave Stewart 23 Jun '05

23 Jun '05

>how many different bandaids are applied. It is time >to re-engineer with the benefit of hindsight. However desirable this may be, don't you agree that no matter what mechanism comes along, there's a huge inertia to overcome. We can debate the correct way to handle email forever. But of greater interest would be how you're going to get everyone to go along and change.

1 0

RE: md5 for bgp tcp sessions
by Barry Greene (bgreene) 23 Jun '05

23 Jun '05

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

1 0

openning party on 06/25/2005 11pm Coordinated Universal Time
by codewarrior＠cuseeme.de 23 Jun '05

23 Jun '05

morning all , experts i am proud to announce a european cuseeme test reflector cuseeme was a free available peer 2 peer multiconferencing videoconferencing application for mac and pc more info about installation and history: http://www.cuseeme.de/ its open now cuseeme.dyndns.tv CID 0 64/150 regards the the cu-team *********************************** join its free http://www.isabel.de/ and support free cuseeme

1 0

Re: OSPF -vs- ISIS
by Dan Evans 23 Jun '05

23 Jun '05

Thanks to everyone who offered advice and links to resources. The information I've gathered with your help will greatly assist me moving forward, regardless of our decision on which protocol to use. Regards, Daniel

1 0

RE: OSPF -vs- ISIS
by Barry Greene (bgreene) 22 Jun '05

22 Jun '05

> 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

2 1

Shared bandwidth and QoS
by Eric Gauthier 22 Jun '05

22 Jun '05

Heya, We have a situation where multiple organizations are all going to be sharing a gigabit ethernet based Internet feed. We've each agreed to "purchase" a percentage of the cost of the feed. The topology is roughly: (Inbound GigE 802.1q Trunk) ----------------------------------->Collective Router w/eBGP to ISP------>ISP | --Org #1, eBGP Peer 1, SubInt 1 | --Org #2, eBGP Peer 2, SubInt 2 | | .. etc What we'd like to do is to set things up so that each institution always has access to their percentage of the ISP link bandwidth and, if there is additional bandwidth available, provide that everyone. The only way I can think to accomplish this is via rate limits and priority queuing, but it looks as though I'll need to mark and/or rewrite the TOS bits in everyone's packets to do so. Does anyone have a better way of accomplishing this? Eric :)

1 0

Re: OSPF -vs- ISIS
by Eric Gauthier 22 Jun '05

22 Jun '05

On Tue, Jun 21, 2005 at 03:16:06PM +0100, Richard Dumoulin wrote: > Hi Eric, what's the reason for migrating to ISIS? There are currently a few projects that we're doing which prompted us to take a look at how we're doing routing, both IGP and EGP. We're altering our border connectivity by spreading our multiple commodity Internet and Internet2 peers across multiple routers that connect into our core at multiple locations. As a result, we're likely to bring iBGP into our core and, clearly, this is going to alter our IGP setup. We're also looking into MPLS layer 2 VPNs to solve certain traffic classification issues (e.g. limiting I2 access, allowing "guest wireless" etc), which also means that we'd likely need to make modifications to our IGP/EGP setup. Though we filter OSPF multicast traffic, we wanted to add in MD5 passwords to our neighbors. We're deploying IPv6 within our campus, so we needed to look for an IGP to support this. Since we're going to have to make changes, some significant, to our IGP setup (currently multi-area OSPF) no matter what, we felt it made sense to review our options. It looks like IS-IS and OSPF are pretty much the same in terms of functionality. IS-IS, though, looks like it handles IPv6 networks more efficiently, its area scheme seems to match a little more to our topology, and the "security' element (i.e. you can't inject packets) of the adjacencies seems interesting. Also, as I said, we're likely going to move to an iBGP-based core, which seems to run parrallel to what service providers are doing, so I have to admit that "follow the leader" also played into the decision as larger ISP seem to be doing the iBGP/IS-IS combo. Eric :)

1 0

IANA IPv4 allocations and bogon updates: 74/8, 75/8, 76/8, 189/8, 190/8
by Rob Thomas 22 Jun '05

22 Jun '05

-----BEGIN PGP SIGNED MESSAGE----- [ Apologies to those of you who receive this note in multiple forums. ] Hi, all. The numerous Team Cymru bogon projects have been updated as of 17 JUN 2005 to reflect the following IANA allocation made on 17 JUN 2005: 074/8 Jun 05 ARIN (whois.arin.net) 075/8 Jun 05 ARIN (whois.arin.net) 076/8 Jun 05 ARIN (whois.arin.net) 189/8 Jun 05 LACNIC (whois.lacnic.net) 190/8 Jun 05 LACNIC (whois.lacnic.net) IANA allocations change over time, so please check regularly to ensure you have the latest filters if you are not using the bogon BGP feed(s). We do announce updates to the bogon projects to sundry lists, such as the bogon-announce list. We can not stress this point strongly enough - these allocations change. If you do not adjust your filters, you will be unable to access perhaps large portions of the Internet. Worse yet, you may end up blocking access for people who transit through you. Please do not apply any filters or blocks to your network without carefully considering the ramifications of doing so. As a point of reference, the Team Cymru master Bogon Reference Page can be found here: <http://www.cymru.com/Bogons/> A quick summary of the documents and projects that have been updated include the following: HTTP The Bogon List - <http://www.cymru.com/Documents/bogon-list.html> The Text Bogon Lists - <http://www.cymru.com/Documents/bogon-bn-nonagg.txt> - <http://www.cymru.com/Documents/bogon-bn-agg.txt> Secure BIND Template - <http://www.cymru.com/Documents/secure-bind-template.html> Secure IOS Template (Cisco) - <http://www.cymru.com/Documents/secure-ios-template.html> Secure BGP Template (Cisco) - <http://www.cymru.com/Documents/secure-bgp-template.html> Secure JUNOS Template (Juniper) - <http://www.cymru.com/gillsr/documents/junos-template.htm> Secure JUNOS BGP Template (Juniper) - <http://www.cymru.com/gillsr/documents/junos-bgp-template.htm> Ingress Prefix Filter Templates, Loose and Strict (Cisco) - <ftp://ftp-eng.cisco.com/cons/isp/security/Ingress-Prefix-Filter- Templates/> Ingress Prefix Filter Template, Loose (Juniper) - <http://www.cymru.com/gillsr/documents/junos-isp-prefix-filter-loose.htm> Ingress Prefix Filter Template, Strict (Juniper) - <http://www.cymru.com/gillsr/documents/junos-isp-prefix-filter-strict.htm> BGP Bogon route-server for AUTOMATED updates of bogon filters - All bogon route-server peers have already received the appropriate BGP prefix updates. - <http://www.cymru.com/BGP/bogon-rs.html> RADb fltr-unallocated fltr-martian fltr-bogons - <http://www.cymru.com/Bogons/index.html#radb> RIPE NCC fltr-unallocated fltr-martian fltr-bogons - <http://www.cymru.com/Bogons/index.html#ripe> DNS Bogon (bogons.cymru.com) zone - <http://www.cymru.com/Bogons/index.html#dns> Monitoring Bogon prefix monitoring - <http://www.cymru.com/BGP/robbgp-bogon.html> Bogus ASN monitoring - <http://www.cymru.com/BGP/asnbogusrep.html> Please feel free to contact Team Cymru <team-cymru(a)cymru.com> with any comments, questions, or concerns. Thank you for your continued support. Rob, for Team Cymru. - -- Rob Thomas http://www.cymru.com Shaving with Occam's razor since 1999. -----BEGIN PGP SIGNATURE----- Version: PGP 6.5.2 iQCVAwUBQrjLPlkX3QAo5sgJAQFHwAP/Z8KrLp9id6PD51KNEjAlveJCxRnvP4ev RofqRMex1SB5itogkB4O6JmrpSqIjqgM2GsnAUREZr5/r2ekdAZwejT85zHftl92 3ExvEec3P2PVDdfWF5v9TSVWfzwwbMW2HWwymzUYT7klWpjblcUUPdAWl+khD+FU /C8cCA2b8qk= =JvMq -----END PGP SIGNATURE-----

1 0