- Test - lists.nanog.org

Re: Heads up: Long AS-sets announced in the next few days
by Lorenzo Colitti 03 Mar '05

03 Mar '05

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

1 0

Re: Heads up: Long AS-sets announced in the next few days
by Jeroen Massar 03 Mar '05

03 Mar '05

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

2 2

Announcing the 2005 NANOG Program Survey
by Steve Feldman 03 Mar '05

03 Mar '05

In light of the recent discussions about the future direction of NANOG, the program committee would like your input on the area we can affect the most: the content of NANOG meetings. We have created a short survey, and would like to invite all NANOG list subscribers to participate. We're interested in everyone's thoughts, including those of you who have never attended a meeting. The survey can be reached via the "Community Survey" link on http://www.nanog.org/surveys.html If you have any questions about the content of the servey, feel free contact me or the whole program committee (nanogpc(a)nanog.org) For any technical issues, contact me directly; I'm the one who threw this together, so any bugs are my fault. Thanks for your time, Steve (for the pc)

1 1

RE: More on Vonage service disruptions...
by kwallace＠pcconnection.com 03 Mar '05

03 Mar '05

Subject: Re: More on Vonage service disruptions... > Yeah, I forgot about the regulation thing. I suppose I'd give the ISP > a call first, but I'd expect it to be working within a few hours. But > now that cable modem providers themselves are providing VoIP/dialtone, > wouldn't those be regulated by the FCC? A few quick observations here (my own, personal opinion): To paraphrase an earlier comment " a 90K stream is not an issue" but what about 10,000's of them? In the circuit switched arena, the LEC's compensate each other for either originating (toll free) or terminating traffic (LD) in a regulated environment. Thus there is some business reason to build the network out to handle the level traffic. That is not the case here (with VoIP), as most ISP's are paying for transport, peering connections, backhaul circuits, internal network bandwidth, etc. The IP Phone providers may be paying THEIR ISP, but the $$'s don't nescessarily flow down to the ISP that the customer is connected to. That end user's ISP must now pay more for transit, plus beef up their internal network infrastructure to handle the additional traffic. That would result in having to raise rates, perhaps making the previously viable, dirt cheap, VoIP look like not so competitive a choice (vs. traditional dialtone) to the end user anymore. 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?

5 4

More on Vonage service disruptions...
by Fergie (Paul Ferguson) 03 Mar '05

03 Mar '05

advancedIPpipeline is running another article this morning in their series of articles covering the Vonage service disruptions that [allegedly] invlove an ISP "port blocking" SIP connectitity between Vonage's client equipment and Vonage's servers. While there is a bit more decriptive detail in this article involving the nature of the service interruptions, Vonage's CEO, Jeffrey Citron, is trying to make a [in my opinion] weak argument that this type of traffic blocking is akin to censorship. http://www.advancedippipeline.com/news/60404589 The silliness of the "censorship" argument aside, an interesting snippet within this article started me thinking abut the "slippery slope" which might ensue if any type of legislation is enacted which would attempt to prohibit an ISP from blocking traffic in an effort to keep it [unwanted traffic] from traversing their network: "'It'd be unfortunate to have to pass a law [against port blocking and other types of interference], but we may have to,' Citron said. Though he said he has previously testified against the need for port-blocking regulation, Citron may now change that tune, especially if more network operators start using port-blocking or other techniques to selectively control Internet traffic." It looks to me like this is going to open up a huge can of worms. On one hand, you have ISP's who own their own infrastructure and have every right to prohibit traffic from traversing their network which does not conform to their AUP, business practices, technical standards, etc., or provide revenue. By the same token, and specifically when it comes to things like VoIP, we have these issues involving PUC's, FCC regulations, "equal access" rights, etc. IANAL (or a policy wonk), and I hope I'm wrong, but it certainly looks like things could get pretty ugly. - ferg -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(a)netzero.net or fergdawg(a)sbcglobal.net

5 4

RE: More on Vonage service disruptions...
by Fergie (Paul Ferguson) 03 Mar '05

03 Mar '05

Ah, and therein lies the rub. Any sort of QoS frob that is implemented for VoIP (or any other traffic for that matter) _must_ be truly honored end-to-end, and at every intermediate hop in between, for it to be "guaranteed" -- otherwise when traffic that you may designate as "higher quality" is handed off to another administrative domain that does not honor your traffic classifications, all bets are off. 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. - ferg (who has been down this QoS road a few times before) -- Jeff Rosowski <rosowskij(a)ie.ymp.gov> wrote: > 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? Offer a "Quality of Service" product to enhance voice over IP services. -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(a)netzero.net or fergdawg(a)sbcglobal.net

