February 2005 - Test - lists.nanog.org

Vendor Vulnerability Release Problem
by Hannigan, Martin 01 Feb '05

01 Feb '05

I attended the ISP Security BoF this evening and listened to Juniper and Cisco defend their positions of determining who gets notifications first. Decent talk. Folks did defend the "you need to reach us" to get the patch method, but some of it was "me too" I'd like to suggest to the Program Committee that a talk related to just this be solicited at the next NANOG and include all of the vendors who want to participate. They did concur that the current system is broken. This is part of the reason I decided to post this. To let everyone know that this is a problem and the vendors agree. I *was disappointed in was the harsh criticism of DHS. The vendors called DHS and the Pentagon the biggest source of leaks related to 'their' security vulnerabilities. I don't know if that's true, but if they are, I hope they're leaking to the right people. Thanks to Juniper and Cisco for holding the talk. -M< -- Martin Hannigan (c) 617-388-2663 VeriSign, Inc. (w) 703-948-7018 Network Engineer IV Operations & Infrastructure hannigan(a)verisign.com

2 1

RE: Vendor Vulnerability Release Problem
by Hannigan, Martin 01 Feb '05

01 Feb '05

> -----Original Message----- > From: mathews(a)uhunix2.hawaii.edu [mailto:mathews@uhunix2.hawaii.edu]On > Behalf Of Robert Mathews > Sent: Tuesday, February 01, 2005 11:01 AM > To: Hannigan, Martin > Subject: Re: Vendor Vulnerability Release Problem > > > > > On Tue, 1 Feb 2005, Hannigan, Martin wrote: > > > Date: Tue, 01 Feb 2005 01:17:42 -0500 > > From: "Hannigan, Martin" <hannigan(a)verisign.com> > > To: "'nanog(a)merit.edu'" <nanog(a)merit.edu> > > Subject: Vendor Vulnerability Release Problem > > > > > > [ .... ] > > > > They did concur that the current system is broken. This is > part of the > > reason I decided to post this. To let everyone know that this is a > > problem and the vendors agree. > > > Martin: > > Thank you for posting this note, as the subject item is of immense > interest to me personally, and to many within US Government. > My question, > which I will pose to you shortly -- is a broader one; one > that goes beyond > the world of ISPs and NSPs to the vastness of the IT world. > Still, your > concerns are very much valid in such an area as well. > > Before I go forward, I would like to disclose that I do not > attend NANOG > meetings regularly. > > With regard to your post Martin, I would like to ask you -- > just how you > see it, when you say: that "they did concur that the current system is > broken." Studies done within Government indicate a LARGER > problem than > 'after-incident action' which directly points to vendor > acknowledgement > itself. I am not at liberty to provide further details to > the studies or > their details but, it suffices to say that vendor behavior > is seen as a > significant problem. So, what of Vendor Behaviour? There appeared to be a consensus that the current methodology is broken. The vendors stated this themselves. The two presenters would need to clarify that further. As far as vendor behavior is related, I can't comment on that. It was clear, at least to me, there is no transparent or uniform method of distributing serious vulnerabilities. At least that participants of NANOG are aware of. I will concur that the vendors may not currently have a way to proceed with these problems, but I don't know that the operator community, ground zero for these vulnerabilities, hasn't been consulted as a whole. ((archives)). > > I *was disappointed in was the harsh criticism of DHS. The > vendors called > > DHS and the Pentagon the biggest source of leaks related to > 'their' security > > vulnerabilities. I don't know if that's true, but if they > are, I hope > > they're leaking to the right people. > > > Since I was not there for the discussion, I could not > appropriately relate > to the exchange held but, I would just like to understand if > I may -- what > the perception by the many gathered of DHS and the Pentagon were > respectively. My interpretation of the event was that the speakers considered DHS and the Pentagon to share some level of responsibility as to why vendors can't detail serious vulnerabilities. The feedback seemed to deride the Pentagon more than DHS. I can't gauge what the participants felt. As a guess, I think it was believable in the way it was presented. The overall impression was that the relevant government agencies are not credible. (I disagree from my own experience). > If you feel that this matter would be of interest to the > NANOG community, > do feel free to re-post. Reposted whole. > > > > -M< > > Thank you for your time Martin.. > > > Best, > Robert. > ------- > > ************************************************************** > ************* > * Robert Mathews, MSc. - Mgmt. (Honors), Ad.PD. - Econ. (Honors) > * Chancellor's Professor of Science & > * Distinguished Senior Scholar on > * National Security Affairs & U.S Industrial Preparedness > * @ University of Hawai'i > * Telephone: 315.853.7853 (NY) / 703.655.7124 (VA/WDC) > * Telecopier: 808.933.3473 (HI) / 315.859.1998 (NY) > * E.mail: mathews(a)hawaii.edu >

