Re: Comcast enables 6to4 relays
On Sat, 28 Aug 2010, John Jason Brzozowski wrote: In most cases, we observed that 6to4-enabled operating systems and devices were attempting to use a 6to4 relay infrastructure hosted by a midwestern university. Before that they used our (Tele2) 6to4 relays in Amsterdam and Paris. I think this was discussed here 1-2 years back. I couldn't find it, but http://gpshead.blogspot.com/2009/01/consumer-router-ipv6-firewall-fail.html says the same thing. I urge more people to look up what 6to4 relays you're using and set up your own if needed. People *are* using it and you not doing it is making things worse for your customers. Yes, 6to4 is generally bad but it's out there. Everybody needs to think about it. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: Did your BGP crash today?
On Sat, 28 Aug 2010, Brett Frankenberger wrote: The implementor is to blame becuase the code he wrote send out BGP messages which were not properly formed. People talk about not dropping sessions but instead dropping malformed messages. This is not safe. We've seen ISIS (which is TLV based and *can* drop individual messages) been wrongly implemented and platforms drop the entire ISIS *packet* instead of the individual message when seeing something malformed (or rather in this case, ISIS multi topology which the implementation didn't understand), and this made the link state database go out of sync and miss information for things it actually should have understood. This was *silent* error/corruption. I'm not sure I prefer to have silent problems instead of tearing down the session which is definitely noticable. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: Did your BGP crash today?
This was *silent* error/corruption. I'm not sure I prefer to have silent problems instead of tearing down the session which is definitely noticable. i call the silent fix do-gooder software. it means to do good. when it works, nobody notices or says thanks. when it fails, there is hell to pay. randy
Re: Did your BGP crash today?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, Aug 29, 2010 at 12:23 AM, Mikael Abrahamsson swm...@swm.pp.se wrote: On Sat, 28 Aug 2010, Brett Frankenberger wrote: The implementor is to blame becuase the code he wrote send out BGP messages which were not properly formed. People talk about not dropping sessions but instead dropping malformed messages. This is not safe. We've seen ISIS (which is TLV based and *can* drop individual messages) been wrongly implemented and platforms drop the entire ISIS *packet* instead of the individual message when seeing something malformed (or rather in this case, ISIS multi topology which the implementation didn't understand), and this made the link state database go out of sync and miss information for things it actually should have understood. This was *silent* error/corruption. I'm not sure I prefer to have silent problems instead of tearing down the session which is definitely noticable. It would seem to me that there should actually be a better option, e.g. recognizing the malformed update, and simply discarding it (and sending the originator an error message) instead of resetting the session. Resetting of BGP sessions should only be done in the most dire of circumstances, to avoid a widespread instability incident. - - ferg -BEGIN PGP SIGNATURE- Version: PGP Desktop 9.5.3 (Build 5003) wj8DBQFMegyGq1pz9mNUZTMRAr6tAKDHDZk2/Yk3bHNKTvCJeniTCEdPvwCg0zhk HX/E0XsFOIURWI8UlfpM2Ms= =PSz3 -END PGP SIGNATURE- -- Fergie, a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/
Complain to your vendors (was Re: Did your BGP crash today?)
Guys/girls/furry-creatures-from-!Earth, Complaining on nanog-ml is likely to only achieve personal stress relief. This is something you should bring up with your vendor. Say that you'll move vendors if they don't start making better BGP implementations and adding the features you guys want. Make the list of better features open, public, and actively solicit alternatives. Follow up on your threat. This is your business bottom line after all. Don't just use it as a reason to get lower prices from your current vendor and then continue complaining when dumb crap like this occurs. It would be great if vendor(s) participated in a public interoperability test suite where researchers could test their stuff against it before unleashing it on the public internet. I'd love to see something public -and- cross institutional, -and- include access to things like CRS-level equipment. Go on, I dare you. :) 2c, Adrian
Re: Complain to your vendors (was Re: Did your BGP crash today?)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, Aug 29, 2010 at 12:35 AM, Adrian Chadd adr...@creative.net.au wrote: Guys/girls/furry-creatures-from-!Earth, Complaining on nanog-ml is likely to only achieve personal stress relief. This is something you should bring up with your vendor. Say that you'll move vendors if they don't start making better BGP implementations and adding the features you guys want. Make the list of better features open, public, and actively solicit alternatives. Follow up on your threat. This is your business bottom line after all. Don't just use it as a reason to get lower prices from your current vendor and then continue complaining when dumb crap like this occurs. It would be great if vendor(s) participated in a public interoperability test suite where researchers could test their stuff against it before unleashing it on the public internet. I'd love to see something public -and- cross institutional, -and- include access to things like CRS-level equipment. Go on, I dare you. :) Maybe the NANOG conference committee (or whatever its called) could get a couple of major router vendor gerbils to come to the next NANOG and talk to this issue? Maybe? Okay, I give up. - - ferg -BEGIN PGP SIGNATURE- Version: PGP Desktop 9.5.3 (Build 5003) wj8DBQFMeg7Uq1pz9mNUZTMRAtLzAJwNzJMf4YwjP9C42CFANvESJCVoDQCg9trZ lS5Wd5kpH27JBLKkDhibIOg= =fdTs -END PGP SIGNATURE- -- Fergie, a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/
Re: Did your BGP crash today?
On Aug 29, 2010, at 2:30 PM, Paul Ferguson wrote: It would seem to me that there should actually be a better option, e.g. recognizing the malformed update, and simply discarding it (and sending the originator an error message) instead of resetting the session. Generation of the error message should probably have a user toggle. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken
Re: Comcast enables 6to4 relays
Franck, As you know 6to4 is enabled by default in many cases and is used perhaps more than folks realize. Because of this and other observations we decided to deploy our own relays. This does not alter our plans for our native dual stack trials, in fact, I hope to have more news on this front soon. It is true that 6to4 has challenges, some of these may be related to how 6to4 relays have been deployed. Others may be related to the protocol itself. Either way, by deploying our own we observed an improvement, we hope others have as well. John On 8/28/10 6:06 PM, Franck Martin fra...@genius.com wrote: These are good news. However, if Comcast provides native IPv6 to their customers, then the IPv6 native customers don't need these 6to4 relays? Airport Extreme, Linksys and other user equipment, enable IPv6 by doing 6to4 tunnels, so what this press release says, is that there are many users who are already on IPv6 via Comcast network but not native? Providing relays close to them, is a good transition move. Alternatively, the measurement of this 6to4 bandwidth on IPv4 may give you an idea of the demand for IPv6 from your customers? May be you detected a non null number here? I'm just trying to understand more IPv6 by the examples. I'm personally using 6to4 at home, and experiencing some MTU issues, which seems related to some PTB packets suppressed on the way between some end points, and that can depend on which 6to4 relay I'm using. Still trying to debug this (I'm not too fanatic about it, but work on it when I have a bit of time). I thought I would mention that. The WAND people have done some good studies: http://www.ripe.net/ripe/meetings/ripe-60/presentations/Stasiewicz-Measurement s_of_IPv6_Path_MTU_Discovery_Behaviour.pdf At the office, I have a more classical tunnel with he.net and do not have any issue there. - Original Message - From: John Jason Brzozowski john_brzozow...@cable.comcast.com To: NANOG nanog@nanog.org Sent: Sunday, 29 August, 2010 5:49:30 AM Subject: Comcast enables 6to4 relays FYI - thought this would be of interest to some of you, there will be more news on this front shortly. http://www.comcast6.net/ 6to4 Relays Activated Tuesday, August 17, 2010 As we started our IPv6 trials, we began to observe an increase in 6to4 relay traffic. 6to4 is a transition mechanism built into some operating systems and home gateways. While it is not a transition technology that Comcast planned to invest in due to limitations related to performance, we did observe poor performance when 6to4 was used by our customers. In many cases, these customers were not even aware that 6to4 was enabled by default or that their device or operating system was attempting to use 6to4 to communicate with IPv6 resources on the Internet. = John Jason Brzozowski Comcast Cable e) mailto:john_brzozow...@cable.comcast.com o) 609-377-6594 m) 484-962-0060 w) http://www.comcast6.net =
Re: Comcast enables 6to4 relays
Mikael, I agree with your points and echoed them in my earlier reply. 6to4 is out there and is likely not to go away any time soon. Folks should definitely see what 6to4 relay they default to, you might be surprised (or not). FWIW - I updated ARIN's wiki for 6to4 relay deployment with some generic updates. I will add some more text shortly that folks may find useful if they decide to deploy their own 6to4 relays. John On 8/29/10 3:19 AM, Mikael Abrahamsson swm...@swm.pp.se wrote: On Sat, 28 Aug 2010, John Jason Brzozowski wrote: In most cases, we observed that 6to4-enabled operating systems and devices were attempting to use a 6to4 relay infrastructure hosted by a midwestern university. Before that they used our (Tele2) 6to4 relays in Amsterdam and Paris. I think this was discussed here 1-2 years back. I couldn't find it, but http://gpshead.blogspot.com/2009/01/consumer-router-ipv6-firewall-fail.html says the same thing. I urge more people to look up what 6to4 relays you're using and set up your own if needed. People *are* using it and you not doing it is making things worse for your customers. Yes, 6to4 is generally bad but it's out there. Everybody needs to think about it. = John Jason Brzozowski Comcast Cable e) mailto:john_brzozow...@cable.comcast.com o) 609-377-6594 m) 484-962-0060 w) http://www.comcast6.net =
Re: Did your BGP crash today?
On Sun, Aug 29, 2010 at 12:30:21AM -0700, Paul Ferguson wrote: It would seem to me that there should actually be a better option, e.g. recognizing the malformed update, and simply discarding it (and sending the originator an error message) instead of resetting the session. Resetting of BGP sessions should only be done in the most dire of circumstances, to avoid a widespread instability incident. The only thing you know for sure when you receive a malformed update is that the router on the other end of the connection is broken (or that there's something in between the other router and you that is corrupting messages, but for the purposes of this, that's essentially the same thing). Accepting information received from a router known to be broken, and then passing that on to other routers, is a bad idea and something that could lead to a widespread instability incident. Of course, in theory, you discard the bad updates and only pass on the good updates, but doing that relies on the assumption that the known-to-be-broken router on the other end of the connection is broken in such a way that ensures that all the corrupted messages it sends will be recognizable as malformed and can be discarded. There's plenty of corruption that can't be detected on the receiving end. On top of that, there's problems with being out of sync with the router on the other end. For example, suppose a router developed a condition that caused it to malform all withdraw messages (or, more precisely, all UPDATE messages where the withdrarn routes length field is non-zero). If we implement what you suggest above, then we'll accept all the advertisements from that router, but ignore all the withdraws, and end up sending that router a bunch of traffic that it won't actually be able to handle. -- Brett
Re: Comcast enables 6to4 relays
John Jason Brzozowski john_brzozow...@cable.comcast.com writes: This does not alter our plans for our native dual stack trials, in fact, I hope to have more news on this front soon. comcast native dual stack is working fine at my house. traceroute6 -q1 mol.redbarn.org shows details.
Re: Comcast enables 6to4 relays
On 8/29/10 6:25 AM, John Jason Brzozowski wrote: Franck, As you know 6to4 is enabled by default in many cases and is used perhaps more than folks realize. Because of this and other observations we decided to deploy our own relays. Right prior to this the nearest 6to4 relay router from the vantage-point of comcast customers was at AMSIX. It's a given that you're going to have path asymmetry, in this case however it was frequently worse in one direction than in the other. This ought greatly improve the performance of existing devices located at comcast's customers. This does not alter our plans for our native dual stack trials, in fact, I hope to have more news on this front soon. It is true that 6to4 has challenges, some of these may be related to how 6to4 relays have been deployed. Others may be related to the protocol itself. Either way, by deploying our own we observed an improvement, we hope others have as well. John On 8/28/10 6:06 PM, Franck Martin fra...@genius.com wrote: These are good news. However, if Comcast provides native IPv6 to their customers, then the IPv6 native customers don't need these 6to4 relays? Airport Extreme, Linksys and other user equipment, enable IPv6 by doing 6to4 tunnels, so what this press release says, is that there are many users who are already on IPv6 via Comcast network but not native? Providing relays close to them, is a good transition move. Alternatively, the measurement of this 6to4 bandwidth on IPv4 may give you an idea of the demand for IPv6 from your customers? May be you detected a non null number here? I'm just trying to understand more IPv6 by the examples. I'm personally using 6to4 at home, and experiencing some MTU issues, which seems related to some PTB packets suppressed on the way between some end points, and that can depend on which 6to4 relay I'm using. Still trying to debug this (I'm not too fanatic about it, but work on it when I have a bit of time). I thought I would mention that. The WAND people have done some good studies: http://www.ripe.net/ripe/meetings/ripe-60/presentations/Stasiewicz-Measurement s_of_IPv6_Path_MTU_Discovery_Behaviour.pdf At the office, I have a more classical tunnel with he.net and do not have any issue there. - Original Message - From: John Jason Brzozowski john_brzozow...@cable.comcast.com To: NANOG nanog@nanog.org Sent: Sunday, 29 August, 2010 5:49:30 AM Subject: Comcast enables 6to4 relays FYI - thought this would be of interest to some of you, there will be more news on this front shortly. http://www.comcast6.net/ 6to4 Relays Activated Tuesday, August 17, 2010 As we started our IPv6 trials, we began to observe an increase in 6to4 relay traffic. 6to4 is a transition mechanism built into some operating systems and home gateways. While it is not a transition technology that Comcast planned to invest in due to limitations related to performance, we did observe poor performance when 6to4 was used by our customers. In many cases, these customers were not even aware that 6to4 was enabled by default or that their device or operating system was attempting to use 6to4 to communicate with IPv6 resources on the Internet. = John Jason Brzozowski Comcast Cable e) mailto:john_brzozow...@cable.comcast.com o) 609-377-6594 m) 484-962-0060 w) http://www.comcast6.net =
Re: Did your BGP crash today?
Richard A Steenbergen r...@e-gerbil.net writes: Just out of curiosity, at what point will we as operators rise up against the ivory tower protocol designers at the IETF and demand that they add a mechanism to not bring down the entire BGP session because of a single malformed attribute? Did I miss the memo about the meeting? I guess you did. http://tools.ietf.org/html/draft-ietf-idr-optional-transitive-02 Bjørn
Re: Did your BGP crash today?
On 8/29/10 3:23 AM, Mikael Abrahamsson wrote: On Sat, 28 Aug 2010, Brett Frankenberger wrote: The implementor is to blame becuase the code he wrote send out BGP messages which were not properly formed. People talk about not dropping sessions but instead dropping malformed messages. This is not safe. We've seen ISIS (which is TLV based and *can* drop individual messages) been wrongly implemented and platforms drop the entire ISIS *packet* instead of the individual message when seeing something malformed (or rather in this case, ISIS multi topology which the implementation didn't understand), and this made the link state database go out of sync and miss information for things it actually should have understood. Reminder: TCP itself has also been wrongly implemented with horrid consequences. Unknown TCP options are supposed to be silently discarded. Instead, some middlebox vendors simply copy them into the return packet. There are some circumstances where it makes sense to silently discard one TLV option, and others where it makes sense to discard the whole packet, and still others where it makes sense to drop the session. A problem is that many of the early designers (BGP is a fairly early design) used one-size-fits-all error handling. There's not much anybody can do about bad implementation (as in this case) that corrupts data. But a lot more thought needs to go into error recovery! This was *silent* error/corruption. I'm not sure I prefer to have silent problems instead of tearing down the session which is definitely noticable. Personally, I've usually advocated returning an error message. Many of the protocols I've developed use this approach. (Please forgive RADIUS, which for some odd reason is my most frequently cited work according to Google. My original draft had a Reject, subsequent WG activity took it away. All I could do is throw up my hands and walk away.)
Re: Did your BGP crash today?
On 8/29/10 9:31 AM, Bjørn Mork wrote: Richard A Steenbergen r...@e-gerbil.net writes: Just out of curiosity, at what point will we as operators rise up against the ivory tower protocol designers at the IETF and demand that they add a mechanism to not bring down the entire BGP session because of a single malformed attribute? Did I miss the memo about the meeting? I guess you did. http://tools.ietf.org/html/draft-ietf-idr-optional-transitive-02 rfc 4893 (4 octet as numbers) leverages the assumption that you can send the as4_path attribute and that even router's that don't understand it will forward it. given that 4 byte as numbers exist in the internet and many non-4byte aware routers exist, that seems like a reasonable assumption. Bjørn
Re: Did your BGP crash today?
On 8/27/10 1:07 PM, Mike Gatti wrote: where's the change management process in all of this. basically now we are going to starting changing things that can potentially have an adverse affect on users without letting anyone know before hand Interesting concept. BGP is transitive, change management is not. you have a change management process, your peer might integrate into that but have their own, your peer's peers almost certainly do not. Every time a wet-behind-the-ears network engineer connects a bgp speaker to the edge of the network it's an experiment in the the stability of the Internet. This on the fact of it seems like a quite reasonable experiment, which should have worked, except that it happened to tickle a bug... On Aug 27, 2010, at 3:33 PM, Dave Israel wrote: On 8/27/2010 3:22 PM, Jared Mauch wrote: When you are processing something, it's sometimes hard to tell if something just was mis-parsed (as I think the case is here with the missing-2-bytes) vs just getting garbage. Perhaps there should be some way to re-sync when you are having this problem, or a parallel keepalive path similar to MACA/MCAS/MIDCAS/TCAS between the devices to talk when something bad is happening. I know it wasn't there originally, and isn't mandatory now, but there is an MD5 hash that can be added to the packet. If the TCP hash checks out, then you know the packet wasn't garbled, and just contained information you didn't grok. That seems like enough evidence to be able to shrug and toss the packet without dropping the session. -Dave =+=+=+=+=+=+=+=+=+=+=+=+= Mike Gatti ekim.it...@gmail.com =+=+=+=+=+=+=+=+=+=+=+=+=
Re: Comcast enables 6to4 relays
Before we turned up our own relays the closest 6to4 relay was a single relay hosted by a mid-western university. Regardless where the next closest relays are located deploying our own resulted in improvements (as you pointed out below). John On 8/29/10 12:24 PM, Joel Jaeggli joe...@bogus.com wrote: On 8/29/10 6:25 AM, John Jason Brzozowski wrote: Franck, As you know 6to4 is enabled by default in many cases and is used perhaps more than folks realize. Because of this and other observations we decided to deploy our own relays. Right prior to this the nearest 6to4 relay router from the vantage-point of comcast customers was at AMSIX. It's a given that you're going to have path asymmetry, in this case however it was frequently worse in one direction than in the other. This ought greatly improve the performance of existing devices located at comcast's customers. This does not alter our plans for our native dual stack trials, in fact, I hope to have more news on this front soon. It is true that 6to4 has challenges, some of these may be related to how 6to4 relays have been deployed. Others may be related to the protocol itself. Either way, by deploying our own we observed an improvement, we hope others have as well. John On 8/28/10 6:06 PM, Franck Martin fra...@genius.com wrote: These are good news. However, if Comcast provides native IPv6 to their customers, then the IPv6 native customers don't need these 6to4 relays? Airport Extreme, Linksys and other user equipment, enable IPv6 by doing 6to4 tunnels, so what this press release says, is that there are many users who are already on IPv6 via Comcast network but not native? Providing relays close to them, is a good transition move. Alternatively, the measurement of this 6to4 bandwidth on IPv4 may give you an idea of the demand for IPv6 from your customers? May be you detected a non null number here? I'm just trying to understand more IPv6 by the examples. I'm personally using 6to4 at home, and experiencing some MTU issues, which seems related to some PTB packets suppressed on the way between some end points, and that can depend on which 6to4 relay I'm using. Still trying to debug this (I'm not too fanatic about it, but work on it when I have a bit of time). I thought I would mention that. The WAND people have done some good studies: http://www.ripe.net/ripe/meetings/ripe-60/presentations/Stasiewicz-Measureme nt s_of_IPv6_Path_MTU_Discovery_Behaviour.pdf At the office, I have a more classical tunnel with he.net and do not have any issue there. - Original Message - From: John Jason Brzozowski john_brzozow...@cable.comcast.com To: NANOG nanog@nanog.org Sent: Sunday, 29 August, 2010 5:49:30 AM Subject: Comcast enables 6to4 relays FYI - thought this would be of interest to some of you, there will be more news on this front shortly. http://www.comcast6.net/ 6to4 Relays Activated Tuesday, August 17, 2010 As we started our IPv6 trials, we began to observe an increase in 6to4 relay traffic. 6to4 is a transition mechanism built into some operating systems and home gateways. While it is not a transition technology that Comcast planned to invest in due to limitations related to performance, we did observe poor performance when 6to4 was used by our customers. In many cases, these customers were not even aware that 6to4 was enabled by default or that their device or operating system was attempting to use 6to4 to communicate with IPv6 resources on the Internet. = John Jason Brzozowski Comcast Cable e) mailto:john_brzozow...@cable.comcast.com o) 609-377-6594 m) 484-962-0060 w) http://www.comcast6.net = = John Jason Brzozowski Comcast Cable e) mailto:john_brzozow...@cable.comcast.com o) 609-377-6594 m) 484-962-0060 w) http://www.comcast6.net =
Re: Did your BGP crash today?
It seems that creating a worst case BGP test suite for all kinds of nastiness (in light of the recent RIPE thing) might not be a bad idea - so that we can all test the implementation ourselves before we deploy new code. Normally those things are done by vendors - that what we pay them good money for software update and support. You need a fully mesh network of all the vendors as it would seems that you need to check the outgoing packet as well as making sure the router is as well not chocking on the packet. Definitively no rocket science, still quite some work for something which should not be the end-user's problem. Thomas
Re: Did your BGP crash today?
It would seem to me that there should actually be a better option, e.g. recognizing the malformed update, and simply discarding it (and sending the originator an error message) instead of resetting the session. Resetting of BGP sessions should only be done in the most dire of circumstances, to avoid a widespread instability incident. I had the same thought before giving up on it. Negotiating a new error message could be a per peer option. BGP has capabilities for this exact reason. However to make sense you would need to find a resynchronisation point to only exclude the one faulty message. Initially I thought that the last received KEEPALIVE (for the receiver of the error message) could do - but you find yourselves with races conditions - so perhaps two KEEPALIVE back ? Each TCP packet can contain multiple message, so the messages would have to be then split and ACK individually to find the faulty one and then ACK individually. EOR could be used for that purpose. Still it adds lots of complexity in the conversation - are we not going to introduce bug in that not much used and tested code path as well ? Unless you have a new ACK capability for each message - another idea but those are clearly a discussions for outside NANOG. Thomas
Re: Comcast enables 6to4 relays
As the 6to4 is an default option on Apple Airport Extreme to enable ipv6, I would have thought that Apple would have provided a few gateways? Same for Microsoft that has it in its OS? Reminds me of the ntp servers issue built in on some devices...
Re: Did your BGP crash today?
On Sun, Aug 29, 2010 at 3:12 PM, Thomas Mangin thomas.man...@exa-networks.co.uk wrote: However to make sense you would need to find a resynchronisation point to only exclude the one faulty message. Initially I thought that the last received KEEPALIVE (for the receiver of the error message) could do - but you find yourselves with races conditions - so perhaps two KEEPALIVE back ? Each TCP packet can contain multiple message, so the messages would have to be then split and ACK individually to find the faulty one and then ACK individually. EOR could be used for that purpose. Every BGP message header has a portion that starts with 16 all-bits-1 octets, for compatibility. This is distinctive enough an implementation can guess where the next message starts. However, suppose you have an attacker.. if for example, a BGP speaker passes on too short a length value for an attribute... and the attacker knows what length will be sent instead of the right one. Places an entry into the Data portion, that will appear to the other peer to be the rest of the malformed update, Result: the malformed update is received and appears to be perfectly valid. The next thing the attacker inserts into the data portion of the attribute is the 16 all-bits-1 octets, BGP header, update message, and their malicious update. This will appear properly formed, when the buggy BGP speaker sends it. As far as the buggy BGP speaker is concerned, it has propagated 1 route update. As far as the buggy BGP speaker's other peers are concerned, they have received 3 messages from the buggy speaker. * The update completed in the attribute data section. (This is malformed, but intentionally not detectable as malformed) * The maliciously injected route.(This isn't supposed to exist. The buggy speaker is unaware of its existence, there is a disagreement between peers about how the message is interpreted) * A malformed message that does not make any sense. If the injection were perfect, nothing would be detectable as malformed. But alas, the attacker does not know exactly what other attributes or prepending buggy router will add to the message before passing it on. They could work this out through trial and error, however, some admin will hopefully notice all the CEASEs, before the attacker achieved complete success. In this case, by the time the other speakers detect something as malformed, the two preceding updates are already in the table, and possibly even propagated further. A CEASE rolls this back, by rolling back the entire session. Peers could (perhaps) safely re-synchronize in this case is if there was an extension to partially roll back some of the updates in a session and request a portion of the messages to be resent. Or if an extension such as authentication is used to make it impossible to inject BGP messages within the value of an attribute. Through data quarantine:requiring all BGP speakers to disallow the all-bits-1 sequence in any attribute value. Or through peer-specific authentication mechanisms, or checksums and digital signature, in the message header portion of each BGP message. -- -J
Re: Did your BGP crash today?
Every BGP message header has a portion that starts with 16 all-bits-1 octets, for compatibility. This is distinctive enough an implementation can guess where the next message starts. i desperately feared reading this. i do not want to bet the internet on guessing where anythings starts. randy
[NANOG-announce] Reminder: NANOG Steering Committee nominations close soon
The deadline for nominations for the NANOG Steering Committee is tomorrow, at 11:59 PM EDT on Monday, August 30. If you are interested in running for an SC position, or know someone who might be a good candidate, please send the nomination to nominati...@nanog.org. More details are below. This is a very important time in the evolution of NANOG, and the SC members elected this fall will have a great opportunity to help represent the community and shape our future. For the SC, Steve Feldman Elections for three of the six elected positions on the NANOG Steering Committee will be held in October, 2010, for two-year terms ending in October, 2012. The current SC members whose terms are expiring are Patrick Gilmore, Joe Provo, and Robert Seastrom. Joe is finishing his second consecutive term, so per the charter, cannot be considered for reelection until October 2011. If you care about NANOG as a forum, and think you would like to take a turn at volunteering your time to help make it better, please consider either volunteering yourself or nominating someone else. For more information about the role of the Steering Committee, or to find out more about what's involved in being a Steering Committee member, please consult the NANOG charter or contact someone who is already serving and ask them directly. http://www.nanog.org/governance/charter/ http://www.nanog.org/governance/steering/steeringcommittee.php Per the charter, Steering Committee members must attend at least two of three NANOG meetings per year while in office. HOW TO NOMINATE SOMEONE You may nominate someone else, or yourself. There is no limit to the number of nominations that may be submitted by a single person. Individual nominees will be contacted directly to confirm that they are willing to accept the nomination, and so that they can supply a biography for the NANOG web page. To submit a nomination, send the nominee's full name and contact details to nominati...@nanog.org. The deadline for nominations is 11:59 PM EDT on Monday, August 30. The candidates will be given an opportunity to make brief comments and/or accept questions from the community at the NANOG 50 Community Meeting on Sunday, October 3. As a reminder, the full election timeline is: Aug. 2 - SC Nominations begin Aug. 24 - Potential charter amendments discussed in nanog-futures Aug. 24 - PC Nominations begin Aug. 30 - SC Candidate information posted/nominations close Sep. 13 - Call for Communications Committee nominations Sep. 21 - Ballot approved Oct. 3 - Voting opens at 12:00 EDT Oct. 4 - PC Candidate Information posted/nominations close Oct. 6 - Voting closes at 09:15 EDT, results announced before the close of NANOG 50. ___ NANOG-announce mailing list nanog-annou...@nanog.org https://mailman.nanog.org/mailman/listinfo/nanog-announce
