RE: More on Vonage service disruptions...
On Wed, 2 Mar 2005 22:15:48 -0500 (EST), Greg Boehnlein wrote: So, set your Rate-Limiting of SIP traffic to 1 packet per second for the network that YOU control and then offer your VoIP subscribers a different QOS profile at a higher cost. Bingo, problem solved. The economy will work itself out. In fact this just happened to me here in Bangkok; I was doing some tests of streaming audio during which I was moved administratively from one ADSL domain to another. Streaming audio became unuseable with many packet discards apparently due to jitter running up to a second. (The utility at http://testyourvoip.com proved invaluable: it uses Java to install a simulated VoIP client and runs a broad suite of tests.) Behind-the-scenes discussions have revealed the provider's experience that a short time after it brought the service online, its bandwidth was overwhelmed by a small minority of users downloading videos etc. The solution was silently to throttle the throughput. (Same operator nightmare experienced at many institutions of higher education where the students use the ethernet jack in their dormrooms, intended for research purposes, to download sex videos.) Jeffrey Race -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.300 / Virus Database: 266.5.7 - Release Date: 3/1/2005
Re: Heads up: Long AS-sets announced in the next few days
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2005-03-03, at 10.27, Geoff Huston wrote: On 2005-03-02, at 19.38, James A. T. Rice wrote: This seems to suggest that you are just picking ASns at random to inject into the paths, and that you don't have a set of ASs which you have the assignees permission to use. Would't this then actually equate to resource hijacking along the lines of prefix hijacking? Who will be the first to hit the RIRs? Isn't this a case of illustrating how easy it is to tell lies in BGP today? I don't see what hitting the RIRs has do to with this. The problem appears to be more basic than that - its just too easy to tell lies in BGP and get the lies propagated globally. Well agreed. And that is an important point in itself. The reference to the RIRs was me trying to be ironic as when we have prefix hijacks that seems to be reported to the RIRs. - - kurtis - -BEGIN PGP SIGNATURE- Version: PGP 8.1 iQA/AwUBQibejKarNKXTPFCVEQKO6ACeIzkX5j04JA3RK3Y48fSsXM0DMLEAoM+k 6+j6phNoiKSg5Qai2CNSloLa =TWvV -END PGP SIGNATURE-
Re: More on Vonage service disruptions...
Vonage style VoIP is unflatteringly but accurately called parasitic, it sits on top of someone else's network connection without supporting that connection at all, competing with any other IP traffic on the connection, with traffic going back to a switch wherever the VoIP company is. One person's definition of parasitic is another person's definition of unbundled services. --Michael Dillon
RE: More on Vonage service disruptions...
If you do not own the end-to-end network infrastructure, there is no way to guarantee any preferential handling of any particular subset of traffic. There is a way to guarantee end-to-end QoS even if you don't own all networks along the way. That is for a 3rd party organization to impose a contractual requirement. Aside from the very common scenario where a large customer contracts with 2 ISPs, there are some 3rd parties which require such QoS in order to certify an ISP. In Europe, the automotive industry does this. Maybe the ANX does similar? Maybe one of the ANX certified service providers could do a talk about their experiences? If a group of ISP's want to create a trade association for end-to-end QoS guarantees, they are free to do this. Perhaps the shift to VoIP will even make this economically viable. In any case, this issue should make for an interesting panel discussion if NANOG does a VoIP track/theme. --Michael Dillon
Re: More on Vonage service disruptions...
To diverge from VoIP, an interesting situation will present itself in the future. Verizon is installing FTTH. Data offerings in their present service area are: 5, 15, and 30Mbps downstream. http://www22.verizon.com/fiosforhome/channels/fios/root/package.asp These speeds would support broadcast quality video delivery (even HD quality) if properly implemented. I was walking down Tottenham Court Road at the weekend looking in the shop windows. More than one of them had a 1 terabyte hard drive on display made by LaCie. Combine that with multiMbps FTTH and P2P networks and you have a lot of big pipes running flat out 24x7. Back when MP3 filesharing was all the rage it didn't take long for the market to saturate, i.e. people had so many MP3s on their hard drive that there was no need to keep collecting. Imagine what happens when the same effect hits the film/DVD industry. --Michael Dillon
Re: More on Vonage service disruptions...
* [EMAIL PROTECTED] [Wed 02 Mar 2005, 19:24 CET]: A question to ponder - what would happen to your network , from both a technical and financial perspective if all of your customers circuit switched voice traffic suddenly became ip? Jack all, as I expect the amount of Internet traffic to be quite a bit larger than voice. Especially for residential users. -- Niels. -- The idle mind is the devil's playground
scanner-dns
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi there, Just wondering if there is any way I could use a scanner (I have a home grown script for this) that would go thru the DNS registries from some public source, scan for keywords in the domain name. Anything that is available only to ISP's and perhaps we can dovetail onto that if we cough up some $. Any pointers will be appreciated. regards, /virendra -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCJzEJpbZvCIJx1bcRAoIRAKC0JxOAUVuD30jKzrbtElrqWCoYWwCfdXop b5J3TIDs4i2xILgtaYpApZI= =T5GG -END PGP SIGNATURE-
public accessible snmp devices?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi there, Just wondering if there are any pool of public accessible (read-only) snmp enabled devices that one can access for testing purposes (such as snmpwalk, polling devices via oid/mib, graphing chart..etc)? I'm looking for a pool of devices that I run my test on. Any pointers will be appreciated. regards, /virendra -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCJzLfpbZvCIJx1bcRAqLcAJ95PzxXE4v51JgzTpeqfuEDZG6ibgCaAg20 WJxjcsJYroHriTPr635QOBE= =SV3b -END PGP SIGNATURE-
Re: Heads up: Long AS-sets announced in the next few days
On 2 Mar 2005, at 22:30, David Schwartz wrote: Please just clarify the following point: do you intend to advertise paths containing AS numbers belonging to other entities on the public Internet without the permission of the owners of those AS numbers? You admit that you don't know what the consequences of this injection will be. Prepending announcements with remote AS numbers has been a well-known technique for preventing prefixes from propagating to particular ASes for a long time. The AS_PATH attribute is a loop detection mechanism, and a determinant in path selection. What other magic is there in it that requires such careful consideration? Why should anybody need to get permission from remote operators before deciding what attributes to include in their own advertisements? Do I need to get permission from Sprint before I include 1239:100 as a community-string attribute on my own advertisement, too? It seems to me that there are enough issues with this type of experimentation *with* the permission of the AS numbers you plan to use. But the ethical issues with using them without such permission seems to me to be insurmountable. The ethical issues seem to be non-existent, to my way of thinking, and hence trivial to surmount :-) Joe
Re: Heads up: Long AS-sets announced in the next few days
On Thu, 2005-03-03 at 20:27 +1100, Geoff Huston wrote: On 2005-03-02, at 19.38, James A. T. Rice wrote: This seems to suggest that you are just picking ASns at random to inject into the paths, and that you don't have a set of ASs which you have the assignees permission to use. Would't this then actually equate to resource hijacking along the lines of prefix hijacking? Who will be the first to hit the RIRs? Isn't this a case of illustrating how easy it is to tell lies in BGP today? I don't see what hitting the RIRs has do to with this. The problem appears to be more basic than that - its just too easy to tell lies in BGP and get the lies propagated globally. I am probably telling you what you already know, but for the ones who don't know it yet: Secure BGP (S-BGP): http://www.ir.bbn.com/projects/s-bgp/ http://www.nanog.org/mtg-0306/pdf/bellovinsbgp.pdf http://www.nwfusion.com/details/6484.html?def and of course the sister by amongst others Cisco: Secure Origin BGP (SO-BGP): http://bgp.potaroo.net/ietf/idref/ draft-ng-sobgp-bgp-extensions/ http://www.nwfusion.com/details/6485.html http://www.nanog.org/mtg-0306/pdf/alvaro.pdf etc... most people know how to google I guess ;) Aka BGP with certificates and other nice tricks. Greets, Jeroen signature.asc Description: This is a digitally signed message part
Re: Heads up: Long AS-sets announced in the next few days
On 2 Mar 2005, at 22:30, David Schwartz wrote: Please just clarify the following point: do you intend to advertise paths containing AS numbers belonging to other entities on the public Internet without the permission of the owners of those AS numbers? You admit that you don't know what the consequences of this injection will be. Prepending announcements with remote AS numbers has been a well-known technique for preventing prefixes from propagating to particular ASes for a long time. The AS_PATH attribute is a loop detection mechanism, and a determinant in path selection. What other magic is there in it that requires such careful consideration? Why should anybody need to get permission from remote operators before deciding what attributes to include in their own advertisements? Do I need to get permission from Sprint before I include 1239:100 as a community-string attribute on my own advertisement, too? It seems to me that there are enough issues with this type of experimentation *with* the permission of the AS numbers you plan to use. But the ethical issues with using them without such permission seems to me to be insurmountable. The ethical issues seem to be non-existent, to my way of thinking, and hence trivial to surmount :-) Joe It is my humble little opinion that if joe-public looked at AS paths, it may be somewhat of an ethical issue, as some companies wouldn't want to be associated with others. ( hey, it says right here that Sprint gets it connection from the isp down the street!) However, most who see the as paths have a clue, and are smart enough to know that anyone can prepend pretty much anything thing pretty much any way they want to, so it's really not an issue. Those that look at AS paths, and aren't cluefull enough to know the difference well does anyone really care what those people think anyway? ;-) -Jerry
Re: Heads up: Long AS-sets announced in the next few days
I am probably telling you what you already know, but for the ones who don't know it yet: Secure BGP (S-BGP): http://www.ir.bbn.com/projects/s-bgp/ http://www.nanog.org/mtg-0306/pdf/bellovinsbgp.pdf http://www.nwfusion.com/details/6484.html?def and of course the sister by amongst others Cisco: Secure Origin BGP (SO-BGP): http://bgp.potaroo.net/ietf/idref/ draft-ng-sobgp-bgp-extensions/ http://www.nwfusion.com/details/6485.html http://www.nanog.org/mtg-0306/pdf/alvaro.pdf etc... most people know how to google I guess ;) Aka BGP with certificates and other nice tricks. And, of course, the RPSEC working group draft that is supposed to target the BGP requirements for those proposed systems is... http://www.ietf.org/internet-drafts/draft-ietf-rpsec-bgpsecrec-01.txt The folks who worked on S-BGP and SO-BGP participated in it's creation (as well as several operators). Please note that there are more than just two proposed mechanisms for securing BGP. The two mentioned above are just the most popular grin.
Re: Heads up: Long AS-sets announced in the next few days
On Thu, 2005-03-03 at 13:51 -0500, Blaine Christian wrote: And, of course, the RPSEC working group draft that is supposed to target the BGP requirements for those proposed systems is... http://www.ietf.org/internet-drafts/draft-ietf-rpsec-bgpsecrec-01.txt The folks who worked on S-BGP and SO-BGP participated in it's creation (as well as several operators). Please note that there are more than just two proposed mechanisms for securing BGP. The two mentioned above are just the most popular grin. Thanks for the new reading material, I had not seen that one yet... *print* will be a nice read (hmmm, actually I should swear at you for even more reading material, for which I have no time, oh well :) Greets, Jeroen signature.asc Description: This is a digitally signed message part
Reminder: 2005 NANOG Program Survey
Just a reminder to fill out the NANOG program survey! The survey can be reached via the Community Survey link on http://www.nanog.org/surveys.html We need _your_ input to help improve the quality of NANOG meeting content. Steve
Re: More on Vonage service disruptions...
On Wed, Mar 02, 2005 at 09:46:05AM -0600, Church, Chuck wrote: Another thing for an ISP considering blocking VoIP is the fact that you're cutting off people's access to 911. That alone has got to have some tough legal ramifications. I can tell you that if my ISP started blocking my Vonage, my next cell phone call would be my attorney... Why? Do you have a binding legal agreement with your ISP that requires them to pass all traffic? Do you really think you can make a persuasive case that you have an implicit agreement to that effect? (Note that I am not expressing an opinion about whether you _should_ or _might like to_ have such an agreement, just my skepticism that you actually _do_ have such an agreement, and can enforce it) The 911 issue is a tremendous red herring. In fact, it's more of a red halibut, or perhaps a red whale. Vonage fought tooth-and-nail to *not* be considered a local exchange carrier precisely *so that* they could avoid the quality of service requirements associated with 911 service. One of their major arguments in that dispute was that they provided a service accessible by dialing 911 that was like real 911 service but that was not actually 911 service. As I and others noted at the time, that very much violates the principle of least surprise, and is quite possibly more dangerous than not providing any 911 service at all: in New York City, for example, the number to which Vonage sends 911 calls is not equipped to dispatch emergency services and often advises callers to hang up and dial 911: this _decreases_ public safety by causing people to waste time instead of dealing with emergencies in some constructive way. But Vonage persisted nonethess in insisting that they should not be held to real 911 service standards, and they prevailed, basically by convincing a compliant federal regulatory body with little or no understanding of the underlying technical and human-factors issues to force the state regulators to see it Vonage's way. To turn around now and use 911 reliability (of their service that is like 911 but not 911 and thus should not _have_ any reliability standards enforced upon it) as a reason why other carriers should be enjoined from filtering Vonage's packets is not just wrong, it's absurd. Of course, like much of Vonage's other rhetoric, it will probably be effective. Ultimately, Vonage will succeed in the marketplace and, in the process of controlling its own costs, manage to wipe away almost all of the traditional regime of regulation of service quality, telco accountability, etc. even in realms like contact to emergency service in which the public good is generally considered to in fact be well served by those regulations. We will have cheaper voice telephone service when all is said and done but will we, eventually, be forced to turn around, after Vonage uses cheaper costs from differential regulation to wipe out all the old wireline carriers, to painfully reinstate a large part of the old regulatory regime to ensure that telecom services that we believe essential to the public good are not (or do not remain) wiped out as well? Thor
RE: Heads up: Long AS-sets announced in the next few days
On 2 Mar 2005, at 22:30, David Schwartz wrote: Please just clarify the following point: do you intend to advertise paths containing AS numbers belonging to other entities on the public Internet without the permission of the owners of those AS numbers? You admit that you don't know what the consequences of this injection will be. Prepending announcements with remote AS numbers has been a well-known technique for preventing prefixes from propagating to particular ASes for a long time. And therefore such use would not be considered experimental. We are talking about experimenting with routes that falsely claim to have passed through another autonymous system. The AS_PATH attribute is a loop detection mechanism, and a determinant in path selection. What other magic is there in it that requires such careful consideration? Why should anybody need to get permission from remote operators before deciding what attributes to include in their own advertisements? Every piece of BGP documentation I have ever seen says that this attribute documents the ASes that the route has actually passed through. Do I need to get permission from Sprint before I include 1239:100 as a community-string attribute on my own advertisement, too? You certainly need their permission before you can advertise routes that falsely came to have passed through their network! And yes, I would argue that you do need permission to attach someone else's community string to your routes and that it would be considered at least terribly bad manners to use undocumented community strings from other people's ASes. (Documentation, of course, equates to permission.) It seems to me that there are enough issues with this type of experimentation *with* the permission of the AS numbers you plan to use. But the ethical issues with using them without such permission seems to me to be insurmountable. The ethical issues seem to be non-existent, to my way of thinking, and hence trivial to surmount :-) I'm curious where you would draw the line then. And I'm curious what you think is the point of registering AS numbers at all, if it's okay to use other people's without their permission. DS
Re: More on Vonage service disruptions...
On Wed, 2 Mar 2005 12:39:45 -0500 Thor Lancelot Simon [EMAIL PROTECTED] wrote: On Wed, Mar 02, 2005 at 09:46:05AM -0600, Church, Chuck wrote: Another thing for an ISP considering blocking VoIP is the fact that you're cutting off people's access to 911. That alone has got to have some tough legal ramifications. I can tell you that if my ISP started blocking my Vonage, my next cell phone call would be my attorney... Why? Do you have a binding legal agreement with your ISP that requires them to pass all traffic? Do you really think you can make a persuasive case that you have an implicit agreement to that effect? (Note that I am not expressing an opinion about whether you _should_ or _might like to_ have such an agreement, just my skepticism that you actually _do_ have such an agreement, and can enforce it) The 911 issue is a tremendous red herring. In fact, it's more of a red halibut, or perhaps a red whale. Vonage fought tooth-and-nail to *not* be considered a local exchange carrier precisely *so that* they could avoid the quality of service requirements associated with 911 service. One of their major arguments in that dispute was that they provided a service accessible by dialing 911 that was like real 911 service but that was not actually 911 service. The problem is that, as more people take up VOIP service, it cannot be long before some of those people start dropping wireline. Examples of possible places are apartment blocks, with DSL on the janitor's phone line, and each apartment having VOIP service off that DSL. When that happens, if VOIP access to 911/112 is still problematic, we can expect standards for it to be mandated by governments - and they WILL do it - there is nothing politicians hate more than an avoidable fatality where the blame can be attributed to their failure to act. Far better that we get this right in advance, so that nothing needs to be made mandatory anyway. Some of my responsibilities involve work protecting telecommunications for deaf people, where emergency calls may have to be made by means of text messages. Some very similar issues seem to be arising there! -- Richard Cox
Re: Heads up: Long AS-sets announced in the next few days
James A. T. Rice wrote: You appear to be trying to take advantage of a side effect of this behaviour, in order to see what other ASn transitive adjacancies are available that would not normally be used, by inserting the ASns of transit AS's that would normally be used, into the as path you are announcing. Yes, that's more or less what we are proposing. I'm sure this was never an intended use for BGP as paths No, obviously not. But many things in the protocols we use today are used in ways that the original authors didn't have in mind. Examples I can think of at the moment are IP-in-IP tunnels, TCP congestion control (bolted on to TCP long after it was first designed), NAT and private addresses, ..., but I'm sure there are many more. So I think a more relevant question than was this intended, rather is this useful? If so, does it break existing stuff? More to the point, you are breaking a very fundemenatal convention and expectation that if you see a given ASn in an as path, that route will have transited that given ASn. That is not true in all cases. RFC 1771, paragraph 5.1.6, says: A BGP speaker that receives a route with the ATOMIC_AGGREGATE attribute needs to be cognizant of the fact that the actual path to destinations, as specified in the NLRI of the route, while having the loop-free property, may traverse ASs that are not listed in the AS_PATH attribute. I think that most of the the AS-sets you see announced in the Internet today have this property, and ours are no different: the sequence before the AS-set shows which ASes the announcement has passed through, and the AS-set which ASes the announcement might have passed through. As such, inserting others ASns into an as path is about as helpful to debugging as policy routing all your ICMP traffic to a box running fakeroute! I don't understand why this should be the case. If you exclude the AS-set, then you get exactly the path that was followed by the announcement. How does that hamper debugging? Regards, Lorenzo
Re: More on Vonage service disruptions...
When that happens, if VOIP access to 911/112 is still problematic, we can expect standards for it to be mandated by governments - and they WILL do it - there is nothing politicians hate more than an avoidable fatality where the blame can be attributed to their failure to act. So what is legislation going to do short of banning VoIP applications that connect to the PSTN? So who's going to stand trial if fatalities occur because the 911 operator was unreachable? The ISP for having insufficient bandwidth, the janitor for sharing the DSL line, the phone owner for dropping legacy PSTN service...? Who would in their right mind rely on MSN Messenger for 911 access? Today residential VoIP service offered by Vonage or like companies is nothing more or less than your instant messenging gizmo. Perhaps it is more useful but by no means more reliable. Adi
Re: Heads up: Long AS-sets announced in the next few days
David Schwartz wrote:
Prepending announcements with remote AS numbers has been a well-known
technique for preventing prefixes from propagating to particular ASes
for a long time.
And therefore such use would not be considered experimental. We are
talking
about experimenting with routes that falsely claim to have passed through
another autonymous system.
They are experimental in that yes, we are experimenting with a new
technique for topology discovery which to our knowledge has not been
proposed before.
As regards falsely claim to have passed through an autonomous system,
that is not accurate:
1. RFC 1771, paragraph 5.1.6 says that in the presence of an
ATOMIC_AGGREGATE attribute, the actual path to destinations, [...] may
traverse ASs that are not listed in the AS_PATH attribute. So an
AS-path does not claim to contain all the ASes that the announcement has
passed through.
2. Given an AS-set such as {1,2}, if you concluded that the announcement
had passed through both AS1 and AS2, you would be wrong (most of the
time, at least). So an AS-path does not claim that all the ASes in the
path are ASes that the announcement has passed through.
So, given these considerations, is everyone announcing an AS-set
announcing routes that falsely claim to have passed through another
autonymous system?
Every piece of BGP documentation I have ever seen says that this
attribute
documents the ASes that the route has actually passed through.
I think the above paragraph of RFC 1771 disagrees with you.
Regards,
Lorenzo
Re: More on Vonage service disruptions...
* [EMAIL PROTECTED] (Thor Lancelot Simon) [Thu 03 Mar 2005, 23:01 CET]: On Wed, Mar 02, 2005 at 09:46:05AM -0600, Church, Chuck wrote: Another thing for an ISP considering blocking VoIP is the fact that you're cutting off people's access to 911. That alone has got to have some tough legal ramifications. I can tell you that if my ISP started blocking my Vonage, my next cell phone call would be my attorney... Why? Do you have a binding legal agreement with your ISP that requires them to pass all traffic? Do you really think you can make a persuasive case that you have an implicit agreement to that effect? Why, yes, an agreement for Internet access. The end-to-end principle is considered an integral part of the design (and power) of the Internet. Kindergarten ISPs exist but I do not buy from them. And the verbiage in the contract is that the ISP doesn't guarantee access but will do its best to provide and keep offering such. The 911 issue is a tremendous red herring. In fact, it's more of a red halibut, or perhaps a red whale. Vonage fought tooth-and-nail ... and then you spend two entire pages derailing the debate towards emergency services. Thanks! Any provider intentionally causing deterioration of network performance towards a competitor's service offering is engaging in anticompetitive behaviour. This may be merely bad or legally suicidal. -- Niels. -- The idle mind is the devil's playground
Re: Heads up: Long AS-sets announced in the next few days
* [EMAIL PROTECTED] (Lorenzo Colitti) [Fri 04 Mar 2005, 00:09 CET]: David Schwartz wrote: Every piece of BGP documentation I have ever seen says that this attribute documents the ASes that the route has actually passed through. I think the above paragraph of RFC 1771 disagrees with you. Please quote properly; the context was AS_path, not AS_set. David Schwartz was right on the mark here. You certainly need their permission before you can advertise routes that falsely came to have passed through their network! And yes, I would argue that you do need permission to attach someone else's community string to your routes and that it would be considered at least terribly bad manners to use undocumented community strings from other people's ASes. (Documentation, of course, equates to permission.) This latter half is nonsense. A community is a 32-bit number with no guarantee of uniqueness; it's up to some kind-hearted fellow network operators to act upon certain `magical' values (apart from well-known ones as no-announce and no-export, of course) that they may have described in an object's remarks in some IRR's database. ASNs are uniquely assigned to autonomous systems; preloading other AS_paths than your own in an advertisement should be frowned upon (just like adding fake Path: entries to your Usenet postings, or adding Received: headers to e-mail if the e-mail in question did not pass through those systems). -- Niels. -- The idle mind is the devil's playground
Re: More on Vonage service disruptions...
..and apparently this is happening more and more. There was actually a story in USA Today a couple of days ago where a family tried calling 911 on their VoIP service during a burglary only to be told by a recorded message that they must dial 911 from another phone... http://www.usatoday.com/tech/news/2005-02-28-voip-usat_x.htm This story accurately highlights some of the issues. - ferg -- Adi Linden [EMAIL PROTECTED] wrote: Who would in their right mind rely on MSN Messenger for 911 access? Today residential VoIP service offered by Vonage or like companies is nothing more or less than your instant messenging gizmo. Perhaps it is more useful but by no means more reliable. Adi -- Fergie, a.k.a. Paul Ferguson Engineering Architecture for the Internet [EMAIL PROTECTED] or [EMAIL PROTECTED]
RE: Heads up: Long AS-sets announced in the next few days
David Schwartz wrote:
Prepending announcements with remote AS numbers has been a well-known
technique for preventing prefixes from propagating to particular ASes
for a long time.
And therefore such use would not be considered
experimental. We are talking
about experimenting with routes that falsely claim to have
passed through
another autonymous system.
They are experimental in that yes, we are experimenting with a new
technique for topology discovery which to our knowledge has not been
proposed before.
So you do not know what affect your announcements will have.
As regards falsely claim to have passed through an autonomous system,
that is not accurate:
I stand by it.
1. RFC 1771, paragraph 5.1.6 says that in the presence of an
ATOMIC_AGGREGATE attribute, the actual path to destinations, [...] may
traverse ASs that are not listed in the AS_PATH attribute. So an
AS-path does not claim to contain all the ASes that the announcement has
passed through.
I never said anything about what the absence of an AS entry means, I
only
talked about what the presence of an AS entry meant.
2. Given an AS-set such as {1,2}, if you concluded that the announcement
had passed through both AS1 and AS2, you would be wrong (most of the
time, at least). So an AS-path does not claim that all the ASes in the
path are ASes that the announcement has passed through.
The issue is not what conclusions I draw from an AS-set but what the
rules
are for including an AS in an AS-set.
So, given these considerations, is everyone announcing an AS-set
announcing routes that falsely claim to have passed through another
autonymous system?
Yes. From RFC1771:
1 AS_SET: unordered set of ASs a route in the
UPDATE message has traversed
...
AS_PATH is a well-known mandatory attribute. This attribute
identifies the autonomous systems through which routing information
carried in this UPDATE message has passed. The components of this
list can be AS_SETs or AS_SEQUENCEs.
...
In fact, RFC1771 goes on to specifically state under what conditions an
AS
can be added to the set:
b) When a given BGP speaker advertises the route to a BGP speaker
located in a neighboring autonomous system, then the advertising
speaker shall update the AS_PATH attribute as follows:
1) if the first path segment of the AS_PATH is of type
AS_SEQUENCE, the local system shall prepend its own AS number
as the last element of the sequence (put it in the leftmost
position).
2) if the first path segment of the AS_PATH is of type AS_SET,
the local system shall prepend a new path segment of type
AS_SEQUENCE to the AS_PATH, including its own AS number in that
segment.
When a BGP speaker originates a route then:
a) the originating speaker shall include its own AS number in
the AS_PATH attribute of all UPDATE messages sent to BGP
speakers located in neighboring autonomous systems. (In this
case, the AS number of the originating speaker's autonomous
system will be the only entry in the AS_PATH attribute).
b) the originating speaker shall include an empty AS_PATH
attribute in all UPDATE messages sent to BGP speakers located
in its own autonomous system. (An empty AS_PATH attribute is
one whose length field contains the value zero).
So you are violating RFC1771, plain and simple. To then go and cite one
small section of RFC1771 in your defense is hypocritical.
Every piece of BGP documentation I have ever seen says that
this attribute
documents the ASes that the route has actually passed through.
I think the above paragraph of RFC 1771 disagrees with you.
Since you obviously feel totally free to violate RFC 1771, the one
paragraph that vaguely supports what you're doing really doesn't help you.
Especially since it says nothing about the *presence* of an AS set.
DS
Re: Heads up: Long AS-sets announced in the next few days
On Thu, Mar 03, 2005 at 02:28:43PM -0800, David Schwartz wrote: [ snip ] Every piece of BGP documentation I have ever seen says that this attribute documents the ASes that the route has actually passed through. Do I need to get permission from Sprint before I include 1239:100 as a community-string attribute on my own advertisement, too? You certainly need their permission before you can advertise routes that falsely came to have passed through their network! What kind of specific _technical_ issue do I create by prepending another ASN on AS_PATHs I advertise, without such owner's permission? that you do need permission to attach someone else's community string to your routes and that it would be considered at least terribly bad manners to use undocumented community strings from other people's ASes. (Documentation, of course, equates to permission.) Please, that's ridiculous. [ snip ] I'm curious where you would draw the line then. And I'm curious what you think is the point of registering AS numbers at all, if it's okay to use other people's without their permission. If you are concerned about accuracy of registration records, I would advise that you ensure that your origin AS (aka the last ASN showing up before 'i' on Cisco or 'I' on Juniper in show output) in the AS_PATH is accurate. I don't see any technical pitfalls to include someone else's ASN in the transit path to avoid that particular ASNs from seeing it, other than the fact that is generally a frowned-upon or tasteless act to do. -J
Re: Heads up: Long AS-sets announced in the next few days
On Mar 3, 2005, at 7:22 PM, James wrote: You certainly need their permission before you can advertise routes that falsely came to have passed through their network! What kind of specific _technical_ issue do I create by prepending another ASN on AS_PATHs I advertise, without such owner's permission? Oh, I don't know, increasing the size of an already bloated global routing table; possibly crashing routers which are already starving for FIB RAM? A certain level of stability is to be expected on the global routing table. Playing with it isn't a 'good thing'. Besides the fact that they are experimenting with the core of the Internet. What if their experiments had an unwanted effect? What is the global financial impact of backbone instability? That is an awful big grenade they are chucking about. I think it is irresponsible for someone, no matter how educated or well intentioned to throw experiments into the middle of the network. -Matt
Re: Heads up: Long AS-sets announced in the next few days
David Schwartz wrote: They are experimental in that yes, we are experimenting with a new technique for topology discovery which to our knowledge has not been proposed before. So you do not know what affect your announcements will have. We don't know the effectiveness of the technique. That depends on the topology of the Internet, where you run the announcements from, etc. etc. We do know the effect that the announcements will have on BGP routers, i.e., cause them to ignore the path if they are in the AS-set, and accept them otherwise (modulo policy, max aspath length, etc. etc., of course). So, given these considerations, is everyone announcing an AS-set announcing routes that falsely claim to have passed through another autonymous system? Yes. From RFC1771: Ok, so if everyone announcing an AS-set is announcing routes that falsely claim to have passed through another autonymous system, and you are saying this shouldn't be done, then why aren't you complaining with everyone who is announcing an AS-set? [Quote of section 5.1.2 almost in its entirety] So you are violating RFC1771, plain and simple. To then go and cite one small section of RFC1771 in your defense is hypocritical. You quote Section 5.1.2, but you don't mention that if you follow Section 5.1.2 to the letter there is no way that an AS-path may contain an AS-set. To summarize the whole of section 5.1.2, the various cases are: Propagating a route learned from an UPDATE message: a) To another router in same AS: don't modify AS-path b) To a neighboring AS: 1. Path starts with AS_SEQUENCE: prepend own ASn 2. Path starts with AS_SET: prepend new AS_SEQUENCE with own AS in it Originating a route: a) To neighboring AS: announce own ASn as only element in path b) To another router in same AS: announce empty AS-path If you follow this to the letter, you must rule out both prepending (In this case, the AS number of the originating speaker's autonomous system will be the only entry in the AS_PATH attribute) and any form of AS-set, since there is no way, following these rules, that an AS-set may enter the AS-path in the first place. If we are violating this section, then everyone else announcing an AS-set, and - at least the way I read it - anyone doing prepending, is doing so too. But nobody is suggesting that these things shouldn't be done. Regards, Lorenzo
Vonage: Telco agrees to stop blocking VoIP calls
CNET News.com is reporting that: A North Carolina telecommunications company accused of deliberately blocking Internet phone traffic has reached a deal with federal regulators to halt the controversial practice. http://news.com.com/Telco+agrees+to+stop+blocking+VoIP+calls/2100-7352_3-5598633.html?tag=nefd.top - ferg -- Fergie, a.k.a. Paul Ferguson Engineering Architecture for the Internet [EMAIL PROTECTED] or [EMAIL PROTECTED]
Re: Heads up: Long AS-sets announced in the next few days
Niels Bakker wrote: Every piece of BGP documentation I have ever seen says that this attribute documents the ASes that the route has actually passed through. I think the above paragraph of RFC 1771 disagrees with you. Please quote properly; the context was AS_path, not AS_set. David Schwartz was right on the mark here. As far as the RFC is concerned, the AS-set is part of the AS-path. See Section 4.3, which says the AS-path is a well-known mandatory attribute that is composed of a sequence of AS path segments. Each AS path segment is represented by a triple path segment type, path segment length, path segment value, where path segment type is 1 for AS_SEQUENCE and 2 for AS_SET. The RFC also says: An AS_SET implies that the destinations listed in the NLRI can be reached through paths that traverse at least some of the constituent autonomous systems. which is exactly what we are doing. Regards, Lorenzo
Re: Heads up: Long AS-sets announced in the next few days
On Thu, Mar 03, 2005 at 07:40:53PM -0500, Matthew Crocker wrote: [ snip ] Oh, I don't know, increasing the size of an already bloated global routing table; possibly crashing routers which are already starving for FIB RAM? Probably not FIB, may be the BGP RIB for the most people that may be affected. If it is FIB that we are concerned about, well.. its only two additional prefixes to be held. I think the top polluters on www.cidr-report.org are more so on the critical path than this experiment. A certain level of stability is to be expected on the global routing table. Playing with it isn't a 'good thing'. Besides the fact that they are experimenting with the core of the Internet. They are not playing with the core. The result of what they are doing is dependent on specific topology and level of direction they are throwing prefixes at. What if their experiments had an unwanted effect? What is the global financial impact of backbone instability? That is an awful big grenade they are chucking about. I think it is irresponsible for someone, no matter how educated or well intentioned to throw experiments into the middle of the network. While I will not dispute your statement, I believe that every ASN should be responsible of their own and should not trust the General Internet to not cause harm on their network. If your router is going to crash b/c of someone advertising an unusual AS_PATH, I don't view that differently from a box getting owned because it was running unpatched OS since 1999 without any firewall rules either. -J
Re: Heads up: Long AS-sets announced in the next few days
* [EMAIL PROTECTED] (Lorenzo Colitti) [Fri 04 Mar 2005, 02:09 CET]: As far as the RFC is concerned, the AS-set is part of the AS-path. See Section 4.3, which says the AS-path is a well-known mandatory attribute that is composed of a sequence of AS path segments. Each AS path segment is represented by a triple path segment type, path segment length, path segment value, where path segment type is 1 for AS_SEQUENCE and 2 for AS_SET. I stand corrected. The RFC also says: An AS_SET implies that the destinations listed in the NLRI can be reached through paths that traverse at least some of the constituent autonomous systems. which is exactly what we are doing. Which would be planning to advertise routes with attributes claiming a topology that does not conform to reality? -- Niels. -- The idle mind is the devil's playground
RE: Heads up: Long AS-sets announced in the next few days
The RFC also says: An AS_SET implies that the destinations listed in the NLRI can be reached through paths that traverse at least some of the constituent autonomous systems. which is exactly what we are doing. Yes, you can cite sections of the RFC that you don't violate. That doesn't change a single thing about the sections you *do* violate. Nobody is arguing that you violate every single paragraph of the RFC. DS
RE: Heads up: Long AS-sets announced in the next few days
So, given these considerations, is everyone announcing an AS-set announcing routes that falsely claim to have passed through another autonymous system? Yes. From RFC1771: Ok, so if everyone announcing an AS-set is announcing routes that falsely claim to have passed through another autonymous system, and you are saying this shouldn't be done, then why aren't you complaining with everyone who is announcing an AS-set? I never said that this shouldn't be done. I said it shouldn't be done without the consent of the owners of the ASes you wish to include. In addition, the things I don't complain about don't constitute a defense to the things I do complain about. [Quote of section 5.1.2 almost in its entirety] So you are violating RFC1771, plain and simple. To then go and cite one small section of RFC1771 in your defense is hypocritical. You quote Section 5.1.2, but you don't mention that if you follow Section 5.1.2 to the letter there is no way that an AS-path may contain an AS-set. To summarize the whole of section 5.1.2, the various cases are: Propagating a route learned from an UPDATE message: a) To another router in same AS: don't modify AS-path b) To a neighboring AS: 1. Path starts with AS_SEQUENCE: prepend own ASn 2. Path starts with AS_SET: prepend new AS_SEQUENCE with own AS in it Originating a route: a) To neighboring AS: announce own ASn as only element in path b) To another router in same AS: announce empty AS-path If you follow this to the letter, you must rule out both prepending (In this case, the AS number of the originating speaker's autonomous system will be the only entry in the AS_PATH attribute) and any form of AS-set, since there is no way, following these rules, that an AS-set may enter the AS-path in the first place. Section 9.2.4.2 documents how an AS-set can enter the AS-path as part of aggregating routes. As far as I can tell, the use of AS-sets is permitted only to aggregate routes. If we are violating this section, then everyone else announcing an AS-set, and - at least the way I read it - anyone doing prepending, is doing so too. But nobody is suggesting that these things shouldn't be done. Lovely straw man. I complained about the lack of *consent* and you talk about people prepending their *own* AS numbers? Are you suggesting they lack their own consent?! DS
RE: Heads up: Long AS-sets announced in the next few days
James [mailto:[EMAIL PROTECTED] wrote: They are not playing with the core. The result of what they are doing is dependent on specific topology and level of direction they are throwing prefixes at. While I will not dispute your statement, I believe that every ASN should be responsible of their own and should not trust the General Internet to not cause harm on their network. If your router is going to crash b/c of someone advertising an unusual AS_PATH, I don't view that differently from a box getting owned because it was running unpatched OS since 1999 without any firewall rules either. -J I think most of the concern comes from the fact that this experiment is being done on a network that many people rely upon for various reasons, and it's unknown side effects have are in the scope of global financial/communication/emergency crisises. It might not cause any harm, but I'd think you guys could have probably come up with a better test bed than using other people's equipment and networks without permission and risking unforseen disasters. Why wasn't this experiment tested in a lab environment? We don't test new pharmaceuticals directly on humans in the first round of testing, and after they've been proven safe on animals, the tests then go on to compensated volunteers Even if this type of experiment fell into compliance with the RFCs, it surely wasn't the intended use of AS-PATHS and should be considered experimental, and therefore tested in a lab setting. The risks imposed by using the global internet routing infrastructure as your testbed far outweigh any benefits your tool might realize. If this experiment that you're running causes downtime for someone elses systems, are you willing to pay for the damages? -Brian
Re: More on Vonage service disruptions...
There was actually a story in USA Today a couple of days ago where a family tried calling 911 on their VoIP service during a burglary only to be told by a recorded message that they must dial 911 from another phone... I was surprised to see on Packet8's web site that they now offer E911 in a lot of places. You have to have a local phone number and pay an extra $1.50/mo. They remind you that if your power goes out, your phone still won't work, but if you can call 911, it'll be a real 911 call. This still has little to do with port blocking, but a lot to do with the whole question of what level of service people are paying for vs. what level they think they are paying for. Regards, John Levine, [EMAIL PROTECTED], Primary Perpetrator of The Internet for Dummies, Information Superhighwayman wanna-be, http://www.johnlevine.com, Mayor I dropped the toothpaste, said Tom, crestfallenly.
Re: scanner-dns
Just wondering if there is any way I could use a scanner (I have a home grown script for this) that would go thru the DNS registries from some public source, scan for keywords in the domain name. If you just want the list of domain names and not the rest of the whois data, it's not hard to get access to the zone files for most gTLDs. I arranged to get com, org, net, edu, biz, and info. In each case you have to sign and fax back an agreement to the registry in which you promise not to do naughty things with the data. Regards, John Levine, [EMAIL PROTECTED], Primary Perpetrator of The Internet for Dummies, Information Superhighwayman wanna-be, http://www.johnlevine.com, Mayor I dropped the toothpaste, said Tom, crestfallenly.
Re: Heads up: Long AS-sets announced in the next few days
lorenzo, i think we're ratholing here. can you tell us in simple words o what you are trying to learn with your experiment and why it will help us understand or better manage our networks (thanks rodney) o why the way you are doing it is safe and will not affect the packets we're trying to move for our customers in negative ways thanks randy
RE: More on Vonage service disruptions...
Perhaps it varies by state, but I thought part of the E-911 service regulations was that if you were offering (charging) for it, you had to offer it as lifeline service which meant it had to survive power outage. *shrug* I guess the original regs weren't written with these things in mind! Scott -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Levine Sent: Thursday, March 03, 2005 9:17 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: More on Vonage service disruptions... There was actually a story in USA Today a couple of days ago where a family tried calling 911 on their VoIP service during a burglary only to be told by a recorded message that they must dial 911 from another phone... I was surprised to see on Packet8's web site that they now offer E911 in a lot of places. You have to have a local phone number and pay an extra $1.50/mo. They remind you that if your power goes out, your phone still won't work, but if you can call 911, it'll be a real 911 call. This still has little to do with port blocking, but a lot to do with the whole question of what level of service people are paying for vs. what level they think they are paying for. Regards, John Levine, [EMAIL PROTECTED], Primary Perpetrator of The Internet for Dummies, Information Superhighwayman wanna-be, http://www.johnlevine.com, Mayor I dropped the toothpaste, said Tom, crestfallenly.
Process and Procedure of a NOC
Hi I am in the process of preparing a process and procedure documents for a newly setup NOC. Could any one help me by sending sample process and procedure documents / or key domains I need to focus on Best regards, Anvaj
