-------- Original Message -------- Subject: Re: Peering LSR Violation Date: Fri, 29 Jun 2001 11:07:58 -0700 From: Doug Junkins <junkins@orcasisland.verio.net> To: Rick Irving <rirving@onecall.net> CC: Dorian Kim <dorian@verio.net>, peering@verio.net, peering@onecall.net References: <AEEPICGDOHNHFODBPFCLOEHBCPAA.tfrancis@verio.net> <3B3B8688.9933F73@onecall.net> <20010628184256.D15999@blackrose.org> <3B3CC0E6.63BFBDB9@onecall.net> Rick, Please accept this as 30-days notice that Verio will turn down peering with OneCall unless LSR is permanently enabled on on the peering routers that border Verio. I'm sorry if your interpretation of the requirement in our peering policy is different than ours, but the following clause is clear: Verio reserves the right to not peer with anyone as Verio sees fit and to terminate any peering at any time with 30 days notice. Warm Regards, -Doug Junkins VP, IP Engineering Verio, Inc. On Fri, Jun 29, 2001 at 12:54:46PM -0500, Rick Irving wrote:
Dorian Kim wrote:
On Thu, Jun 28, 2001 at 02:33:28PM -0500, Rick Irving wrote:
Rather than tell me -your- conclusion, why don't you tell me what you are trying to achieve ?
LSR is an important tool for us, both for diagnostics and for verification of certain peer checks.
This is a generic smoke screen, I need specifics.
There aren't many things LSR provides that cannot be provided in another fashion, with cooperation.
And, FWIW, with less security risks.
www.onecall.net has interior -traceroute- pages to provide the probable services you are attempting to acquire. (See diagnostics)
"Verio requires that peers permit LSR, loose source routing, at least at the routers bordering the peering."
FWIW, we -do- permit LSR.... We turn -on- LSR by request.... then turn it -off- , when the diagnostic phase is complete. My NOC -is- staffed 24x7 to respond to such needs.
Otherwise, LSR is inherently too insecure to -leave- enabled, so we have to permit it on a case-by-case, instance by instance, basis.
This has also been an explicit part of our peering policy as long as Verio has had a peering policy.
Randy Bush also thought the best solution to bandwidth and routing was to buy MCI, UU, and SPRINT instead of peering, at one time.
You know, in -his- case he may have been right. ;)
(Just kidding, Randy... smile. :)
However, We all learn.
Like I said, perhaps you should tell me your goals, rather than your conclusion. I think we could plumb an appropriate solution.
BTW: In addition to the Record Route header options you appear to desire, I'll leave you with Cisco's enigmatic LSR definition:
================================================================================= Loose Source Routing Allows you to specify a list of nodes that must be traversed when going to the destination. =================================================================================
We are simply attempt to get you to turn on LSR at the border routers as you've agreed to when you agreed to our peering policy.
We will.
Please schedule a time, and limited duration, that a tech on my side can work with a tech on your side, so we can assist you in running your diagnostics.
Thanks in advance.
Regards,
-dorian
You are aware that Loose Source Routing is a security risk, correct ?
Or, are you simply trying to "record route", and can't get something back ... And your response is to "Inform me" of your policy?
Teri Francis wrote:
Onecall is currently in violation of Verio's peering agreement. Under the "Technical Policy" section of our peering agreement it states,
"Verio requires that peers permit LSR, loose source routing, at least at the routers bordering the peering."
Please enable LSR on the routers we are peering with.
Our peering policy has also been updated. Please acknowledge your receipt of this agreement and your compliance of the policy. Please also include the entire text of the agreement in your reply.
This notice will serve as a 30 day notice to depeer should we not receive a response from you.
Regards,
Verio Peering
----Verio Peering agreement-----
Technical : for all trouble and problems with established peers Problems noc@verio.net +1 888 598-3746 or +1 214 290-8545
Abuse/SPAM : SPAM and similar abuses abuse@verio.net
Security : for all other security-related issues security@verio.net
Peering : for negotiations of changes in peering points etc peering@verio.net do NOT send to this address for technical problems with existing circuits
---
AS : 2914 AS-macro : AS-VERIO Equinix-Ashburn : 206.223.115.12 r00.asbnva01 GigE MAE-East : 192.41.177.121 r00.mclnva01 Vienna FDDI [0] 192.41.177.196 r01.mclnva01 Vienna FDDI [0] 198.32.187.223 r00.mclnva01 VPI/VCI:0/323 aal5snap [1] CID: 0281b81b0052 MAE-West : 198.32.136.80 r00.snjsca01 San Jose FDDI [2] 198.32.136.126 r01.snjsca01 San Jose FDDI [2] 198.32.200.80 r00.snjsca01 VPI/VCI:0/107 aal5snap [1] CID: wz898473ip80 NASA-Ames : 198.32.136.89 r00.mtvwca02 Sunnyvale FDDI [2] PAIX : 198.32.176.14 r06.plalca01 GigE 198.32.176.47 r05.plalca01 GigE AADS : 206.220.243.34 r00.chcgil01 VPI/VCI:3/40 aal5snap LINX : 195.66.224.138 r00.londen02 100baseT [3] 195.66.224.139 r01.londen02 100baseT [3] Xchangepoint UK : 217.79.160.10 r00.londen02 GigE [3] 217.79.161.10 r01.londen02 GigE [3]
[0] - Due to the impending terminatation of FDDI services at MAE-East, Verio is not adding new peers to our FDDI connections.
[1] - Verio is only provisioning AAL5 best-effort PVCs via WorldCom's Peermaker for MAE-ATM. No guaranteed bandwidth PVCs will be accepted.
[2] - Please peer with MFS-West or Ames only in the same location. Do not use the overburdened inter-site links.
[3] - Verio is currently testing prefix filtering based on IRR entries on our LINX and Xchangepoint connections. You will need to provide Verio the name of your AS-set in the IRR that descibes the set of routes you will be announcing. Verio currently accepts the following route registries: RADB, RIPE, ALTDB, ARCSTAR and CW[4]. Peering filters will be updated each day automatically at 0100 UTC and loaded on the routers at 0400 UTC. Contact noc@verio.net for technical problems with prefix filters. These prefix filters do not replace or supercede our normal peering filters as described at:
"http://info.us.bb.verio.net/routing.html#PeerFilter".
[4] - Please note that due to problems mirroring RIPE 181 database, we are likely to phase out support for CW routing registry in the next few months unless CW upgrades their routing registry to be RPSL compliant and improves their reliability.
---
To initiate peering, you need to send email agreeing to the following:
General policy for public peering
The Verio backbone peers with other transit ISPs, and only at the global exchange points to which the Verio backbone is connected.
Verio does not peer with any ISP which is a Verio transit customer.
In the United States, peering must be at least on both coasts, or one coast and Europe, with the peer having sufficient connectivity between points to support closest exit routing.
In Europe, one peering is sufficient for now. Verio may choose to announce the same routes in Europe as the States, but Verio reserves the right to announce only that subset of our routes which are local. Of course, peer may choose to do either.
Peer agrees to peer locally with Verio at any non-US peering points at which both appear.
Peer is responsible for keeping Verio informed of their current contact information. Please send infomation and updates to: peering@verio.net noc@verio.net
Technical Policy:
Verio requires all BGP sessions have MD5 signature configured.
Verio requires that peers permit LSR, loose source routing, at least at the routers bordering the peering.
Verio requires that peers announce the same routing policy at all points where they peer with Verio.
Peers are encouraged to, have NOCs with email addresses, phone numbers, and 24x7 coverage.
Peers must agree to actively cooperate chasing security violations, denial of service attacks, and similar incidents.
Peers must agree to actively respond to all technical issues within 48 hours. Non-response may result in depeering and other attention-getting mechanisms.
Peers must not abuse the peering relationship by doing any of the following non exhaustive list: pointing default, resetting next hop, selling or giving next hop to others, etc.
Verio reserves the right to not peer with anyone as Verio sees fit and to terminate any peering at any time with 30 days notice.
Verio reserves the right to change this peering policy with 30 days notice.
01-JUN-2001
Whoops, bad CC... Please ignore! Rick Irving wrote:
-------- Original Message -------- Subject: Re: Peering LSR Violation Date: Fri, 29 Jun 2001 11:07:58 -0700 From: Doug Junkins <junkins@orcasisland.verio.net> To: Rick Irving <rirving@onecall.net> CC: Dorian Kim <dorian@verio.net>, peering@verio.net, peering@onecall.net References: <AEEPICGDOHNHFODBPFCLOEHBCPAA.tfrancis@verio.net> <3B3B8688.9933F73@onecall.net> <20010628184256.D15999@blackrose.org> <3B3CC0E6.63BFBDB9@onecall.net>
so what's your point, other than you seem to not be meeting their peering ts and cs? randy
... With yet another "update" to the DDos pages. http://grc.com/dos/intro.htm and I quote:
* ISP's are responsible for preventing the transportation of obviously-fraudulent and easily blocked Internet traffic.
Because the responsibility for a safe and secure Internet is just as distributed as the Internet's technology, we must work together to bring about the required changes.
Unfortunately, today we see only the operation of blind self-interest from Microsoft and the Internet's ISP's
As I seem to recall several members of this list offered him help (and were rebuffed) perhaps they would like to comment? He seems increasingly lost in a fantasy world where everyone is out to get him....
David Howe wrote:
... With yet another "update" to the DDos pages. http://grc.com/dos/intro.htm and I quote:
* ISP's are responsible for preventing the transportation of obviously-fraudulent and easily blocked Internet traffic.
Because the responsibility for a safe and secure Internet is just as distributed as the Internet's technology, we must work together to bring about the required changes.
Unfortunately, today we see only the operation of blind self-interest from Microsoft and the Internet's ISP's
As I seem to recall several members of this list offered him help (and were rebuffed) perhaps they would like to comment? He seems increasingly lost in a fantasy world where everyone is out to get him....
My feeling is that he's missing some clues regarding the necessary realities of the situation. Its not so much a matter of laziness, avarice, or incompetence as much as it is a matter of the internet working the way it is supposed to. There is no way an ISP could block all, or even most, of the fraudulent traffic that is traversing their networks without resorting to draconian tactics that would, possibly, drive them out of business. There are certain steps they can take (source address filtering) which they should be doing anyway but this network has been designed to be a leaky seive. I'm also sure that XP might increase the number of spoofed packets running through the network. If that spurs more ISPs to use source address filtering them thats a good thing. Even if they don't it is possible to track down where a spoofed IP is coming from - its more of a social engineering issue than a technical one.
On Mon, 2 Jul 2001, David Howe wrote:
... With yet another "update" to the DDos pages. http://grc.com/dos/intro.htm and I quote:
Yet more proof that Gibson wants nothing more than media attention. After the attacks that he first experienced, as I mentioned before here, we offered our assistance and cooperation in the termination of Dynamic DNS accounts for people who run these trojans and connect them to their IRC servers. To quote myself from my e-mail to Steve:
I'd be more than happy to terminate this account, and open a continuing dialog with you if you'd be interested in passing along information of other accounts under our service being used for these purposes. It may be a losing fight, but at least we can try.
His response to me began: "I hate to give you a canned reply Tim, but I really have no choice. Here's what I'm sending back to most people ..." And was followed with a canned response, which included: "Therefore, I am working hard to put this whole whacky adventure behind me and to get on with the work I already had planned. A large part of me would dearly love to be distracted, but I just can't let the happen." How does that add up with the fact that he continues updating his page? He continues lambasting ISPs which won't cooperate with him, but pays no heed to us, a service provider offering our help and partnership in the battle against these abusers. I just can't get my mind around this in any way but "Gibson is an attention-starved whacko who doesn't understand the first thing about what he's trying to talk about." I keep waiting for it to add up, and it fails to do so. Gibson just wants to flame everyone in sight, ignore the facts, because he knows it'll get him the attention he wants. Tim Wilde -- Tim Wilde twilde@dyndns.org Systems Administrator Dynamic DNS Network Services http://www.dyndns.org/
participants (5)
-
Chris Rapier -
David Howe -
Randy Bush -
Rick Irving -
Tim Wilde