1 0

long as path games?
by Jon Lewis 01 Feb '05

01 Feb '05

Someone at fido.net having some bgp config issues? Jan 30 18:34:51 EST: %BGP-6-ASPATH: Long AS path 6461 3356 6770 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 received from ... I got this today from 2 of 3 transit providers (6461 and 3356). ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________

7 9

Qwest outage in CA?
by Brandon Shiers 01 Feb '05

01 Feb '05

Is anybody noticing problems reaching the Qwest network? It appears to me that Qwest is having major issues right now, just wondering if anybody had more details than I've been able to get. Here's a traceroute (partial) with what I'm seeing. I see the same off both my upstream providers: 9 att-gw.sfo.qwest.net (192.205.32.82) 52.809 ms 48.510 ms 47.386 ms 10 svx-core-02.inet.qwest.net (205.171.214.137) 43.872 ms 48.237 ms 43.062 ms 11 svx-core-01.inet.qwest.net (205.171.214.141) 45.100 ms 41.555 ms 47.190 ms 12 svx-core-02.inet.qwest.net (205.171.214.142) 45.743 ms 43.708 ms 50.738 ms 13 svx-core-01.inet.qwest.net (205.171.214.141) 51.182 ms 49.088 ms 52.417 ms 14 svx-core-02.inet.qwest.net (205.171.214.142) 54.275 ms 55.287 ms 48.152 ms 15 svx-core-01.inet.qwest.net (205.171.214.141) 53.801 ms 57.715 ms 50.122 ms 16 svx-core-02.inet.qwest.net (205.171.214.142) 45.526 ms 45.324 ms 54.539 ms 17 svx-core-01.inet.qwest.net (205.171.214.141) 43.281 ms 45.338 ms 46.141 ms 18 svx-core-02.inet.qwest.net (205.171.214.142) 41.324 ms 50.589 ms 42.397 ms 19 svx-core-01.inet.qwest.net (205.171.214.141) 55.421 ms 55.115 ms 48.757 ms 20 svx-core-02.inet.qwest.net (205.171.214.142) 46.072 ms 53.476 ms 50.280 ms 21 svx-core-01.inet.qwest.net (205.171.214.141) 44.127 ms 51.838 ms 50.987 ms 22 svx-core-02.inet.qwest.net (205.171.214.142) 52.952 ms 52.369 ms 41.843 ms 23 svx-core-01.inet.qwest.net (205.171.214.141) 50.093 ms 54.280 ms 64.481 ms 24 svx-core-02.inet.qwest.net (205.171.214.142) 52.143 ms 48.565 ms 45.444 ms 25 svx-core-01.inet.qwest.net (205.171.214.141) 47.978 ms 51.010 ms 57.275 ms 26 svx-core-02.inet.qwest.net (205.171.214.142) 52.550 ms 48.590 ms 53.459 ms 27 svx-core-01.inet.qwest.net (205.171.214.141) 60.545 ms 49.940 ms 50.369 ms 28 svx-core-02.inet.qwest.net (205.171.214.142) 52.378 ms 50.665 ms 47.266 ms 29 svx-core-01.inet.qwest.net (205.171.214.141) 45.451 ms 55.091 ms 50.909 ms 30 svx-core-02.inet.qwest.net (205.171.214.142) 46.745 ms 40.908 ms 48.400 ms Thanks in advance, Brandon

