- Test - lists.nanog.org

It's about time they got him! (Off Topic)
by Bill Sehmel 12 Jul '00

12 Jul '00

Yahoo is running an artical on Raymond Torricelli being locked up. He is a known cracker by the name of "rolex" and used to head the lamer gang "conflict" http://dailynews.yahoo.com/h/nm/20000712/tc/crime_hacker_dc_1.html -Bill Sehmel

1 0

Re: MD5 in BGP4
by Sean Donelan 12 Jul '00

12 Jul '00

On Wed, 12 July 2000, Danny McPherson wrote: > I suggest you go (re?)read RFC 2385. Intuitively, > it's called the TCP MD5 Signature Option, not the > BGP MD5 Signature Option. It wasn't clear in your original message you were speaking about RFC 2385, I assumed you were using the authentication option built into BGP in RFC 1654.

1 0

RE: Running BGP4 on a Core Router
by Dmitri Krioukov 12 Jul '00

12 Jul '00

that is, your ip core and edge are sort of very "close" to each other. it's not like, say, in uunet, where this architectural distance is greater. true? -- dima. > -----Original Message----- > From: Chris Liljenstolpe [mailto:chris@cw.net] > Sent: Wednesday, July 12, 2000 7:13 AM > To: Dmitri Krioukov; Bora Akyol > Cc: nanog > Subject: RE: Running BGP4 on a Core Router > > > Dimirtri, > > I have to disagree with you on this statement. While the > physical trunks > are not connecting routers together in the C&W network, there is most > definately an IP core. The L2 core provides a mesh for core routers at > each site, wich provide the hierarchy for edge/fannout routers. > Therefore > we have both an IP and L2 core with the IP core overlayed over > the L2 core. > > Chris > > > --On Tuesday, 11 July 2000 21.54 -0400 Dmitri Krioukov > <dima(a)krioukov.net> > wrote: > > > > > we can even imagine some core that is > > not ip core but, say, atm core and all > > lsrs are atm-lsrs. > > > > actually some providers (like c&w) > > have exactly this no ip core, overlay > > model. it's far from being the best one. > > -- > > dima. > > > >> -----Original Message----- > >> From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of > >> Bora Akyol > >> Sent: Monday, July 10, 2000 12:10 AM > >> To: nanog > >> Subject: Re: Running BGP4 on a Core Router > >> > >> > >> > >> Even with MPLS, you need to run some sort of a routing protocol. > >> > >> ISIS or OSPF with TE extensions would do. > >> > >> One can also use BGP with MPLS Label extensions as well. By > the way, how > >> does this work with route reflectors? > >> > >> > >> Bora > >> > >> > >> ----- Original Message ----- > >> From: "Jesper Skriver" <jesper(a)skriver.dk> > >> To: "HANSEN CHAN" <hansen.chan(a)alcatel.com> > >> Cc: <nanog(a)merit.edu> > >> Sent: Sunday, July 09, 2000 8:20 PM > >> Subject: Re: Running BGP4 on a Core Router > >> > >> > >> > > >> > On Sun, Jul 09, 2000 at 07:49:37PM -0400, HANSEN CHAN wrote: > >> > > > >> > > Hi folks, > >> > > > >> > > I was hearing that typically BGP4 is run on all routers > inside a POP, > >> > > including access routers connecting to customers, border routers > >> > > connecting other ISPs and core routers connecting to other POPs in > >> > > the same network. > >> > > > >> > > I can understand why BGP4 is run on access and border routers. But > >> > > running BGP4 on core routers is beyond my understanding. I thought > >> > > you don't need to run BGP4 on core routers which are > considered to be > >> > > interior nodes. > >> > > > >> > > Can someone shed some light on what is the benefit of > running BGP4 on > >> > > the core routers? > >> > > >> > If these routers run "normal" ip routing you have to, as each router > >> > does a lookup of the destination ip address of each packet, > and forward > >> > it accordingly. > >> > > >> > If you run MPLS, you don't have to, as it uses labels to get to the > >> > next-hop router. > >> > > >> > /Jesper > >> > > >> > -- > >> > Jesper Skriver, jesper(at)skriver(dot)dk - CCIE #5456 > >> > Work: Network manager @ AS3292 (Tele Danmark DataNetworks) > >> > Private: Geek @ AS2109 (A much smaller network ;-) > >> > > >> > One Unix to rule them all, One Resolver to find them, > >> > One IP to bring them all and in the zone to bind them. > >> > > >> > > > > > > >

