July 2000 - NANOG - lists.nanog.org

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

RE: RBL-type BGP service for known rogue networks?
by rdobbins＠netmore.net 12 Jul '00

12 Jul '00

ORBS forge headers (thereby violating the RFC) to look as if they're coming from domains you host, then if it goes through, they put you in their little black book for being an 'open relay'. No notice, nothing. The problem with this is that for hosting-only providers like my firm, it's blatantly unfair. We have thousands of users residing on networks (lots of dynamic addresses) all over the world who have domains hosted with us; they also have email aliases for the domains they host here. And while we encourage them to use IMAP, it's like herding cats to get any substantial percentage doing anything other than basic POP and SMTP. POP-before-SMTP isn't viable for the same reason that it's extremely difficult to get people to use IMAP; to wit, users tend to resist change. In a corporate environment, you can force remote users to use additional authentication mechanisms, as long as you're willing to set them up and train the users. Out here in the world, though, if you come down on people over something which forces them to change the way they do things in any substantial way, they vote with their feet and go to some other provider who not only doesn't secure his mail relay, but ignores spam complaints, as well. Our NOC staff act -immediately- upon any complaints of spam or forged mail - no one has ever acused us of being a spam-house or anything other than spammer-*unfriendly*. And yet, due to the current well-known limitations of SMTP as currently defined in the standard, their blatant adoption of RFC-violating spammer tactics, and their unwillingness to acknowledge that not every provider offers transport to his userbase (thereby rendering address-based validation unworkable), the ORBS folks decide to tar my organization with the same brush as, say, rr.com. No discussion, no examination of our track record and response-times, nada. Where's the equity in that, I ask you? ----------------------------------------------------------- Roland Dobbins <rdobbins(a)netmore.net> // 818.535.5024 voice -----Original Message----- From: Peter van Dijk [mailto:petervd@vuurwerk.nl] Sent: Saturday, July 08, 2000 10:15 AM To: nanog(a)merit.edu Subject: Re: RBL-type BGP service for known rogue networks? On Sat, Jul 08, 2000 at 12:35:14PM -0400, Greg A. Woods wrote: > > [ On Saturday, July 8, 2000 at 08:42:41 (-0700), Randy Bush wrote: ] > > Subject: Re: RBL-type BGP service for known rogue networks? > > > > > ORBS lists open relay by policy. As simple as that. If ORBS is aware that > > > you are an open relay, you get listed. ORBS is 100% objective. > > > > as we all know, this is utter horsepucky. orbs goes vigilante crazy and > > blackholes entire isp blocks over political poweplay nonsense. > > Listing a net-block that has several proven open relays within it but > which will not allow testing, is not "going vigilante crazy" -- it's a > very very reasonable and well thought out reaction (i.e. there is no > lesser action possible since the originally tested open relays have been > moved to new address space within the block). Let me explain some things: - ORBS does not blackhole. It lists hosts and sometimes complete netblocks. $administrator can then choose to take any action (or not!) based on these listings. - ORBS lists hosts in several categories. One is 'open relay inputs'. Another is 'open relay outputs' (most open relays will be both). Yet another is 'untested/untestable'. Hosts/netblocks can end up in this last category in two ways: - by request from the admin of that host/netblock - when ORBS finds out that they are being blocked specifically. It is therefore incorrect to state 'ORBS blackholes whole netblocks'. These netblocks are listed *different* from open relays. The admin that decides to use ORBS has a choice to block *only* open relays, or also block hosts that do not want to be tested by ORBS. I hope this clears things up. > It is critically important to also realise that "ORBS" itself doesn't > "go crazy" and do these things -- such "rogue net-block" listings are > directly a result of pressure from ORBS users. Such users who continue > to get spam from relays they've reported to ORBS for testing will > complain and put pressure on the ORBS administrators until there is no > other choice but to list the entire offending net-block. Nope. ORBS doesn't do 'user pressure'. Such net-block listings (as 'untestable', not as 'open relay') are only done based on actions/requests by admins responsible for these netblocks. > Use of the term "blackhole" in this context is not only wrong but also > misleading. It is very important to understand that ORBS users are free > to programmatically ignore, in real time, that section of the ORBS > database which lists the so-called "rogue" net-blocks and only use the > section of the database which contains actually verified relay results. Correct, this is what I explained above. > In my humble opinion any admin who permits their mailer to receive any > e-mail from a known open relay (even so-called legitimate e-mail, since > there's absolutely no way to identify legitimacy at the protocol level) > is an accessory to any theft-of-service attack perpetrated on the relay, > and is furthermore "guilty" in part of allowing known spam to reach > their end users (assuming of course that they are willing to do anything > at all in the first place to protect their users from unsolicited junk > e-mail). To this end an impartial and independent testing service such > as ORBS is critical to the success of such efforts. The other services > you mention are valuable, but nowhere near as powerful, and they are far > more susceptible to unnecessary delays (time is critical in spam > fighting!), and by definition they are more susceptible to human error. Yes. On the other hand, one might say that you as an admin do not have the right to block *any* mail for your users. This is solved by for example just inserting headers based on ORBS-listing and not outright rejecting mail, and then leaving the choice to your users thru procmail or other per-user filtering means. > Finally it cannot be pointed out enough times that the administrators of > the so-called "rogue" blocks need only change their attitudes and > co-operate with ORBS in order to make this issue completely go away. Correct. > Any SMTP service administrator who believes that SMTP port is totally > private property is sadly mistaken and should firewall it if they really > want it to be private. Being irrational about public testing of public > services is, frankly, insane. Public testing by a known independent > non-profit agency should be vigorously welcomed by all network admins! Correct again. AboveNet blackholing ORBS is therefore an action I do not understand, especially since they host MAPS. I see 2 possibilities: - MAPS doesn't test if a reported spamhouse is really an open relay, and is therefore susceptible to forgery. - MAPS does do open relay testing and therefore performs the same 'unsolicited traffic' as ORBS, which would mean they're hypocritic. Greetz, Peter. -- petervd(a)vuurwerk.nl - Peter van Dijk [student:developer:ircoper]

22 43

abov engineers(network)
by jamie＠next.hway.net 11 Jul '00

11 Jul '00

All, sorry for the slightly-non-technical post, I'm looking for an ABOV engineer who has a few minutes to engage me in some technical (and non-technical) chatter regarding ABOV and its data centers. You can only get so far through normal channels, and I'm not really getting the 'real' answers I'm looking for. I won't quote you on anything, just looking for more realistic things. Please reply privately. Thanks, -jamie

1 0

Multiple providers w/o BGP (was: Re: Arrowpoint Load Balancing Devices)
by Timothy Brown 11 Jul '00

11 Jul '00

> Thank you for your interest in ArrowPoint Communications > On June 23, 2000, Cisco Systems completed its acquisition of ArrowPoint > Communications. > ... > > No Cisco's, eh? (-; The company I work for has its offices in a building Cisco mostly occupies. There have been Arrowpoint engineering staff in and out all week getting badges for a move-in within the next 2-3 weeks. As an aside containing actual internet operational content, are there any pointers onna web to redundancy and load-balancing solutions NOT using BGP? I'm pretty much talking about two different providers with different addressing schemes trying to connect to a third party who is a customer of both providers, but who cannot justify a /20. What are my primary options here for connectivity to the customer (short of adding three or four completely seperate production networks to the justification request)? > Alan -- Timothy Brown tcb(a)ga.prestige.net

2 1