3 2

long as path games - additional question
by Gniewomir Krol 01 Feb '05

01 Feb '05

hello there, perhaps it's trivial question ( if so, please give mi direction to some source of information); suppose i've received as-path which contains about 8 as-numbers, four of which are the same; what exactly this could mean? thanks in advance, best regards, gk

1 0

Rapidly-variable routing on the time scale of seconds to minutes?
by Charles Shen 01 Feb '05

01 Feb '05

We did a "traceroute" end-to-end routing measurement in 2004 and found about 5-10% of measuremnts exhibiting rapidly-variable routing on the time scale of a single traceroute (seconds to minutes). In other words, the packets belonging to a single traceroute took multiple paths. Vern Paxson mentioned in 1997 one mechanism that can lead to this "route fluttering" behavior as "route splitting", which is explicity allowed in RFC1812 - Requirements for IP version 4 Routers. Route change in such a short scale for packets in the same flow could be troublesome. But the occurrence of such behavior does not seem to have reduced over the past years at least from our measurements. Does anyone know how to explain this behavior? Thanks! An example traceroute record containing the fluttering is shown below (see the 5th hop) Fri Apr 09 09:35:35 2004 1 cisfhfb.fh-friedberg.de (212.201.24.1) 1.095 ms 0.402 ms 0.321 ms 2 ar-frankfurt2.g-win.dfn.de (188.1.42.9) 120.105 ms 198.766 ms 200.040 ms 3 cr-frankfurt1-ge5-0.g-win.dfn.de (188.1.80.1) 2.093 ms 2.142 ms 2.087 ms 4 so-6-0-0.ar2.FRA2.gblx.net (208.48.23.141) 2.461 ms 2.349 ms 2.333 ms 5 pos5-0-2488M.cr2.FRA2.gblx.net (67.17.65.53) 2.448 ms pos6-0-2488M.cr1.FRA2.gblx.net (67.17.65.77) 2.368 ms 2.281 ms 6 so3-0-0-2488M.ar2.FRA3.gblx.net (67.17.65.82) 2.676 ms 2.750 ms so2-0-0-2488M.ar2.FRA3.gblx.net (67.17.65.58) 2.569 ms 7 ge-7-2.Frankfurt1.Level3.net (195.122.136.245) 10.971 ms 10.967 ms 10.882 ms 8 ae-0-55.mp1.Frankfurt1.Level3.net (195.122.136.97) 11.488 ms 11.417 ms 11.353 ms 9 so-0-0-0.mp1.London2.Level3.net (212.187.128.61) 27.203 ms 27.042 ms 27.048 ms 10 so-1-0-0.bbr1.Washington1.Level3.net (212.187.128.138) 91.004 ms 91.006 ms 90.977 ms 11 ge-0-0-0.mpls1.Honolulu2.Level3.net (4.68.128.13) 212.254 ms 212.321 ms 212.351 ms 12 so-7-0.hsa1.Honolulu2.Level3.net (4.68.112.90) 212.407 ms 212.250 ms 212.365 ms 13 s1.lavanet.bbnplanet.net (4.24.134.18) 212.609 ms 212.372 ms 213.270 ms 14 malasada.lava.net (64.65.64.17) 212.260 ms 212.460 ms 212.226 ms Best regards, Charles

4 10

Google Is Now A Domain Registrar....
by Fergie (Paul Ferguson) 01 Feb '05

01 Feb '05

Interesting... FYI, - ferg http://news.netcraft.com/archives/2005/01/31/google_is_now_a_domain_registr… -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(a)netzero.net or fergdawg(a)sbcglobal.net

5 6