1 0

Re: MD5 in BGP4
by Steven M. Bellovin 12 Jul '00

12 Jul '00

In message <200007121609.KAA09225(a)tcb.net>, Danny McPherson writes: > > >The primary goal of the BGP MD5 signature option is >to protect the TCP substrate from introduction of >spoofed TCP segments such a TCP RSTs. These segments >could easily be injected from anywhere on the Internet. > >Lots of service providers employ the TCP MD5 signature >option stuff to protect both internal and external BGP >sessions in their networks. It really doesn't matter >if the neighbors are directly connected or not, BGP >rides on IP and is therefore vulnerable to "packet bombs" >and the like from anywhere, regardless of whether the >peer is internal, external or external multi-hop. > >Expoliting such a vulernability is trivial, actually, in >any of these configurations. All one needs to know is a >tiny amount of information associated with the BGP session. >Though MD5 clearly isn't perfect, it does make is >considerably more difficult. > >Using MD5 stuff with IP-based protocols such as BGP & OSPF >is strongly advised. Obviously, IS-IS and similar protocols >are less vulnerable. Right. To learn how to hijack a TCP session, see @inproceedings{hijack, title = {A Simple Active Attack Against {TCP}}, author = {Laurent Joncheray}, year = 1995, booktitle = {Proceedings of the Fifth Usenix \Unix\ Security Symposium}, address = {Salt Lake City, UT} } IPsec protection is even stronger than the MD5 signature option described in RFC 2385, but 2385 if *far* better than nothing. (Btw -- since 2385 requires a TCP option, it's implemented in the stack, and not at application level.) --Steve Bellovin

1 0

Re: MD5 in BGP4
by Danny McPherson 12 Jul '00

12 Jul '00

The primary goal of the BGP MD5 signature option is to protect the TCP substrate from introduction of spoofed TCP segments such a TCP RSTs. These segments could easily be injected from anywhere on the Internet. Lots of service providers employ the TCP MD5 signature option stuff to protect both internal and external BGP sessions in their networks. It really doesn't matter if the neighbors are directly connected or not, BGP rides on IP and is therefore vulnerable to "packet bombs" and the like from anywhere, regardless of whether the peer is internal, external or external multi-hop. Expoliting such a vulernability is trivial, actually, in any of these configurations. All one needs to know is a tiny amount of information associated with the BGP session. Though MD5 clearly isn't perfect, it does make is considerably more difficult. Using MD5 stuff with IP-based protocols such as BGP & OSPF is strongly advised. Obviously, IS-IS and similar protocols are less vulnerable. -danny > BGP is a TCP based protocol and is normally run only to an adjacent > peer. This combination makes it very hard to break into. You have to > have another system on the shared media send a spoofed packet with > bogus information that fits the TCP stream and the BGP status for that > peering (and many BGP connections are point-to-point, making even > this impossible). > > Multi-hop BGP is a different beast and much more likely to be subject > to attack, but it's also pretty rare and such an attack would still be > very difficult.

2 1

Re: MD5 in BGP4
by Danny McPherson 12 Jul '00

12 Jul '00

I suggest you go (re?)read RFC 2385. Intuitively, it's called the TCP MD5 Signature Option, not the BGP MD5 Signature Option. Again, it's not insurmountable, though it is far, far better than nothing. -danny > BGP MD5 signatures do not protect the TCP/IP stream from > spoofed TCP RSTs. The MD5 signature is checked at the > BGP application layer after passing through and being > acted on by the TCP stack. You can play all sorts of > MAC, ARP, ICMP, IP and TCP games with the stream which > MD5 won't prevent.

1 0

Re: MD5 in BGP4
by Sean Donelan 12 Jul '00

12 Jul '00

On Wed, 12 July 2000, Danny McPherson wrote: > The primary goal of the BGP MD5 signature option is > to protect the TCP substrate from introduction of > spoofed TCP segments such a TCP RSTs. These segments > could easily be injected from anywhere on the Internet. BGP MD5 signatures do not protect the TCP/IP stream from spoofed TCP RSTs. The MD5 signature is checked at the BGP application layer after passing through and being acted on by the TCP stack. You can play all sorts of MAC, ARP, ICMP, IP and TCP games with the stream which MD5 won't prevent. Why we haven't seen more of these attacks I don't know for sure.

2 1

Re: IS-IS authentication
by Danny McPherson 12 Jul '00

12 Jul '00

> The deployed form of IS-IS uses CLNP not IP for transmission, > making it less vulnerable to inter-domain attacks -- provided > that there is no inter-domain CLNP connectivity (generally > true, but not always true). IS-IS is not particularly any > less vulnerable from intra-domain attacks. Actually, IS-IS runs directly over the link layer, it doesn't employ CLNP or IP (unless you're using some tunneling hack such as IS-IS over GRE, but...). As for intra-domain CLNP packet forwarding, though a few networks had supported this for a while, fewer (do any?) ISPs do it today and most new IS-IS supporting routers don't provide capability for anything other than IP packet forwarding. As for inter-domain CLNP -- ha :-) > Hence, the IETF IS-IS WG has a draft proposal for adding OSPF-like > MD5 authentication into IS-IS. The addition of MD5 authentication > into IS-IS specifications was driven by some large Tier-1 ISPs > who happen to use IS-IS internally and felt there was significant > risk without it. Oh, I certainly agree that it's useful, though IS-IS is clearly not as vulnerable as IP-based protocols. -danny

