I am greatful to Geoff for his consistant ability to get me interested in
breaking things... so, for the assembled mutlitude, what would the impact
on various peers be if I was to change my orign AS (ok, so i'll have to
change the router code on my end to support this) from
4554
to
00004554
Any ideas on how IOS (various flavors) will deal w/ this? (yes, there is
some lab work to do first, but i don' think there is a comprehensive enough
lab to cover the full range of possibilities...)
On Mon, 24 Oct 2005 bmanning@vacation.karoshi.com wrote something
about "prepending 2 bytes of zeros....":
Hi,
I am greatful to Geoff for his consistant ability to get me interested in
breaking things... so, for the assembled mutlitude, what would the impact
on various peers be if I was to change my orign AS (ok, so i'll have to
change the router code on my end to support this) from
I'll assume you are talking about BGP.
4554
to
00004554
actually these are 4 bytes of leading zeros because you are in decimal
but it's ok;)
How would you change the code?
"My Autonomous System" is an 2 octet unsigned integer and leading
zeros are of no value. So the number above still is 4554.
In case you'd hardcode that as 0x0000 0x11ca you'd overflow and depending
on your coding you my either overwrite "Hold Time" or generate some kind of
invalid packet with bad BGP Identifier and bad overall length (considering
"Opt Parm Length") or overwrite some of your local memory...
Any ideas on how IOS (various flavors) will deal w/ this? (yes, there is
some lab work to do first, but i don' think there is a comprehensive enough
lab to cover the full range of possibilities...)
Depending on what checks the code runs you should run into an error
one way or the other and not get back a NOTIFICATION message - if you
hard code those 32bit given above then you might get sth like subcode
2, 4 or 6. It should be treated like any other (specially crafted)
invalid packet.
So lets say you are running a BGP version that supports 4-Byte AS code, and you local AS is 4554
When you open a session with your BGP peer (using in this case 4554 in the 2-byte My AS field of the OPEN packet) you will send a BGP capacility advertisement to your peer, indicating your willingness to exchange 4-Byte AS numbers with your peer.
At this stage IOS (various flavours) do not (to my limited knowledge) support this capability, so you will not get a positive response to your capability announcement, so you are now on a NEW / OLD transition boundary. Your BGP will now operate in this NEW / OLD transition mode. The behaviour now depends on whether you are an isolated 0:4554 island, or whether there are any 4-Byte AS's that directly peer with your AS.
In the former case you will strip off the leading zero 2-Byte fields from your BGP Updates when you pass them to your BGP peer
The the latter case the action will vary, depending on whether the 4-Byte AS's in the path are all zero-strippable or not. In the latter case the UPDATES will cause a NEW_AS_PATH attribute to be added to the UPDATES you generate. in the former case its zero stripping.