4 3

RE: More on Vonage service disruptions...
by Church, Chuck 03 Mar '05

03 Mar '05

Yeah, I forgot about the regulation thing. I suppose I'd give the ISP a call first, but I'd expect it to be working within a few hours. But now that cable modem providers themselves are providing VoIP/dialtone, wouldn't those be regulated by the FCC? I know that my cable modem ISP (Charter) has been much more reliable the last few months, as they're doing a bunch of upgrades regarding redundancy. I believe this is to support their new VoIP service. But it still seems to me that blocking someone from making a 911 call would be a lawsuit waiting to happen. Chuck -----Original Message----- Even if the ISP in question is a LEC, normally the ISP side of the house is unregulated. The LEC providesthe circuit, and the ISP provides the bandwidth / services on that circuit. If you ISP decided to block VOIP, your cell phone call should be to their competition to order service from them, and vote with your dollars. Or at least to your ISP to call up and complain. Just my opinion, IANAL (I don't even play one on TV), etc... -Patrick -- Patrick Muldoon Network/Software Engineer INOC (http://www.inoc.net) PGPKEY (http://www.inoc.net/~doon) Key ID: 0x370D752C (A)bort, (R)etry, (P)retend this never happened?

3 2

Re: Heads up: Long AS-sets announced in the next few days
by Kurt Erik Lindqvist 03 Mar '05

03 Mar '05

-----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-----

1 0

Re: Localizing traffic using BGP
by Fergie (Paul Ferguson) 03 Mar '05

03 Mar '05

Well, the most specific prefix wins in the forwarding selection process, but I won't make any comments on "best current practice" since "best" is somewhat relative to the idea of max-aggregation ....but this reference might help: G. Huston Request for Comments: 3221 Commentary on Inter-Domain Routing in the Internet ftp://ftp.rfc-editor.org/in-notes/rfc3221.txt [snip] 5.4 Lack of Common Operational Practices There is considerable evidence of a lack of uniformity of operational practices within the inter-domain routing space. This includes the use and setting of prefix filters, the use and setting of route damping parameters and level of verification undertaken on BGP advertisements by both the advertiser and the recipient. There is some extent of 'noise' in the routing table where advertisements appear to be propagated well beyond their intended domain of applicability, and also where withdrawals and advertisements are not being adequately damped close to the origin of the route flap. This diversity of operating practices also extends to policies of accepting advertisements that are more specific advertisements of existing provider blocks. [snip] - ferg -- Ashe Canvar <acanvar(a)gmail.com> wrote: Hello all, BGP design question. My scenario is very much like an online gaming company with servers on multiple continents. Details : 1. I have datacenters/servers in many POPs globally. 2. I am a stub AS with multiple ISPs available at each POP. 3. I do not have the resources to buy dedicated fiber to link these POPs, so my backbone is essentially a bunch of VPN tunnels. 4. I own a /21. Of which I announce /24's. 5. I have a mechanism to allocate client sessions to any ONE of the POPs based on network performance (which is what I want to optimize). Questions : I presently announce different /24's out of different POPs to localize traffic. All these prefixes are announced from the same AS number. This obviously can't be best practice. Are there any published BCPs or RFCs tackling this issue ? Is it recommened that I get multiple AS numbers and announce symmetrically from each "smaller" AS ? Or should I announce inconsistently from different locations ? Thanks! -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(a)netzero.net or fergdawg(a)sbcglobal.net

1 0

Localizing traffic using BGP
by Ashe Canvar 03 Mar '05

03 Mar '05

Hello all, BGP design question. My scenario is very much like an online gaming company with servers on multiple continents. Details : 1. I have datacenters/servers in many POPs globally. 2. I am a stub AS with multiple ISPs available at each POP. 3. I do not have the resources to buy dedicated fiber to link these POPs, so my backbone is essentially a bunch of VPN tunnels. 4. I own a /21. Of which I announce /24's. 5. I have a mechanism to allocate client sessions to any ONE of the POPs based on network performance (which is what I want to optimize). Questions : I presently announce different /24's out of different POPs to localize traffic. All these prefixes are announced from the same AS number. This obviously can't be best practice. Are there any published BCPs or RFCs tackling this issue ? Is it recommened that I get multiple AS numbers and announce symmetrically from each "smaller" AS ? Or should I announce inconsistently from different locations ? Thanks!

1 0