1 0

Re: MD5 in BGP4
by Walter Prue 12 Jul '00

12 Jul '00

> "HANSEN CHAN" wrote: >>I understand that MD5 is quite commonly used in IGP such as OSPF but not >>in BGP4. Am I correct? Can someone explain to me why? Shouldn't one be >>more concerned the session being hijacked when talking to another >>network? >i believe this is because bgp will not establish a session unless the other >end is directly connected. hence the reason for ebgp-multihop. so unless >somebody drops a physical line into your router and configures it, you >shouldn't have a problem. The norm for E-BGP is that the packets to the neighbor are created with a TTL of 1 making the packets die if they are not addressed to a neighbor one hop away. However some folks run multihop BGP for various reasons. When they do they may not be so careful setting the hop count. However, regardless of how a well behaved router acts, a misbehaving node can violate these rules and set the hop count to anything that suites their twisted purposes. Most routers won't check to see that a packet, it is forrwarding, is sourced from its own IP address and thus not detect that a misbehaving node multiple hops away is trying to attack its BGP neighbors BGP TCP session. A full hijack of the session however would be less likely because the return packets are unlikely to reach the misbehaving node. So a misbehaving host could potentially cause a session reset and a route flap but not persist in a hijacked BGP session, feeding and consuming routing updates. When a general purpose node (ie. Unix node) is between two EBGP speakers running multihop BGP such an attack is possible. It is also quite possible in a situation where BGP speakers are on a shared media. Walt Prue

1 0

Re: MD5 in BGP4
by Walter Prue 12 Jul '00

12 Jul '00

> "HANSEN CHAN" wrote: >>I understand that MD5 is quite commonly used in IGP such as OSPF but not >>in BGP4. Am I correct? Can someone explain to me why? Shouldn't one be >>more concerned the session being hijacked when talking to another >>network? >i believe this is because bgp will not establish a session unless the other >end is directly connected. hence the reason for ebgp-multihop. so unless >somebody drops a physical line into your router and configures it, you >shouldn't have a problem. The norm for E-BGP is that the packets to the neighbor are created with a TTL of 1 making the packets die if they are not addressed to a neighbor one hop away. However some folks run multihop BGP for various reasons. When they do they may not be so careful setting the hop count. However, regardless of how a well behaved router acts, a misbehaving node can violate these rules and set the hop count to anything that suites their twisted purposes. Most routers won't check to see that a packet, it is forrwarding, is sourced from its own IP address and thus not detect that a misbehaving node multiple hops away is trying to attack its BGP neighbors BGP TCP session. A full hijack of the session however would be less likely because the return packets are unlikely to reach the misbehaving node. So a misbehaving host could potentially cause a session reset and a route flap but not persist in a hijacked BGP session, feeding and consuming routing updates. When a general purpose node (ie. Unix node) is between two EBGP speakers running multihop BGP such an attack is possible. It is also quite possible in a situation where BGP speakers are on a shared media. Walt Prue

1 0