From lorell at hathcock.org Sun Mar 1 10:32:42 2009 From: lorell at hathcock.org (Lorell Hathcock) Date: Sun, 1 Mar 2009 10:32:42 -0600 Subject: DPI or Flow Management In-Reply-To: References: <49A99EE3.3050801@ibctech.ca> Message-ID: <025501c99a8b$587cb7f0$097627d0$@org> Francois: Should your email have also included a French interpretation as well? Sincerely, Lorell Hathcock ----------------------------------------------------- Francois : Votre email devrait-il avoir ?galement inclus une interpr?tation fran?aise aussi bien ? Sinc?rement, Lorell Hathcock -----Original Message----- From: Francois Menard [mailto:francois at menards.ca] Sent: Saturday, February 28, 2009 3:51 PM To: nanog list Subject: DPI or Flow Management The Coalition of Internet Service Providers has filed a substantial contribution at the CRTC stating: 1) The CRTC should forbid DPI, as it cannot be proven to be 98.5% effective at trapping P2P, such as to guarantee congestion relief 2) The CRTC should allow for other forms of traffic management by ISPs, such as Flow Management http://www.crtc.gc.ca/public/partvii/2008/8646/c12_200815400/1029835.zip This is part of the public record at the following address: http://www.crtc.gc.ca/PartVII/eng/2008/8646/c12_200815400.htm The world will see Canada taking head-on the issue of addressing the legitimacy of DEEP PACKET INSPECTION as a mean of properly managing an incumbent's network behind the unbundling/peering interface. NANOG cannot pretend that this debate does not take place and remain silent on this. Best regards, F. -- Fran?ois D. M?nard francois at menards.ca From francois at menards.ca Sun Mar 1 11:14:20 2009 From: francois at menards.ca (Francois Menard) Date: Sun, 1 Mar 2009 12:14:20 -0500 Subject: DPI or Flow Management In-Reply-To: <025501c99a8b$587cb7f0$097627d0$@org> References: <49A99EE3.3050801@ibctech.ca> <025501c99a8b$587cb7f0$097627d0$@org> Message-ID: ---------- see the small change in the third sentence ---- apologies. If by french, you actually are wondering if the time could be afforded to translate all of the filing to french, and file in both languages, the answer is unfortunately no. However, I most certainly assist with any requested translation. My take on this is that there is no difference in a peering router ignoring DSCP bits, and queuing all of the traffic in the same lane, such as to disregard the intended prioritization between the peering parties AND FLOW management... DPI gear instead of ignoring DSCP bits, compute DSCP bits from the content of the packer (so-called application headers). I agree with various party submissions that the 5-layer Internet model does not provide for such a concept of headers, which DPI and ILECs and Incumbent Cable Operators, call application headers. I believe that anything traffic management, which purports to place its hook on application headers, is by definition, violating network neutrality. However, traffic management in the form of 'pacing packets' based on their inter-arrival behavior, multiplicity of sources and multiplicity of destinations, remains legit in my humble opinion. Just like ignoring DSCP bits at the peering interface is legit at this time. Its like the post office getting envolopes by the truckload, then opening each envelope, read the content, to decide when to send the opened letter for delivery, either by foot or car, claiming that such a decision process will prevent envelopes from flooding the post office, coming into the post office for delivery in the last mile. On the other hand, traffic management such as flow management, deal with stuff differently by ensuring that the envelopes do not get to the post office too fast, thus permitting the letters be dispatched always by car, except those envelopes which are arriving to the post office, exhibiting behaviour of P2P, which are then sent for delivery by foot. In this latter case, the envelopes are never opened. F. -- Fran?ois D. M?nard francois at menards.ca On 1-Mar-09, at 11:32 AM, Lorell Hathcock wrote: > Francois: > > Should your email have also included a French interpretation as well? > > Sincerely, > > Lorell Hathcock > ----------------------------------------------------- > Francois : > > Votre email devrait-il avoir ?galement inclus une interpr?tation > fran?aise > aussi bien ? > > Sinc?rement, > > Lorell Hathcock > > -----Original Message----- > From: Francois Menard [mailto:francois at menards.ca] > Sent: Saturday, February 28, 2009 3:51 PM > To: nanog list > Subject: DPI or Flow Management > > The Coalition of Internet Service Providers has filed a substantial > contribution at the CRTC stating: > > 1) The CRTC should forbid DPI, as it cannot be proven to be 98.5% > effective at trapping P2P, such as to guarantee congestion relief > > 2) The CRTC should allow for other forms of traffic management by > ISPs, such as Flow Management > > http://www.crtc.gc.ca/public/partvii/2008/8646/c12_200815400/1029835.zip > > This is part of the public record at the following address: > > http://www.crtc.gc.ca/PartVII/eng/2008/8646/c12_200815400.htm > > The world will see Canada taking head-on the issue of addressing the > legitimacy of DEEP PACKET INSPECTION as a mean of properly managing an > incumbent's network behind the unbundling/peering interface. > > NANOG cannot pretend that this debate does not take place and remain > silent on this. > > Best regards, > > F. > -- > Fran?ois D. M?nard > francois at menards.ca > > > > > > From francois at menards.ca Sun Mar 1 10:49:18 2009 From: francois at menards.ca (Francois Menard) Date: Sun, 1 Mar 2009 11:49:18 -0500 Subject: DPI or Flow Management In-Reply-To: <025501c99a8b$587cb7f0$097627d0$@org> References: <49A99EE3.3050801@ibctech.ca> <025501c99a8b$587cb7f0$097627d0$@org> Message-ID: If by french, you actually are wondering if the time could be afforded to translate all of the filing to french, and file in both languages, the answer is unfortunately no. However, I most certainly assist with any requested translation. My take on this is that there is no difference in a peering router ignoring DSCP bits, and queuing all of the traffic in the same lane, such as to disregard the intended prioritization between the peering parties. DPI gear instead of ignoring DSCP bits, compute DSCP bits from the content of the packer (so-called application headers). I agree with various party submissions that the 5-layer Internet model does not provide for such a concept of headers, which DPI and ILECs and Incumbent Cable Operators, call application headers. I believe that anything traffic management, which purports to place its hook on application headers, is by definition, violating network neutrality. However, traffic management in the form of 'pacing packets' based on their inter-arrival behavior, multiplicity of sources and multiplicity of destinations, remains legit in my humble opinion. Just like ignoring DSCP bits at the peering interface is legit at this time. Its like the post office getting envolopes by the truckload, then opening each envelope, read the content, to decide when to send the opened letter for delivery, either by foot or car, claiming that such a decision process will prevent envelopes from flooding the post office, coming into the post office for delivery in the last mile. On the other hand, traffic management such as flow management, deal with stuff differently by ensuring that the envelopes do not get to the post office too fast, thus permitting the letters be dispatched always by car, except those envelopes which are arriving to the post office, exhibiting behaviour of P2P, which are then sent for delivery by foot. In this latter case, the envelopes are never opened. F. -- Fran?ois D. M?nard francois at menards.ca On 1-Mar-09, at 11:32 AM, Lorell Hathcock wrote: > Francois: > > Should your email have also included a French interpretation as well? > > Sincerely, > > Lorell Hathcock > ----------------------------------------------------- > Francois : > > Votre email devrait-il avoir ?galement inclus une interpr?tation > fran?aise > aussi bien ? > > Sinc?rement, > > Lorell Hathcock > > -----Original Message----- > From: Francois Menard [mailto:francois at menards.ca] > Sent: Saturday, February 28, 2009 3:51 PM > To: nanog list > Subject: DPI or Flow Management > > The Coalition of Internet Service Providers has filed a substantial > contribution at the CRTC stating: > > 1) The CRTC should forbid DPI, as it cannot be proven to be 98.5% > effective at trapping P2P, such as to guarantee congestion relief > > 2) The CRTC should allow for other forms of traffic management by > ISPs, such as Flow Management > > http://www.crtc.gc.ca/public/partvii/2008/8646/c12_200815400/1029835.zip > > This is part of the public record at the following address: > > http://www.crtc.gc.ca/PartVII/eng/2008/8646/c12_200815400.htm > > The world will see Canada taking head-on the issue of addressing the > legitimacy of DEEP PACKET INSPECTION as a mean of properly managing an > incumbent's network behind the unbundling/peering interface. > > NANOG cannot pretend that this debate does not take place and remain > silent on this. > > Best regards, > > F. > -- > Fran?ois D. M?nard > francois at menards.ca > > > > > > From hcb at netcases.net Sun Mar 1 11:52:05 2009 From: hcb at netcases.net (Howard C. Berkowitz) Date: Sun, 1 Mar 2009 12:52:05 -0500 Subject: DPI or Flow Management In-Reply-To: References: <49A99EE3.3050801@ibctech.ca><025501c99a8b$587cb7f0$097627d0$@org> Message-ID: <023b01c99a96$6f4cb600$020fa8c0@HDESK1> > -----Original Message----- > From: Francois Menard [mailto:francois at menards.ca] > Sent: Sunday, March 01, 2009 11:49 AM > To: Lorell Hathcock > Cc: 'nanog list' > Subject: Re: DPI or Flow Management > > Its like the post office getting envolopes by the truckload, then > opening each envelope, read the content, to decide when to send the > opened letter for delivery, either by foot or car, claiming that such > a decision process will prevent envelopes from flooding the post > office, coming into the post office for delivery in the last mile. > > On the other hand, traffic management such as flow management, deal > with stuff differently by ensuring that the envelopes do not get to > the post office too fast, thus permitting the letters be dispatched > always by car, except those envelopes which are arriving to the post > office, exhibiting behaviour of P2P, which are then sent for delivery > by foot. In this latter case, the envelopes are never opened. > There is, however, at least one more dimension with postal or package delivery services. They offer different delivery priorities with different pricing, may have surcharges or refuse large content that the physical transport technically could carry, and offer sender-pays and receiver-pays options. A few specialized cases do apply as well, such as some package delivery services accepting and handling hazardous materials only with declaration and surcharges. It seems that this discussion emphasizes technical capabilities, which certainly are relevant, but does not necessarily consider economic incentives or disincentives. We are probably in agreement that either DPI or traffic analysis could identify high-volume P2P; how does one deal with the customer assumption that they "should" be able to do whatever they like? Content distribution networks and caches do allow a much cleaner economic model, if not as convenient. From francois at menards.ca Sun Mar 1 12:31:01 2009 From: francois at menards.ca (Francois Menard) Date: Sun, 1 Mar 2009 13:31:01 -0500 Subject: DPI or Flow Management In-Reply-To: <023b01c99a96$6f4cb600$020fa8c0@HDESK1> References: <49A99EE3.3050801@ibctech.ca><025501c99a8b$587cb7f0$097627d0$@org> <023b01c99a96$6f4cb600$020fa8c0@HDESK1> Message-ID: <84CBDA27-5F68-4B70-BC8D-02074DDF08B7@menards.ca> >> Its like the post office getting envolopes by the truckload, then >> opening each envelope, read the content, to decide when to send the >> opened letter for delivery, either by foot or car, claiming that such >> a decision process will prevent envelopes from flooding the post >> office, coming into the post office for delivery in the last mile. >> >> > There is, however, at least one more dimension with postal or package > delivery services. They offer different delivery priorities with > different > pricing, may have surcharges or refuse large content that the physical > transport technically could carry, and offer sender-pays and > receiver-pays > options. > The starting hypothesis is based on envelopes of the same size, weight, colour, with no chemical powder in them, and all with the same stamp value... The emphasis, is the need to open the envelope to decide how to route them... F. From randy at psg.com Sun Mar 1 17:39:24 2009 From: randy at psg.com (Randy Bush) Date: Mon, 02 Mar 2009 08:39:24 +0900 Subject: DPI or Flow Management In-Reply-To: <84CBDA27-5F68-4B70-BC8D-02074DDF08B7@menards.ca> References: <49A99EE3.3050801@ibctech.ca> <025501c99a8b$587cb7f0$097627d0$@org> <023b01c99a96$6f4cb600$020fa8c0@HDESK1> <84CBDA27-5F68-4B70-BC8D-02074DDF08B7@menards.ca> Message-ID: > The emphasis, is the need to open the envelope to decide how to route > them... and more of my margin goes to the folk who make envelope openers. and this is a good thing? and it helps get the packets to the customer how? pfui! randy From smb at cs.columbia.edu Sun Mar 1 17:58:24 2009 From: smb at cs.columbia.edu (Steven M. Bellovin) Date: Sun, 1 Mar 2009 18:58:24 -0500 Subject: DPI or Flow Management In-Reply-To: References: <49A99EE3.3050801@ibctech.ca> <025501c99a8b$587cb7f0$097627d0$@org> <023b01c99a96$6f4cb600$020fa8c0@HDESK1> <84CBDA27-5F68-4B70-BC8D-02074DDF08B7@menards.ca> Message-ID: <20090301185824.63b74245@cs.columbia.edu> On Mon, 02 Mar 2009 08:39:24 +0900 Randy Bush wrote: > > The emphasis, is the need to open the envelope to decide how to > > route them... > > and more of my margin goes to the folk who make envelope openers. and > this is a good thing? and it helps get the packets to the customer > how? > > pfui! > Yah. I like what Mike O'Dell said at http://www.listbox.com/member/archive/247/2009/03/sort/time_rev/page/1/entry/3:12/ I admit to no debate on Deep Packet Inspection by ISPs, advertisers, or other assorted evesdroppers. It is very, very simple and as black-and-white as they come: It is WRONG and Deeply Evil. There is no righteous purpose, period. Full Stop. The fact that various government agencies are very good at it is irrelevant. "When the President does it, it's STILL Wrong." --Steve Bellovin, http://www.cs.columbia.edu/~smb From randy at psg.com Sun Mar 1 18:22:16 2009 From: randy at psg.com (Randy Bush) Date: Mon, 02 Mar 2009 09:22:16 +0900 Subject: DPI or Flow Management In-Reply-To: <20090301185824.63b74245@cs.columbia.edu> References: <49A99EE3.3050801@ibctech.ca> <025501c99a8b$587cb7f0$097627d0$@org> <023b01c99a96$6f4cb600$020fa8c0@HDESK1> <84CBDA27-5F68-4B70-BC8D-02074DDF08B7@menards.ca> <20090301185824.63b74245@cs.columbia.edu> Message-ID: > Yah. I like what Mike O'Dell said at > http://www.listbox.com/member/archive/247/2009/03/sort/time_rev/page/1/entry/3:12/ > I admit to no debate on Deep Packet Inspection by ISPs, > advertisers, or other assorted evesdroppers. > It is very, very simple and as black-and-white as they come: > It is WRONG and Deeply Evil. > There is no righteous purpose, period. Full Stop. > The fact that various government agencies are very good at it > is irrelevant. > "When the President does it, it's STILL Wrong." go mo! randy From rdobbins at cisco.com Sun Mar 1 19:10:25 2009 From: rdobbins at cisco.com (Roland Dobbins) Date: Mon, 2 Mar 2009 09:10:25 +0800 Subject: DPI or Flow Management In-Reply-To: <20090301185824.63b74245@cs.columbia.edu> References: <49A99EE3.3050801@ibctech.ca> <025501c99a8b$587cb7f0$097627d0$@org> <023b01c99a96$6f4cb600$020fa8c0@HDESK1> <84CBDA27-5F68-4B70-BC8D-02074DDF08B7@menards.ca> <20090301185824.63b74245@cs.columbia.edu> Message-ID: <6EC25EF1-FC08-490D-BDCC-4699464AA82F@cisco.com> On Mar 2, 2009, at 7:58 AM, Steven M. Bellovin wrote: > There is no righteous purpose, period. Full Stop. With regards to DDoS mitigation, it's sometimes necessary to go above layers-3/-4 in the event of layer-7-targeted attacks. ----------------------------------------------------------------------- Roland Dobbins // +852.9133.2844 mobile Some things are just too precious to entrust to computers. -- Seth Hanford From rdobbins at cisco.com Sun Mar 1 19:17:47 2009 From: rdobbins at cisco.com (Roland Dobbins) Date: Mon, 2 Mar 2009 09:17:47 +0800 Subject: DPI or Flow Management In-Reply-To: <6EC25EF1-FC08-490D-BDCC-4699464AA82F@cisco.com> References: <49A99EE3.3050801@ibctech.ca> <025501c99a8b$587cb7f0$097627d0$@org> <023b01c99a96$6f4cb600$020fa8c0@HDESK1> <84CBDA27-5F68-4B70-BC8D-02074DDF08B7@menards.ca> <20090301185824.63b74245@cs.columbia.edu> <6EC25EF1-FC08-490D-BDCC-4699464AA82F@cisco.com> Message-ID: On Mar 2, 2009, at 9:10 AM, Roland Dobbins wrote: > With regards to DDoS mitigation, it's sometimes necessary to go > above layers-3/-4 in the event of layer-7-targeted attacks. In fact, it's sometimes important to have the ability to parse packet payloads and/or interact with traffic in some layer-3/layer-4 attacks, depending upon the type of traffic, source distribution, legitimate proxy intermediaries, spoofed vs. non-spoofed, and so forth. ----------------------------------------------------------------------- Roland Dobbins // +852.9133.2844 mobile Some things are just too precious to entrust to computers. -- Seth Hanford From simon at darkmere.gen.nz Sun Mar 1 19:26:06 2009 From: simon at darkmere.gen.nz (Simon Lyall) Date: Mon, 2 Mar 2009 14:26:06 +1300 (NZDT) Subject: ADMIN: was Re: DPI or Flow Management In-Reply-To: <6EC25EF1-FC08-490D-BDCC-4699464AA82F@cisco.com> References: <49A99EE3.3050801@ibctech.ca> <025501c99a8b$587cb7f0$097627d0$@org> <023b01c99a96$6f4cb600$020fa8c0@HDESK1> <84CBDA27-5F68-4B70-BC8D-02074DDF08B7@menards.ca> <20090301185824.63b74245@cs.columbia.edu> <6EC25EF1-FC08-490D-BDCC-4699464AA82F@cisco.com> Message-ID: A reminder that political threads are prohibited from the mailing list under the AUP. Participants in the "DPI or Flow Management" might wish to move their discussion to a more politically orientated forum such as the Network Neutrality Squad mailing list: http://www.nnsquad.org/ Simon Lyall (on behalf of) NANOG Mailing List Committee. -- Simon Lyall | Very Busy | Web: http://www.darkmere.gen.nz/ "To stay awake all night adds a day to your life" - Stilgar | eMT. From ops.lists at gmail.com Sun Mar 1 19:44:53 2009 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Mon, 2 Mar 2009 07:14:53 +0530 Subject: DPI or Flow Management In-Reply-To: References: <49A99EE3.3050801@ibctech.ca> <025501c99a8b$587cb7f0$097627d0$@org> <023b01c99a96$6f4cb600$020fa8c0@HDESK1> <84CBDA27-5F68-4B70-BC8D-02074DDF08B7@menards.ca> <20090301185824.63b74245@cs.columbia.edu> <6EC25EF1-FC08-490D-BDCC-4699464AA82F@cisco.com> Message-ID: In short, the entire DPI debate is starting to go on similar lines, and flogging similar horses, as the gun control debate Yes, dpi has great, useful applications (ddos mitigation and other security, for example). And it has bad / harmful applications (dictatorships doing dpi to catch political dissent). That says a lot more about inappropriate / appropriate use of dpi rather than dpi itself. Nothing at all in DPI that makes it wrong, deeply evil etc. -srs On Mon, Mar 2, 2009 at 6:47 AM, Roland Dobbins wrote: > > On Mar 2, 2009, at 9:10 AM, Roland Dobbins wrote: > >> With regards to DDoS mitigation, it's sometimes necessary to go above >> layers-3/-4 in the event of layer-7-targeted attacks. > > In fact, it's sometimes important to have the ability to parse packet > payloads and/or interact with traffic in some layer-3/layer-4 attacks, > depending upon the type of traffic, source distribution, legitimate proxy > intermediaries, spoofed vs. non-spoofed, and so forth. > > ----------------------------------------------------------------------- > Roland Dobbins // +852.9133.2844 mobile > > ?Some things are just too precious to entrust to computers. > > ? ? ? ? ? ? ? ? ? -- Seth Hanford > > > -- Suresh Ramasubramanian (ops.lists at gmail.com) From jbates at brightok.net Sun Mar 1 20:14:45 2009 From: jbates at brightok.net (Jack Bates) Date: Sun, 01 Mar 2009 20:14:45 -0600 Subject: DPI or Flow Management In-Reply-To: References: <49A99EE3.3050801@ibctech.ca> <025501c99a8b$587cb7f0$097627d0$@org> <023b01c99a96$6f4cb600$020fa8c0@HDESK1> <84CBDA27-5F68-4B70-BC8D-02074DDF08B7@menards.ca> <20090301185824.63b74245@cs.columbia.edu> <6EC25EF1-FC08-490D-BDCC-4699464AA82F@cisco.com> Message-ID: <49AB4115.9060303@brightok.net> Suresh Ramasubramanian wrote: > In short, the entire DPI debate is starting to go on similar lines, > and flogging similar horses, as the gun control debate > > Yes, dpi has great, useful applications (ddos mitigation and other > security, for example). And it has bad / harmful applications > (dictatorships doing dpi to catch political dissent). > > That says a lot more about inappropriate / appropriate use of dpi > rather than dpi itself. > > Nothing at all in DPI that makes it wrong, deeply evil etc. Which is why the political debates over it bother me. Declaring dpi as evil and regulating it could very well limit security of the future; not to mention the fact that DPI tends to be extremely vague in definition dependent upon its implementation. Jack From francois at menards.ca Sun Mar 1 21:29:49 2009 From: francois at menards.ca (Francois Menard) Date: Sun, 1 Mar 2009 22:29:49 -0500 Subject: DPI or Flow Management In-Reply-To: <49AB4115.9060303@brightok.net> References: <49A99EE3.3050801@ibctech.ca> <025501c99a8b$587cb7f0$097627d0$@org> <023b01c99a96$6f4cb600$020fa8c0@HDESK1> <84CBDA27-5F68-4B70-BC8D-02074DDF08B7@menards.ca> <20090301185824.63b74245@cs.columbia.edu> <6EC25EF1-FC08-490D-BDCC-4699464AA82F@cisco.com> <49AB4115.9060303@brightok.net> Message-ID: <6854EAC1-7A93-4B5B-B4F1-DC76FE9040FD@menards.ca> The issue is use of dpi to eliminate congestion stemming from p2p's natural unfairness behind the unbundling interface. F. Le 09-03-01 ? 21:14, Jack Bates a ?crit : > Suresh Ramasubramanian wrote: >> In short, the entire DPI debate is starting to go on similar lines, >> and flogging similar horses, as the gun control debate >> Yes, dpi has great, useful applications (ddos mitigation and other >> security, for example). And it has bad / harmful applications >> (dictatorships doing dpi to catch political dissent). >> That says a lot more about inappropriate / appropriate use of dpi >> rather than dpi itself. >> Nothing at all in DPI that makes it wrong, deeply evil etc. > > Which is why the political debates over it bother me. Declaring dpi > as evil and regulating it could very well limit security of the > future; not to mention the fact that DPI tends to be extremely vague > in definition dependent upon its implementation. > > Jack > From lou at metron.com Sun Mar 1 22:57:01 2009 From: lou at metron.com (Lou Katz) Date: Sun, 1 Mar 2009 20:57:01 -0800 Subject: Hostile probe recording Message-ID: <20090302045701.GA60995@metron.com> I happen to have some non-standard applications running on port 80 on one of my machines. From time to time I get log messages noting improper syntax (for my app) of the form: 'GET /roundcube/CHANGELOG HTTP/1.1' 200.19.191.98 'GET /mail/CHANGELOG HTTP/1.1' 200.19.191.98 'GET /webmail/CHANGELOG HTTP/1.1' 200.19.191.98 'GET /roundcubemail/CHANGELOG HTTP/1.1' 200.19.191.98 'GET /rcmail/CHANGELOG HTTP/1.1' 200.19.191.98 'GET //CHANGELOG HTTP/1.1' 200.19.191.98 'GET /rc/CHANGELOG HTTP/1.1' 200.19.191.98 'GET /email/CHANGELOG HTTP/1.1' 200.19.191.98 'GET /mail2/CHANGELOG HTTP/1.1' 200.19.191.98 'GET /Webmail/CHANGELOG HTTP/1.1' 200.19.191.98 'GET /components/com_roundcube/CHANGELOG HTTP/1.1' 200.19.191.98 'GET /squirrelmail/CHANGELOG HTTP/1.1' 200.19.191.98 'GET /vhcs2/tools/webmail/CHANGELOG HTTP/1.1' 200.19.191.98 'GET /round/CHANGELOG HTTP/1.1' 200.19.191.98 (200.19.191.98 is the IP address of the attacking machine, not me) Is this sort of information of use to anyone here? Is the above an old vulnerability - since I don't run whatever it is probing for, I have not paid much attention to these. -- -=[L]=- Organization: entropic From fergdawgster at gmail.com Sun Mar 1 23:16:22 2009 From: fergdawgster at gmail.com (Paul Ferguson) Date: Sun, 1 Mar 2009 21:16:22 -0800 Subject: Hostile probe recording In-Reply-To: <20090302045701.GA60995@metron.com> References: <20090302045701.GA60995@metron.com> Message-ID: <6cd462c00903012116y104bb9f9l9935150345609c10@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sun, Mar 1, 2009 at 8:57 PM, Lou Katz wrote: > I happen to have some non-standard applications running on port 80 > on one of my machines. From time to time I get log messages noting > improper syntax (for my app) of the form: > > 'GET /roundcube/CHANGELOG HTTP/1.1' 200.19.191.98 > 'GET /mail/CHANGELOG HTTP/1.1' 200.19.191.98 > 'GET /webmail/CHANGELOG HTTP/1.1' 200.19.191.98 > 'GET /roundcubemail/CHANGELOG HTTP/1.1' 200.19.191.98 > 'GET /rcmail/CHANGELOG HTTP/1.1' 200.19.191.98 > 'GET //CHANGELOG HTTP/1.1' 200.19.191.98 > 'GET /rc/CHANGELOG HTTP/1.1' 200.19.191.98 > 'GET /email/CHANGELOG HTTP/1.1' 200.19.191.98 > 'GET /mail2/CHANGELOG HTTP/1.1' 200.19.191.98 > 'GET /Webmail/CHANGELOG HTTP/1.1' 200.19.191.98 > 'GET /components/com_roundcube/CHANGELOG HTTP/1.1' 200.19.191.98 > 'GET /squirrelmail/CHANGELOG HTTP/1.1' 200.19.191.98 > 'GET /vhcs2/tools/webmail/CHANGELOG HTTP/1.1' 200.19.191.98 > 'GET /round/CHANGELOG HTTP/1.1' 200.19.191.98 > > (200.19.191.98 is the IP address of the attacking machine, not me) > > > Is this sort of information of use to anyone here? > Is the above an old vulnerability - since I don't run > whatever it is probing for, I have not paid much attention to these. > Interesting. It looks like someone probing for a RoundCube Webmail vulnerability: http://www.h-online.com/security/RoundCube-vulnerability-allows-injection-o f-arbitrary-scripting-code--/news/112330 The interesting thing about the source is that it appears to be originating from a Brazilian High Performce Computing Facility: AS | IP | AS Name 1916 | 200.19.191.98 | Rede Nacional de Ensino e Pesquisa 200.19.191.98 -PTR-> oros.cenapadne.br See also: http://cenapadne.br/ Maybe a compromised host? Who knows. - - ferg p.s. You can always toss these types of things over on the funsec mailing list: https://linuxbox.org/cgi-bin/mailman/listinfo/funsec There folks over on funsec which can handle reports of this nature, and actually engage the appropriate parties in Brazil... -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFJq2t6q1pz9mNUZTMRAiz8AKC0y2BY0w4IoMhKHuD4rWWKOmX7kwCeMSlw QSGG/DFWFq/CuV+XxW0Cpcw= =u0Ng -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/ From eric at nixwizard.net Sun Mar 1 23:17:39 2009 From: eric at nixwizard.net (Eric Gearhart) Date: Sun, 1 Mar 2009 22:17:39 -0700 Subject: Hostile probe recording In-Reply-To: <20090302045701.GA60995@metron.com> References: <20090302045701.GA60995@metron.com> Message-ID: <5792267e0903012117l640e4194ub19b431a98573e@mail.gmail.com> On Sun, Mar 1, 2009 at 9:57 PM, Lou Katz wrote: > I happen to have some non-standard applications running on port 80 > on one of my machines. From time to time I get log messages noting > improper syntax (for my app) of the form: > > 'GET /roundcube/CHANGELOG HTTP/1.1' ? ? ? ? ? ? ? ? ? ? 200.19.191.98 > 'GET /mail/CHANGELOG HTTP/1.1' ? ? ? ? ? ? ? ? ? ? ? ? ?200.19.191.98 > 'GET /webmail/CHANGELOG HTTP/1.1' ? ? ? ? ? ? ? ? ? ? ? 200.19.191.98 > 'GET /roundcubemail/CHANGELOG HTTP/1.1' ? ? ? ? ? ? ? ? 200.19.191.98 > 'GET /rcmail/CHANGELOG HTTP/1.1' ? ? ? ? ? ? ? ? ? ? ? ?200.19.191.98 > 'GET //CHANGELOG HTTP/1.1' ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?200.19.191.98 > 'GET /rc/CHANGELOG HTTP/1.1' ? ? ? ? ? ? ? ? ? ? ? ? ? ?200.19.191.98 > 'GET /email/CHANGELOG HTTP/1.1' ? ? ? ? ? ? ? ? ? ? ? ? 200.19.191.98 > 'GET /mail2/CHANGELOG HTTP/1.1' ? ? ? ? ? ? ? ? ? ? ? ? 200.19.191.98 > 'GET /Webmail/CHANGELOG HTTP/1.1' ? ? ? ? ? ? ? ? ? ? ? 200.19.191.98 > 'GET /components/com_roundcube/CHANGELOG HTTP/1.1' ? ? ?200.19.191.98 > 'GET /squirrelmail/CHANGELOG HTTP/1.1' ? ? ? ? ? ? ? ? ?200.19.191.98 > 'GET /vhcs2/tools/webmail/CHANGELOG HTTP/1.1' ? ? ? ? ? 200.19.191.98 > 'GET /round/CHANGELOG HTTP/1.1' ? ? ? ? ? ? ? ? ? ? ? ? 200.19.191.98 > > (200.19.191.98 is the IP address of the attacking machine, not me) > > > Is this sort of information of use to anyone here? > Is the above an old vulnerability - since I don't run > ?whatever it is probing for, I have not paid much attention to these. It looks like it's probing for various versions of web-based email apps... RoundCube and SquirrelMail are two that I recognize offhand -- Eric http://nixwizard.net From pstewart at nexicomgroup.net Sun Mar 1 23:48:41 2009 From: pstewart at nexicomgroup.net (Paul Stewart) Date: Mon, 2 Mar 2009 00:48:41 -0500 Subject: Hostile probe recording In-Reply-To: <5792267e0903012117l640e4194ub19b431a98573e@mail.gmail.com> References: <20090302045701.GA60995@metron.com> <5792267e0903012117l640e4194ub19b431a98573e@mail.gmail.com> Message-ID: <89D27DE3375BB6428DDCC2927489826A020F4566@nexus.nexicomgroup.net> Looks like a Nessus scan..... -----Original Message----- From: Eric Gearhart [mailto:eric at nixwizard.net] Sent: Monday, March 02, 2009 12:18 AM To: nanog at merit.edu Subject: Re: Hostile probe recording On Sun, Mar 1, 2009 at 9:57 PM, Lou Katz wrote: > I happen to have some non-standard applications running on port 80 > on one of my machines. From time to time I get log messages noting > improper syntax (for my app) of the form: > > 'GET /roundcube/CHANGELOG HTTP/1.1' ? ? ? ? ? ? ? ? ? ? 200.19.191.98 > 'GET /mail/CHANGELOG HTTP/1.1' ? ? ? ? ? ? ? ? ? ? ? ? ?200.19.191.98 > 'GET /webmail/CHANGELOG HTTP/1.1' ? ? ? ? ? ? ? ? ? ? ? 200.19.191.98 > 'GET /roundcubemail/CHANGELOG HTTP/1.1' ? ? ? ? ? ? ? ? 200.19.191.98 > 'GET /rcmail/CHANGELOG HTTP/1.1' ? ? ? ? ? ? ? ? ? ? ? ?200.19.191.98 > 'GET //CHANGELOG HTTP/1.1' ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?200.19.191.98 > 'GET /rc/CHANGELOG HTTP/1.1' ? ? ? ? ? ? ? ? ? ? ? ? ? ?200.19.191.98 > 'GET /email/CHANGELOG HTTP/1.1' ? ? ? ? ? ? ? ? ? ? ? ? 200.19.191.98 > 'GET /mail2/CHANGELOG HTTP/1.1' ? ? ? ? ? ? ? ? ? ? ? ? 200.19.191.98 > 'GET /Webmail/CHANGELOG HTTP/1.1' ? ? ? ? ? ? ? ? ? ? ? 200.19.191.98 > 'GET /components/com_roundcube/CHANGELOG HTTP/1.1' ? ? ?200.19.191.98 > 'GET /squirrelmail/CHANGELOG HTTP/1.1' ? ? ? ? ? ? ? ? ?200.19.191.98 > 'GET /vhcs2/tools/webmail/CHANGELOG HTTP/1.1' ? ? ? ? ? 200.19.191.98 > 'GET /round/CHANGELOG HTTP/1.1' ? ? ? ? ? ? ? ? ? ? ? ? 200.19.191.98 > > (200.19.191.98 is the IP address of the attacking machine, not me) > > > Is this sort of information of use to anyone here? > Is the above an old vulnerability - since I don't run > ?whatever it is probing for, I have not paid much attention to these. It looks like it's probing for various versions of web-based email apps... RoundCube and SquirrelMail are two that I recognize offhand -- Eric http://nixwizard.net ---------------------------------------------------------------------------- "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you." From wavetossed at googlemail.com Mon Mar 2 03:49:32 2009 From: wavetossed at googlemail.com (Michael Dillon) Date: Mon, 2 Mar 2009 09:49:32 +0000 Subject: Legislation and its effects in our world In-Reply-To: <2edfe3130902250706w2399947cie685c980bec3cd7b@mail.gmail.com> References: <2edfe3130902250706w2399947cie685c980bec3cd7b@mail.gmail.com> Message-ID: <877585b00903020149x44f97015t95794d42a7f4712d@mail.gmail.com> On 2/25/09, Jim Willis wrote: > After having a brief conversation with a friend of mine over the weekend > about this new proposed legislation I was horrified to find that I could not > dig anything up on it in NANOG. Surely this sort of short minded legislation > should have been a bit more thought through in its effects on those that > would have to implement these changes. The people on NANOG mostly deal with moving packets around the network. Log files are kept on servers, or on SAN farms, and the NANOG folks generally don't deal with that so the legislation will have little to no impact on them. Specifically, NANOGers probably won't have to implement this change. That task will fall to ISP management and to the people who run storage systems and SANs. From emanuel.petr at nic.cz Mon Mar 2 05:44:42 2009 From: emanuel.petr at nic.cz (Emanuel Petr) Date: Mon, 02 Mar 2009 12:44:42 +0100 Subject: 23456 without AS4_PATH? In-Reply-To: <20090228171529.GB6429@mx.ytti.net> References: <20090228132412.GA5615@mx.ytti.net> <20090228.145230.41657175.sthaug@nethelp.no> <49A96887.1000900@gmail.com> <20090228.180534.71106261.sthaug@nethelp.no> <20090228171529.GB6429@mx.ytti.net> Message-ID: <49ABC6AA.9080500@nic.cz> Saku Ytti wrote: > On (2009-02-28 18:05 +0100), sthaug at nethelp.no wrote: > >>> show route 195.128.231.0/24 detail >>> [..omitted..] >>> AS path: AS2 PA[5]: 39792 35320 AS_TRANS AS_TRANS 35748 >>> AS path: AS4 PA[4]: 35320 3.21 AS_TRANS 35748 >>> AS path: Merged[5]: 39792 35320 3.21 AS_TRANS 35748 I >>> [...omitted...] >> Agreed, that sounds wrong. However, that's not how the route appears >> from here: >> >> show route 195.128.231.0/24 detail | match "AS path: [0-9AM]" >> AS path: AS2 PA[5]: 3356 13249 6886 AS_TRANS 35748 >> AS path: AS4 PA[4]: 13249 6886 196629 35748 >> AS path: Merged[5]: 3356 13249 6886 196629 35748 I >> AS path: AS2 PA[6]: 1299 3356 13249 6886 AS_TRANS 35748 >> AS path: AS4 PA[4]: 13249 6886 196629 35748 >> AS path: Merged[6]: 1299 3356 13249 6886 196629 35748 I >> >> So in our case the AS4 path seems normal. > > Looks OK in cisco as-dot format too, so unlike first example, I think > this may be local problem. > > gw.ip.fi#show ip bgp 195.128.231.0/24 > BGP routing table entry for 195.128.231.0/24, version 29 > Paths: (1 available, best #1, table Default-IP-Routing-Table) > Multipath: eBGP > Not advertised to any peer > 3292 3356 13249 6886 3.21 35748, (received & used) > 62.237.167.25 from 62.237.167.25 (62.236.0.5) > Origin IGP, localpref 100, valid, external, best > Community: 3292:1101 3292:1901 > gw.ip.fi# > > We have same result, like the first example from Steinar Haug. > show route 195.128.231.0/24 detail | match "AS path" AS path: AS2 PA[6]: 15685 29208 35320 AS_TRANS AS_TRANS 35748 AS path: AS4 PA[4]: 35320 196629 AS_TRANS 35748 AS path: Merged[6]: 15685 29208 35320 196629 AS_TRANS 35748 I ... AS path: AS2 PA[7]: 9002 13249 13249 13249 6886 AS_TRANS 35748 AS path: AS4 PA[6]: 13249 13249 13249 6886 196629 35748 AS path: Merged[7]: 9002 13249 13249 13249 6886 196629 35748 I Note: If propagated via AS196629,AS35320,.... then the AS4_PATH contains AS_TRANS. Em. From ab at root.lu Mon Mar 2 08:09:34 2009 From: ab at root.lu (Andy BIERLAIR) Date: Mon, 2 Mar 2009 15:09:34 +0100 Subject: Looking Glass script Message-ID: <000301c99b40$83b2dfc0$8b189f40$@lu> I was wondering if somebody knows where to find a decent looking glass script (PHP or Perl) that is compatible with Cisco 6500 Routers and can parse the results (bgp, bgp summary, ping, traceroute) so that they can easily be integrated into good looking HTML tables. I know there are plenty of good scripts available, but they all generate raw output. Parsing this data is a lot of coding work and I was hoping that I did not have to reinvent the wheel. Thanks, Andy From azher at hep.caltech.edu Mon Mar 2 08:19:59 2009 From: azher at hep.caltech.edu (Azher Mughal) Date: Mon, 02 Mar 2009 06:19:59 -0800 Subject: Looking Glass script In-Reply-To: <000301c99b40$83b2dfc0$8b189f40$@lu> References: <000301c99b40$83b2dfc0$8b189f40$@lu> Message-ID: <49ABEB0F.5020909@hep.caltech.edu> Router Proxy from Indiana University: http://sourceforge.net/projects/routerproxy/ We are using it with Cisco and Force10. -Azher USLHCNet Andy BIERLAIR wrote: > I was wondering if somebody knows where to find a decent looking glass > script (PHP or Perl) that is compatible with Cisco 6500 Routers and can > parse the results (bgp, bgp summary, ping, traceroute) so that they can > easily be integrated into good looking HTML tables. > > I know there are plenty of good scripts available, but they all generate raw > output. Parsing this data is a lot of coding work and I was hoping that I > did not have to reinvent the wheel. > > Thanks, > > Andy > > > From bruce at yoafrica.com Mon Mar 2 08:22:30 2009 From: bruce at yoafrica.com (Bruce Grobler) Date: Mon, 2 Mar 2009 16:22:30 +0200 Subject: Looking Glass script In-Reply-To: <000301c99b40$83b2dfc0$8b189f40$@lu> References: <000301c99b40$83b2dfc0$8b189f40$@lu> Message-ID: <002101c99b42$5274c160$f75e4420$@com> Try rancid-lg (debian) else freebsd ports comes with it if i'm not mistaken, and a great one is iBGPlay nothing beats it but it doesn't have the granularity you are looking for. Regards, Bruce Grobler Yo!Africa - Network Engineer Landline: +263-4-701300, Cellphone: +263-91-2364532 Skype ID: bruce.grobler -----Original Message----- From: Andy BIERLAIR [mailto:ab at root.lu] Sent: Monday, March 02, 2009 4:10 PM To: nanog at nanog.org Subject: Looking Glass script I was wondering if somebody knows where to find a decent looking glass script (PHP or Perl) that is compatible with Cisco 6500 Routers and can parse the results (bgp, bgp summary, ping, traceroute) so that they can easily be integrated into good looking HTML tables. I know there are plenty of good scripts available, but they all generate raw output. Parsing this data is a lot of coding work and I was hoping that I did not have to reinvent the wheel. Thanks, Andy From ghankins at mindspring.com Mon Mar 2 12:46:04 2009 From: ghankins at mindspring.com (Greg Hankins) Date: Mon, 2 Mar 2009 13:46:04 -0500 Subject: 23456 without AS4_PATH? In-Reply-To: <49ABC6AA.9080500@nic.cz> References: <20090228132412.GA5615@mx.ytti.net> <20090228.145230.41657175.sthaug@nethelp.no> <49A96887.1000900@gmail.com> <20090228.180534.71106261.sthaug@nethelp.no> <20090228171529.GB6429@mx.ytti.net> <49ABC6AA.9080500@nic.cz> Message-ID: <20090302184604.GA8110@force10networks.com> These prefixes all appeared with this problem late last December: 91.207.218.0/23 35320 196629 23456 195.128.230.0/24 35320 196629 23456 35748 195.128.231.0/24 35320 196629 23456 35748 The ill side effects of the AS_CONFED_SEQUENCE in an AS4_PATH and analysis on what is going on were covered in excellent detail by Andy Davidson, Jonathan Oddy, and Rob Shakir: - NANOG thread: http://www.merit.edu/mail.archives/nanog/msg14345.html - NANOG45 presentation: http://www.nanog.org/meetings/nanog45/presentations/Monday/Davidson_asn4_breaks_light_N45.pdf - AS4 Wiki: http://as4.cluepon.net/index.php/Operational_Issues#AS_CONFED_SEQUENCE_in_AS4_PATH Numerous attempts to contact AS 35320's NOC and peering folks about the problem by several people have pretty much been ignored. 91.196.186.0/24 looks like it just showed up with a broken AS path in the past couple of days. We'll probably see it a lot more regular invalid uses of 23456 in the future... I mean, how often does someone leak a private ASN :-)? Perhaps it is a good idea for router and routing software vendors to add 23456 to "neighbor remove-private-as". Incidentally, while RFC 4893bis will include better error handling for 32-bit ASNs, a new I-D to suggest better error handling for all optional transitive attributes was just released yesterday (http://www.ietf.org/internet-drafts/draft-scudder-idr-optional-transitive-00.txt). Greg -- Greg Hankins +1 404 542 5530 From dougb at dougbarton.us Mon Mar 2 15:45:32 2009 From: dougb at dougbarton.us (Doug Barton) Date: Mon, 02 Mar 2009 13:45:32 -0800 Subject: Looking Glass script In-Reply-To: <002101c99b42$5274c160$f75e4420$@com> References: <000301c99b40$83b2dfc0$8b189f40$@lu> <002101c99b42$5274c160$f75e4420$@com> Message-ID: <49AC537C.5050800@dougbarton.us> Bruce Grobler wrote: > Try rancid-lg (debian) else freebsd ports comes with it if i'm not mistaken, $ cd /usr/ports && make search name=rancid Port: rancid-2.3.1_3 Path: /usr/ports/net-mgmt/rancid Port: rancid-devel-2.3.2a9 Path: /usr/ports/net-mgmt/rancid-devel hope this helps, Doug From oberman at es.net Mon Mar 2 19:31:19 2009 From: oberman at es.net (Kevin Oberman) Date: Mon, 02 Mar 2009 17:31:19 -0800 Subject: MAC address confusion In-Reply-To: Your message of "Sun, 01 Mar 2009 00:40:00 +0200." <20090228224000.GA9473@mx.ytti.net> Message-ID: <20090303013119.BD0BC1CC0B@ptavv.es.net> > Date: Sun, 1 Mar 2009 00:40:00 +0200 > From: Saku Ytti > > On (2009-02-28 22:38 +0100), JAKO Andras wrote: > > Hey, > > > > http://standards.ieee.org/regauth/oui/oui.txt > > > 02-07-01 (hex) RACAL-DATACOM > > > > After enabling DECnet routing, the interface MAC address turns to > > something like this: > > Hardware is BCM1250 Internal MAC, address is aa00.0400.0a04 (bia 000b.bffd.fc1a) > > AA-00-04 (hex) DIGITAL EQUIPMENT CORPORATION > > > in the list. I don't know what 02-07-01 is, but I guess that could be > > something similar: The OUI belongs to a company, but they don't use the > > addresses to burn them into interface cards. > > I guess you shouldn't be able to assign 02 (or AA) to a company for ethernet > number, much in the same way you shouldn't be able to assign RFC1918. > However you are right, it seems that these are unexplained exceptions to rules: > > http://www.iana.org/assignments/ethernet-numbers > 'some of the known addresses do not follow the scheme (e.g., AA0003; 02xxxx)' > > Would be interesting to see what are the historical reasons.Perhaps they simply > predate the scheme or some might not even co-exist in ethernet network to begin > with, in which case they might be better documented elsewhere. > In any case, to avoid collision with history, better start with 06 which > seems cruft free, instead of 02, when choosing local MAC address prefix. > > As a side note, the 40 prefix used as local MAC in IXP here, seems to be > just mistake in assuming ethernet follows tokenring in numbering scheme. OK. Time for a history lesson. In the olden days, Xerox, the company that made the first Ethernet and, in a consortium with Digital and Intel, developed the first public standard for Ethernet. (This was referred to as the Blue Book or the DIX Ethernet.) At the time, the Ethernet networking schemes all assumed that the MAC address would be changes to embed the network address. This would allow hosts to know the MAC address of any other system running the same protocol. XNS and DECnet both did this and registered the locally assigned prefix that they would be using. This seemed quite reasonable at the time. Several companies registered the OID they were going to use for their networking systems as well as the hardware ones. This assured that no two hosts would have locally assigned address. Then along came IP over Ethernet and ARP. IP won the protocol battle (pretty easily) and the concept of dong MAC to host mapping via a protocol like ARP or NDP became the norm. But the OIDs for several protocols were already in the registry when it was turned over to the IEEE after 802.3 was ratified. IEEE agreed to retain existing registrations and they have remained there. The scheme was actually not a bad one, just one that never really caught on for modern networking. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman at es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From shivlu.jain at gmail.com Tue Mar 3 00:11:39 2009 From: shivlu.jain at gmail.com (Shivlu Jain) Date: Tue, 3 Mar 2009 11:41:39 +0530 Subject: SB 12.2(31)13 IOS: Internet Vrf Not Working Message-ID: I have simulated the 3 scenario with SB13 ios and found a weird problem whenever the PE is using SB13 with default route towards the internet and customers are coming on to the same PE in that case customers were not able to access internet services. After chaging the ios to 12.4 15T1 it everything works fine. I posted the test results on my blog. Kindly let me know anyone faced the similar issue. http://shivlu.blogspot.com/2009/03/122-31-sb13-internet-vrf-issuecontinued.html -- Thanks & Regards shivlu jain http://shivlu.blogspot.com/ 09312010137 From saku+nanog at ytti.fi Tue Mar 3 00:42:16 2009 From: saku+nanog at ytti.fi (Saku Ytti) Date: Tue, 3 Mar 2009 08:42:16 +0200 Subject: MAC address confusion In-Reply-To: <20090303013119.BD0BC1CC0B@ptavv.es.net> References: <20090228224000.GA9473@mx.ytti.net> <20090303013119.BD0BC1CC0B@ptavv.es.net> Message-ID: <20090303064216.GA23825@mx.ytti.net> On (2009-03-02 17:31 -0800), Kevin Oberman wrote: > > > > http://standards.ieee.org/regauth/oui/oui.txt > > > > 02-07-01 (hex) RACAL-DATACOM > > Would be interesting to see what are the historical reasons.Perhaps they simply > > predate the scheme or some might not even co-exist in ethernet network to begin > > with, in which case they might be better documented elsewhere. > > IEEE after 802.3 was ratified. IEEE agreed to retain existing > registrations and they have remained there. So where does this leave the current local scape addresses being globally assigned? Is it possible that we will run into legit 02 MAC addresses in the wild? -- ++ytti From rdroms at cisco.com Tue Mar 3 05:10:09 2009 From: rdroms at cisco.com (Ralph Droms) Date: Tue, 3 Mar 2009 06:10:09 -0500 Subject: IPv6 confusion Message-ID: <0753A1DD-1C70-42CF-BB95-B573B8214A33@cisco.com> Thanks to all who responded with input about why DHCPv6 should have options for default routers and prefix information. We've published a draft defining these options, which will be discussed at the upcoming IETF meeting in San Francisco. A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Default Router and Prefix Advertisement Options for DHCPv6 Author(s) : R. Droms, T. Narten Filename : draft-droms-dhc-dhcpv6-default-router-00.txt Pages : 7 Date : 2009-03-02 In some IPv6 deployments, there is a requirement to communicate a list of default routers and advertised prefixes to a host through DHCP. This document defines DHCP options to carry that information. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-droms-dhc-dhcpv6-default-router-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ - Ralph From ddoiron at noc1.net Tue Mar 3 09:06:39 2009 From: ddoiron at noc1.net (Dustin Doiron) Date: Tue, 3 Mar 2009 10:06:39 -0500 Subject: GoDaddy Spam/Abuse Message-ID: <3cd595c70903030706o7dfb7c09h3660deadfcab281d@mail.gmail.com> Can a GoDaddy (domain) abuse admin contact me off list? Thanks, Dustin From cmadams at hiwaay.net Tue Mar 3 10:59:56 2009 From: cmadams at hiwaay.net (Chris Adams) Date: Tue, 3 Mar 2009 10:59:56 -0600 Subject: Yahoo postmaster? Message-ID: <20090303165956.GA1248920@hiwaay.net> Can a Yahoo postmaster ping me off list? I've got a couple of servers that appear to be mis-categorized. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From carlos at race.com Tue Mar 3 11:09:28 2009 From: carlos at race.com (Carlos Alcantar) Date: Tue, 3 Mar 2009 09:09:28 -0800 Subject: Yahoo postmaster? Message-ID: <859604546CD1FF488BDB6EA94C896AFB59305C@racexchange.race.local> take a look a couple days back entire thread on yahoo mail might give some good info. -carlos -----Original Message----- From: Chris Adams [mailto:cmadams at hiwaay.net] Sent: Tuesday, March 03, 2009 9:00 AM To: nanog at nanog.org Subject: Yahoo postmaster? Can a Yahoo postmaster ping me off list? I've got a couple of servers that appear to be mis-categorized. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From mpetach at netflight.com Tue Mar 3 12:19:32 2009 From: mpetach at netflight.com (Matthew Petach) Date: Tue, 3 Mar 2009 10:19:32 -0800 Subject: Yahoo postmaster? In-Reply-To: <20090303165956.GA1248920@hiwaay.net> References: <20090303165956.GA1248920@hiwaay.net> Message-ID: <63ac96a50903031019q60c15679y416a1a634d0b430b@mail.gmail.com> On 3/3/09, Chris Adams wrote: > Can a Yahoo postmaster ping me off list? I've got a couple of servers > that appear to be mis-categorized. > Contact information for the Yahoo postmasters is listed at http://postmaster.yahoo.com/ Matt > -- > Chris Adams > Systems and Network Administrator - HiWAAY Internet Services > I don't speak for anybody but myself - that's enough trouble. > > From rcorbin at traffiq.com Tue Mar 3 12:33:04 2009 From: rcorbin at traffiq.com (Ray Corbin) Date: Tue, 3 Mar 2009 12:33:04 -0600 Subject: DNS lookup errors for godaddy domains Message-ID: Hey, Anyone noticing any dns type issues with DNS hosted at godaddy? We have had about several dns errors with our domain. We have several alarms setup for our website and 5 times so far it has said the site is down with "DOWN (ERR: problem resolving the name ())" . I just did some nslookups on 2 of our set godaddy's servers: C:\Program Files\Windows Resource Kits\Tools>nslookup *** Can't find server name for address 192.168.109.20: Non-existent domain Default Server: devdc1.emg.dev Address: 192.168.102.11 > server 216.69.185.5 Default Server: ns09.domaincontrol.com Address: 216.69.185.5 > itx.traffiq.com Server: ns09.domaincontrol.com Address: 216.69.185.5 Name: itx.traffiq.com Address: 66.151.100.151 > server 208.109.255.5 Default Server: [208.109.255.5] Address: 208.109.255.5 > itx.traffiq.com Server: [208.109.255.5] Address: 208.109.255.5 *** [208.109.255.5] can't find itx.traffiq.com: Non-existent domain > ads.traffiq.com Server: [208.109.255.5] Address: 208.109.255.5 Name: ads.traffiq.com Address: 66.151.100.150 > www.traffiq.com Server: [208.109.255.5] Address: 208.109.255.5 *** [208.109.255.5] can't find www.traffiq.com: Non-existent domain > itx.traffiq.com Server: [208.109.255.5] Address: 208.109.255.5 *** [208.109.255.5] can't find itx.traffiq.com: Non-existent domain > server 216.69.185.5 Default Server: [216.69.185.5] Address: 216.69.185.5 > itx.traffiq.com Server: [216.69.185.5] Address: 216.69.185.5 Name: itx.traffiq.com Address: 66.151.100.151 > ads.traffiq.com Server: [216.69.185.5] Address: 216.69.185.5 Name: ads.traffiq.com Address: 66.151.100.150 > www.traffiq.com Server: [216.69.185.5] Address: 216.69.185.5 *** [216.69.185.5] can't find www.traffiq.com: Non-existent domain > It seems pretty inconsistent. Godaddy is looking into it now...just wondering if anyone else was noticing any issues. Thanks! -r From cmadams at hiwaay.net Tue Mar 3 12:45:22 2009 From: cmadams at hiwaay.net (Chris Adams) Date: Tue, 3 Mar 2009 12:45:22 -0600 Subject: Yahoo postmaster? In-Reply-To: <63ac96a50903031019q60c15679y416a1a634d0b430b@mail.gmail.com> References: <20090303165956.GA1248920@hiwaay.net> <63ac96a50903031019q60c15679y416a1a634d0b430b@mail.gmail.com> Message-ID: <20090303184522.GB1248920@hiwaay.net> Once upon a time, Matthew Petach said: > On 3/3/09, Chris Adams wrote: > > Can a Yahoo postmaster ping me off list? I've got a couple of servers > > that appear to be mis-categorized. > > Contact information for the Yahoo postmasters is listed at > http://postmaster.yahoo.com/ We've filled out multiple forms there with no response. That's why I asked here. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From dnightin at wellesley.edu Tue Mar 3 14:37:21 2009 From: dnightin at wellesley.edu (Don Nightingale) Date: Tue, 03 Mar 2009 15:37:21 -0500 Subject: GBLX I2 connection issues? Message-ID: <49AD9501.7010001@wellesley.edu> We're seeing packet loss getting to 208.39.178.0/23 over I2, anyone else seeing any issues? 1 * 207.210.142.2 212 msec 236 msec 2 ge5-3-0-1000M.ar1.SJC2.gblx.net (64.208.110.25) 4 msec 4 msec 4 msec 3 te9-3-10G.ar5.NYC1.gblx.net (67.16.131.109) 80 msec 208 msec 8 msec 4 * * * 5 * * * 6 * * * 7 * * * 8 -- Don Nightingale Systems and Networks Manager Wellesley College 781-283-3271 From surfer at mauigateway.com Tue Mar 3 14:43:51 2009 From: surfer at mauigateway.com (Scott Weeks) Date: Tue, 3 Mar 2009 12:43:51 -0800 Subject: GBLX I2 connection issues? Message-ID: <20090303124351.BD7C2FE0@resin14.mta.everyone.net> No. For example: /usr/local/bin/tcptraceroute 208.39.178.1 9 208.173.53.138 54.790 ms 55.312 ms 55.207 ms 10 pos-0-9-0-0-cr01.losangeles.ca.ibone.comcast.net (68.86.85.186) 57.883 ms 57.948 ms 57.676 ms 11 pos-0-14-0-0-cr01.dallas.tx.ibone.comcast.net (68.86.85.142) 93.850 ms 94.420 ms 93.846 ms 12 pos-0-14-0-0-cr01.atlanta.ga.ibone.comcast.net (68.86.85.154) 112.976 ms 113.173 ms 113.260 ms 13 pos-0-11-0-0-cr01.mclean.va.ibone.comcast.net (68.86.85.242) 129.032 ms 129.078 ms 128.753 ms 14 pos-0-0-0-0-pe01.ashburn.va.ibone.comcast.net (68.86.86.26) 129.215 ms 129.142 ms 129.110 ms 15 ccs-pe01.ashburn.va.ibone.comcast.net (68.86.92.198) 136.825 ms 136.564 ms 136.844 ms 16 ge-11-0-cr01.phl.comcastcommercial.net (208.39.157.41) 142.110 ms 142.837 ms 142.407 ms 17 ge-3-1-br01.phl.comcastcommercial.net (208.39.156.2) 141.837 ms 142.068 ms 142.010 ms 18 208.39.178.1 [closed] 145.743 ms 145.467 ms 145.180 ms --- dnightin at wellesley.edu wrote: From: Don Nightingale To: "nanog at nanog.org" Subject: GBLX I2 connection issues? Date: Tue, 03 Mar 2009 15:37:21 -0500 We're seeing packet loss getting to 208.39.178.0/23 over I2, anyone else seeing any issues? 1 * 207.210.142.2 212 msec 236 msec 2 ge5-3-0-1000M.ar1.SJC2.gblx.net (64.208.110.25) 4 msec 4 msec 4 msec 3 te9-3-10G.ar5.NYC1.gblx.net (67.16.131.109) 80 msec 208 msec 8 msec 4 * * * 5 * * * 6 * * * 7 * * * 8 -- Don Nightingale Systems and Networks Manager Wellesley College 781-283-3271 From oberman at es.net Tue Mar 3 15:50:33 2009 From: oberman at es.net (Kevin Oberman) Date: Tue, 03 Mar 2009 13:50:33 -0800 Subject: MAC address confusion In-Reply-To: Your message of "Tue, 03 Mar 2009 08:42:16 +0200." <20090303064216.GA23825@mx.ytti.net> Message-ID: <20090303215033.0D7F01CC0B@ptavv.es.net> > Date: Tue, 3 Mar 2009 08:42:16 +0200 > From: Saku Ytti > > On (2009-03-02 17:31 -0800), Kevin Oberman wrote: > > > > > > http://standards.ieee.org/regauth/oui/oui.txt > > > > > 02-07-01 (hex) RACAL-DATACOM > > > > Would be interesting to see what are the historical reasons.Perhaps they simply > > > predate the scheme or some might not even co-exist in ethernet network to begin > > > with, in which case they might be better documented elsewhere. > > > > IEEE after 802.3 was ratified. IEEE agreed to retain existing > > registrations and they have remained there. > > So where does this leave the current local scape addresses being globally > assigned? Is it possible that we will run into legit 02 MAC addresses > in the wild? Thee are properly "locally assigned",not "local scope" addresses, but the effect is the same. This is only a problem if you have multiple systems running DECnet (or some other protocol using this) with the same layer 3 address. That should never happen, so there should be no duplication. The only real issue I see is with IPv6 EUI-64 addresses and even in that case, there would have to be two systems getting their address space from the same router interface before there is a conflict. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman at es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From bpfankuch at cpgreeley.com Tue Mar 3 22:31:10 2009 From: bpfankuch at cpgreeley.com (Blake Pfankuch) Date: Tue, 3 Mar 2009 21:31:10 -0700 Subject: Cox Abuse Contact Message-ID: <01759D50DC387C45A018FE1817CE27D7540E0F48C0@CPExchange1.cpgreeley.com> Can someone from the Cox Cable Abuse department contact me off list in regards to an account in Rhode Island? Blake Pfankuch Network Engineer [cid:image001.gif at 01C99C47.5ECB1B70] -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 1642 bytes Desc: image001.gif URL: From saku+nanog at ytti.fi Wed Mar 4 02:48:48 2009 From: saku+nanog at ytti.fi (Saku Ytti) Date: Wed, 4 Mar 2009 10:48:48 +0200 Subject: MAC address confusion In-Reply-To: <20090303215033.0D7F01CC0B@ptavv.es.net> References: <20090303064216.GA23825@mx.ytti.net> <20090303215033.0D7F01CC0B@ptavv.es.net> Message-ID: <20090304084848.GB1749@mx.ytti.net> On (2009-03-03 13:50 -0800), Kevin Oberman wrote: > This is only a problem if you have multiple systems running DECnet (or > some other protocol using this) with the same layer 3 address. That > should never happen, so there should be no duplication. Why would they need to have same L3 address? The way I see it, only thing that matters is, if or not, the addresses might speak ethernetII. If your ethernetII switch sees your local 02 address and one of the addresses below and they collide, the switch will keep relearning the address behind two ports. Unless of course it is guaranteed, that none of these addresses will ever appear as BIA in ethernetII capable NIC. 02-07-01 (hex) RACAL-DATACOM 02-1C-7C (hex) PERQ SYSTEMS CORPORATION 02-60-86 (hex) LOGIC REPLACEMENT TECH. LTD. 02-60-8C (hex) 3COM CORPORATION 02-70-01 (hex) RACAL-DATACOM 02-70-B0 (hex) M/A-COM INC. COMPANIES 02-70-B3 (hex) DATA RECALL LTD 02-9D-8E (hex) CARDIAC RECORDERS INC. 02-AA-3C (hex) OLIVETTI TELECOMM SPA (OLTECO) 02-BB-01 (hex) OCTOTHORPE CORP. 02-C0-8C (hex) 3COM CORPORATION 02-CF-1C (hex) COMMUNICATION MACHINERY CORP. 02-E6-D3 (hex) NIXDORF COMPUTER CORPORATION -- ++ytti From sam_mailinglists at spacething.org Wed Mar 4 03:51:33 2009 From: sam_mailinglists at spacething.org (Sam Stickland) Date: Wed, 04 Mar 2009 09:51:33 +0000 Subject: SNMP and syslog forwarders Message-ID: <49AE4F25.3010007@spacething.org> Hi, It's looking like running all of our traps and syslog through a couple of relay devices (and then onwards to the various NMS's) would be quite a win for us. These relay devices just need to be "dumb" forwarders (we don't require any filtering or storing, just reflection), but we need an HA pair (across two sites) without creating duplicates. I have the coding skills to make this myself, but as coding skills come and go in our network team, we are looking for a commerical product so it will continnue to work after I get: hit by a bus / amnesia / visions of grandeur. Any recommendations / experience? This needs to scale to ~1,500 devices. Thanks, Sam From Josh.Stephens at solarwinds.com Wed Mar 4 09:03:41 2009 From: Josh.Stephens at solarwinds.com (Stephens, Josh) Date: Wed, 4 Mar 2009 09:03:41 -0600 Subject: SNMP and syslog forwarders In-Reply-To: <49AE4F25.3010007@spacething.org> References: <49AE4F25.3010007@spacething.org> Message-ID: <832C54C8546AD0409AEA7E9FEBBEA1ECA5E005@AUS-EXC-01.tul.solarwinds.net> The free Kiwi Syslog Server will do this. Josh -----Original Message----- From: Sam Stickland [mailto:sam_mailinglists at spacething.org] Sent: Wednesday, March 04, 2009 3:52 AM To: NANOG list Subject: SNMP and syslog forwarders Hi, It's looking like running all of our traps and syslog through a couple of relay devices (and then onwards to the various NMS's) would be quite a win for us. These relay devices just need to be "dumb" forwarders (we don't require any filtering or storing, just reflection), but we need an HA pair (across two sites) without creating duplicates. I have the coding skills to make this myself, but as coding skills come and go in our network team, we are looking for a commerical product so it will continnue to work after I get: hit by a bus / amnesia / visions of grandeur. Any recommendations / experience? This needs to scale to ~1,500 devices. Thanks, Sam From dennis at thenose.net Wed Mar 4 09:38:32 2009 From: dennis at thenose.net (Dennis Dayman) Date: Wed, 4 Mar 2009 09:38:32 -0600 Subject: Yahoo postmaster? In-Reply-To: <20090303184522.GB1248920@hiwaay.net> References: <20090303165956.GA1248920@hiwaay.net> <63ac96a50903031019q60c15679y416a1a634d0b430b@mail.gmail.com> <20090303184522.GB1248920@hiwaay.net> Message-ID: I've sent your email onto one of them. -Dennis On Mar 3, 2009, at March 3,12:45 PM, Chris Adams wrote: > Once upon a time, Matthew Petach said: >> On 3/3/09, Chris Adams wrote: >>> Can a Yahoo postmaster ping me off list? I've got a couple of >>> servers >>> that appear to be mis-categorized. >> >> Contact information for the Yahoo postmasters is listed at >> http://postmaster.yahoo.com/ > > We've filled out multiple forms there with no response. That's why I > asked here. > -- > Chris Adams > Systems and Network Administrator - HiWAAY Internet Services > I don't speak for anybody but myself - that's enough trouble. > > From oberman at es.net Wed Mar 4 12:05:00 2009 From: oberman at es.net (R. Kevin Oberman) Date: 04 Mar 2009 10:05:00 -0800 Subject: MAC address confusion Message-ID: <3319005924.60580784@smtp.es.net> Sorry fot the top-post, but my Treo makes it almost impossible to do otherwise. The protocols using these reserved, local addresses all use them to embed the network layer address. AA addresses are used by DECnet and kin while 02 is for XNS, I seem to recall. As long as the only addresses used in these spaces are thse asigned by those protocols and they use peoperly assigned network layer addresses, ther will never be a conflict. That is the point in0the registration...marking them as reserved for the protocols in question and not to be used for anything else. Sent from my Treo: R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) E. O. Lawrence Berkeley National Laboratory (LBNL) oberman at es.net +1 510-486-8634 -----Original Message----- From: Saku Ytti Date: Wednesday, Mar 4, 2009 12:49 am Subject: Re: MAC address confusion To: nanog at nanog.org On (2009-03-03 13:50 -0800), Kevin Oberman wrote: > This is only a problem if you have multiple systems running DECnet (or some other protocol using this) with the same layer 3 address. That should never happen, so there should be no duplication. Why would they need to have same L3 address? The way I see it, only thing that matters is, if or not, the addresses might speak ethernetII. If your ethernetII switch sees your local 02 address and one of the addresses below and they collide, the switch will keep relearning the address behind two ports. Unless of course it is guaranteed, that none of these addresses will ever appear as BIA in ethernetII capable NIC. 02-07-01 (hex) RACAL-DATACOM 02-1C-7C (hex) PERQ SYSTEMS CORPORATION 02-60-86 (hex) LOGIC REPLACEMENT TECH. LTD. 02-60-8C (hex) 3COM CORPORATION 02-70-01 (hex) RACAL-DATACOM 02-70-B0 (hex) M/A-COM INC. COMPANIES 02-70-B3 (hex) DATA RECALL LTD 02-9D-8E (hex) CARDIAC RECORDERS INC. 02-AA-3C (hex) OLIVETTI TELECOMM SPA (OLTECO) 02-BB-01 (hex) OCTOTHORPE CORP. 02-C0-8C (hex) 3COM CORPORATION 02-CF-1C (hex) COMMUNICATION MACHINERY CORP. 02-E6-D3 (hex) NIXDORF COMPUTER CORPORATION -- ++ytti From simon.leinen at switch.ch Wed Mar 4 15:40:13 2009 From: simon.leinen at switch.ch (Simon Leinen) Date: Wed, 04 Mar 2009 22:40:13 +0100 Subject: SNMP and syslog forwarders In-Reply-To: <49AE4F25.3010007@spacething.org> (Sam Stickland's message of "Wed, 04 Mar 2009 09:51:33 +0000") References: <49AE4F25.3010007@spacething.org> Message-ID: Sam Stickland writes: > It's looking like running all of our traps and syslog through a couple > of relay devices (and then onwards to the various NMS's) would be > quite a win for us. You can try the UDP samplicator: http://www.switch.ch/network/downloads/tf-tant/samplicator/ (The name indicates that it can also sample packets, but that is just an option that can be ignored for your application.) > These relay devices just need to be "dumb" forwarders (we don't > require any filtering or storing, just reflection), but we need an HA > pair (across two sites) without creating duplicates. There is one complication with SNMP traps and also with typical Syslog packets: The IP source address carries important information that is not carried in the payload. So it's not sufficient for the relay to simply re-send the UDP datagrams without loss of information. Samplicator handles this with an option to spoof the IP source address when it resends the packets. (With this option, it must run as root, and you will have to drill holes in the ingress filters that you hopefully have even for your own servers. :-) > I have the coding skills to make this myself, but as coding skills > come and go in our network team, we are looking for a commerical > product so it will continnue to work after I get: hit by a bus / > amnesia / visions of grandeur. Not commercial, sorry. Maybe someone can sell you support for it (or life insurance). I should probably put it up on a code hosting service so that the community can maintain it. > Any recommendations / experience? This needs to scale to ~1,500 devices. Shouldn't be a problem. The main trick is to ensure that the forwarder's UDP receive buffers are large enough to handle bursts that might arrive while the forwarder/server is catching its breath. Samplicator lets you tune this socket buffer size. -- Simon. From christian at broknrobot.com Wed Mar 4 17:33:25 2009 From: christian at broknrobot.com (Christian Koch) Date: Wed, 4 Mar 2009 15:33:25 -0800 Subject: SNMP and syslog forwarders In-Reply-To: <49AE4F25.3010007@spacething.org> References: <49AE4F25.3010007@spacething.org> Message-ID: you can easily configure syslog-ng for forwarding/relaying syslog msgs to another box On Wed, Mar 4, 2009 at 1:51 AM, Sam Stickland wrote: > Hi, > > It's looking like running all of our traps and syslog through a couple of > relay devices (and then onwards to the various NMS's) would be quite a win > for us. > > These relay devices just need to be "dumb" forwarders (we don't require any > filtering or storing, just reflection), but we need an HA pair (across two > sites) without creating duplicates. > > I have the coding skills to make this myself, but as coding skills come and > go in our network team, we are looking for a commerical product so it will > continnue to work after I get: ?hit by a bus / amnesia / visions of > grandeur. > > Any recommendations / experience? This needs to scale to ~1,500 devices. > > Thanks, > > Sam > > From gremlin at portal-to-web.de Thu Mar 5 00:09:43 2009 From: gremlin at portal-to-web.de (Martin Mersberger) Date: Thu, 05 Mar 2009 07:09:43 +0100 Subject: SNMP and syslog forwarders In-Reply-To: <49AEA7C6.9050104@portal-to-web.de> References: <49AE4F25.3010007@spacething.org> <832C54C8546AD0409AEA7E9FEBBEA1ECA5E005@AUS-EXC-01.tul.solarwinds.net> <49AEA7C6.9050104@portal-to-web.de> Message-ID: <49AF6CA7.60900@portal-to-web.de> Hi Sam, For SNMP Traps, we were using 'Concord TrapExploder'. I'm not sure, if this is still named that way - it's now more than 1.5 years ago, I'd been involved in that project. As we had configured all network elements to send the Traps to both TrapExploders, we had to de-duplicate the traps on the EventManagement piece of our NMS platform. But that's been an easy one... For Syslog, we had used syslog-ng and it was just running like a charm.. .. just my 2ct's regards Martin > It's looking like running all of our traps and syslog through a couple > of relay devices (and then onwards to the various NMS's) would be quite > a win for us. > > These relay devices just need to be "dumb" forwarders (we don't require > any filtering or storing, just reflection), but we need an HA pair > (across two sites) without creating duplicates. > > I have the coding skills to make this myself, but as coding skills come > and go in our network team, we are looking for a commerical product so > it will continnue to work after I get: hit by a bus / amnesia / visions > > of grandeur. > > Any recommendations / experience? This needs to scale to ~1,500 devices. > > Thanks, > > Sam From AOsgood at Streamline-Solutions.net Thu Mar 5 08:11:00 2009 From: AOsgood at Streamline-Solutions.net (Aaron D. Osgood) Date: Thu, 5 Mar 2009 09:11:00 -0500 Subject: Clueful T-Mobile contact on the Circuit switched side? Message-ID: Please accept my apologies for the waste of space - Will someone from T-Mobile please contact me off list? It seems there is a 10k block of NPA-NXX #'s not in your table. All other rectification contact attempts have failed Thanks! Aaron D. Osgood Streamline Solutions L.L.C P.O. Box 6115 Falmouth, ME 04105 TEL: 207-781-5561 FAX: 207-781-8067 MOBILE: 207-831-5829 PAGE: 2078315829 at vtext.com AOLIM: OzCom1 ICQ: 206889374 AOsgood at Streamline-Solutions.net Blog: http://streamlinesolutionsllc.blogspot.com/ http://www.streamline-solutions.net http://www.WMDaWARe.com Introducing Efficiency to Business since 1986. From mike at sentex.net Thu Mar 5 09:49:18 2009 From: mike at sentex.net (Mike Tancsa) Date: Thu, 05 Mar 2009 10:49:18 -0500 Subject: "web problems" "ssl issues" Message-ID: <200903051549.n25FnUQd028367@lava.sentex.ca> Not sure if others are running into this or not, but we had a few vague support calls come in at once about browser 'ssl problems' and some issues with some websites 'taking forever to come up'... It looks like the common problem is bringing up pages that have src="https://siteseal.thawte.com/cgi/server/thawte_seal_generator.exe"> embedded in the web page the end user goes to. Depending on how the page is written, it can seem (to the end user anyways) as if the page is taking for ever to come up. The browser is blocking on talking to the site seal server. e.g. from the first syn, it was almost 25 seconds before the verisign/thawte server responded. 10:37:18.894068 IP 199.212.134.18.65064 > 65.205.248.240.443: S 2515327385:2515327385(0) win 64240 10:37:21.860159 IP 199.212.134.18.65064 > 65.205.248.240.443: S 2515327385:2515327385(0) win 64240 10:37:27.794374 IP 199.212.134.18.65064 > 65.205.248.240.443: S 2515327385:2515327385(0) win 64240 10:37:39.865205 IP 199.212.134.18.62217 > 65.205.248.242.443: S 3464052443:3464052443(0) win 64240 10:37:42.881109 IP 199.212.134.18.62217 > 65.205.248.242.443: S 3464052443:3464052443(0) win 64240 10:37:42.961994 IP 65.205.248.242.443 > 199.212.134.18.62217: S 3993252659:3993252659(0) ack 3464052444 win 5840 10:37:42.962311 IP 199.212.134.18.62217 > 65.205.248.242.443: . ack 1 win 64240 10:37:42.962799 IP 199.212.134.18.62217 > 65.205.248.242.443: P 1:103(102) ack 1 win 64240 10:37:43.035470 IP 65.205.248.242.443 > 199.212.134.18.62217: . ack 103 win 1460 10:37:43.037779 IP 65.205.248.242.443 > 199.212.134.18.62217: . 1:1461(1460) ack 103 win 1460 10:37:43.041639 IP 65.205.248.242.443 > 199.212.134.18.62217: . 1461:2921(1460) ack 103 win 1460 10:37:43.042292 IP 199.212.134.18.62217 > 65.205.248.242.443: . ack 2921 win 64240 10:37:43.118203 IP 65.205.248.242.443 > 199.212.134.18.62217: P 2921:3967(1046) ack 103 win 1460 10:37:43.119345 IP 199.212.134.18.62217 > 65.205.248.242.443: P 103:285(182) ack 3967 win 63194 network connectivity to 65.205.248.0/24 is fine for me. It looks to be at the application layer at verisign ? Just a heads up in case your helpdesk runs into this issue as well as it seems to be a rather obscure problem that sent us on a wild goose chase at first. Some browsers deal with it differently. on IE, most of the page does not display until the seal comes up or times out. ---Mike -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike at sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike From carlos at race.com Thu Mar 5 12:41:42 2009 From: carlos at race.com (Carlos Alcantar) Date: Thu, 5 Mar 2009 10:41:42 -0800 Subject: Clueful T-Mobile contact on the Circuit switched side? Message-ID: <859604546CD1FF488BDB6EA94C896AFB5930CF@racexchange.race.local> Do telco admins usally hang out on here? I know the telco side is an animal in it's self. -carlos -----Original Message----- From: Aaron D. Osgood [mailto:AOsgood at Streamline-Solutions.net] Sent: Thursday, March 05, 2009 6:11 AM To: nanog at nanog.org Subject: Clueful T-Mobile contact on the Circuit switched side? Please accept my apologies for the waste of space - Will someone from T-Mobile please contact me off list? It seems there is a 10k block of NPA-NXX #'s not in your table. All other rectification contact attempts have failed Thanks! Aaron D. Osgood Streamline Solutions L.L.C P.O. Box 6115 Falmouth, ME 04105 TEL: 207-781-5561 FAX: 207-781-8067 MOBILE: 207-831-5829 PAGE: 2078315829 at vtext.com AOLIM: OzCom1 ICQ: 206889374 AOsgood at Streamline-Solutions.net Blog: http://streamlinesolutionsllc.blogspot.com/ http://www.streamline-solutions.net http://www.WMDaWARe.com Introducing Efficiency to Business since 1986. From nanog at namor.ca Thu Mar 5 13:20:53 2009 From: nanog at namor.ca (nanog at namor.ca) Date: Thu, 5 Mar 2009 13:20:53 -0600 (CST) Subject: "web problems" "ssl issues" In-Reply-To: <200903051549.n25FnUQd028367@lava.sentex.ca> References: <200903051549.n25FnUQd028367@lava.sentex.ca> Message-ID: I hadn't thought about this until now, when I had to use our SPKI account with Thawte. It's painfully slow processing anything. I doesn't seem that anything's amiss with latency or network otherwise, but we're noticing this impact. I'm also just West of you, so I'm curious if it's slightly geographic in nature, as nobody else has noted similar that I've seen here. On Thu, 5 Mar 2009, Mike Tancsa wrote: > > Not sure if others are running into this or not, but we had a few > vague support calls come in at once about browser 'ssl problems' and > some issues with some websites 'taking forever to come up'... It > looks like the common problem is bringing up pages that have > > src="https://siteseal.thawte.com/cgi/server/thawte_seal_generator.exe"> > > embedded in the web page the end user goes to. > > Depending on how the page is written, it can seem (to the end user > anyways) as if the page is taking for ever to come up. The browser is > blocking on talking to the site seal server. > Just a heads up in case your helpdesk runs into this issue as well as > it seems to be a rather obscure problem that sent us on a wild goose > chase at first. Some browsers deal with it differently. on IE, most > of the page does not display until the seal comes up or times out. > > ---Mike > > -------------------------------------------------------------------- > Mike Tancsa, tel +1 519 651 3400 > Sentex Communications, mike at sentex.net > Providing Internet since 1994 www.sentex.net > Cambridge, Ontario Canada www.sentex.net/mike > > From morrowc.lists at gmail.com Thu Mar 5 13:32:56 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 5 Mar 2009 14:32:56 -0500 Subject: "web problems" "ssl issues" In-Reply-To: References: <200903051549.n25FnUQd028367@lava.sentex.ca> Message-ID: <75cb24520903051132i4b914bc2we3d2104b313bab1c@mail.gmail.com> On Thu, Mar 5, 2009 at 2:20 PM, wrote: > I hadn't thought about this until now, when I had to use our SPKI account > with Thawte. ?It's painfully slow processing anything. > > I doesn't seem that anything's amiss with latency or network otherwise, but > we're noticing this impact. > > I'm also just West of you, so I'm curious if it's slightly geographic in > nature, as nobody else has noted similar that I've seen here. > doubtful it's GEO related from both ATL and SAC and IAD I get the same dns mappings: ;; ANSWER SECTION: siteseal.thawte.com. 900 IN A 65.205.248.247 siteseal.thawte.com. 900 IN A 65.205.248.251 siteseal.thawte.com. 900 IN A 65.205.248.236 siteseal.thawte.com. 900 IN A 65.205.248.240 siteseal.thawte.com. 900 IN A 65.205.248.242 siteseal.thawte.com. 900 IN A 65.205.248.246 I don't, however, get any reasonable response on port 443 to these ips... (they all seem to be in SJC-area fyi) Perhaps Thawte/VS is experiencing some LB or load issues? -Chris > On Thu, 5 Mar 2009, Mike Tancsa wrote: > >> >> Not sure if others are running into this or not, but we had a few vague >> support calls come in at once about browser 'ssl problems' and some issues >> with some websites 'taking forever to come up'... ?It looks like the common >> problem is bringing up pages that have >> >> src="https://siteseal.thawte.com/cgi/server/thawte_seal_generator.exe"> >> >> embedded in the web page the end user goes to. >> >> Depending on how the page is written, it can seem (to the end user >> anyways) as if the page is taking for ever to come up. The browser is >> blocking on talking to the site seal server. > > >> >> Just a heads up in case your helpdesk runs into this issue as well as it >> seems to be a rather obscure problem that sent us on a wild goose chase at >> first. ?Some browsers deal with it differently. on IE, most of the page does >> not display until the seal comes up or times out. >> >> ? ? ? ? ---Mike >> >> -------------------------------------------------------------------- >> Mike Tancsa, ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?tel +1 519 651 3400 >> Sentex Communications, ? ? ? ? ? ? ? ? ? ? ? ? ? ?mike at sentex.net >> Providing Internet since 1994 ? ? ? ? ? ? ? ? ? ?www.sentex.net >> Cambridge, Ontario Canada ? ? ? ? ? ? ? ? ? ? ? ? www.sentex.net/mike >> >> > > From mike at sentex.net Thu Mar 5 13:57:50 2009 From: mike at sentex.net (Mike Tancsa) Date: Thu, 05 Mar 2009 14:57:50 -0500 Subject: "web problems" "ssl issues" In-Reply-To: <75cb24520903051132i4b914bc2we3d2104b313bab1c@mail.gmail.co m> References: <200903051549.n25FnUQd028367@lava.sentex.ca> <75cb24520903051132i4b914bc2we3d2104b313bab1c@mail.gmail.com> Message-ID: <200903051957.n25JvirZ030856@lava.sentex.ca> At 02:32 PM 3/5/2009, Christopher Morrow wrote: >Perhaps Thawte/VS is experiencing some LB or load issues? If any verisign folks are around, it would make life a lot easier if an RST was sent instead of timing out like it is/was ---Mike From morrowc.lists at gmail.com Thu Mar 5 14:27:58 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 5 Mar 2009 15:27:58 -0500 Subject: "web problems" "ssl issues" In-Reply-To: <200903051957.n25JvirZ030856@lava.sentex.ca> References: <200903051549.n25FnUQd028367@lava.sentex.ca> <75cb24520903051132i4b914bc2we3d2104b313bab1c@mail.gmail.com> <200903051957.n25JvirZ030856@lava.sentex.ca> Message-ID: <75cb24520903051227r3c9cacf4jdff1c5b4485d1c89@mail.gmail.com> On Thu, Mar 5, 2009 at 2:57 PM, Mike Tancsa wrote: > At 02:32 PM 3/5/2009, Christopher Morrow wrote: > >> Perhaps Thawte/VS is experiencing some LB or load issues? > > If any verisign folks are around, it would make life a lot easier if an RST > was sent instead of timing out like it is/was ask and yee shall recieve: $ t siteseal.thawte.com 443 Trying 65.205.248.251... telnet: connect to address 65.205.248.251: Connection refused Trying 65.205.248.236... telnet: connect to address 65.205.248.236: Connection refused Trying 65.205.248.240... telnet: connect to address 65.205.248.240: Connection refused Trying 65.205.248.242... telnet: connect to address 65.205.248.242: Connection refused Trying 65.205.248.246... telnet: connect to address 65.205.248.246: Connection refused Trying 65.205.248.247... telnet: connect to address 65.205.248.247: Connection refused telnet: Unable to connect to remote host: Connection refused that happens immediately now... From Mauricio.Rodriguez at fpl.com Thu Mar 5 16:02:02 2009 From: Mauricio.Rodriguez at fpl.com (Rodriguez, Mauricio) Date: Thu, 5 Mar 2009 17:02:02 -0500 Subject: Usage-Based Billing for DIA Message-ID: Looking at possibilities for an implementation of usage-based billing, it seems that the same techniques and tools always come up. I'm looking for some feedback from the list on experiences with these tools and techniques as well as alternatives that may not be listed here. +Techniques --Flow data (Netflow, SFlow, etc) analysis to determine 95th percentile traffic levels --SNMP polling of interface counters to determine 95th percentile traffic levels Granted, there are many interpretations of how to calculate "95th percentile traffic levels" that may differ from provider to provider. Assume that we have established the method that we will use. +Tools --RTG --MRTG --Cacti --solarwinds Orion --Various, expensive PM tools such as Netcool Proviso, JDSU NetComplete, InfoVista tools, etc --flow-tools and FlowScan combo --Arbor Networks Peakflow Any follow up to this thread, either on or off list, or pointers to previous threads with good information would be appreciated! My search didn't turn up any, but that doesn't mean that they don't exist! Thanks! Regards, Mauricio Rodriguez Manager of IP/Data Engineering, FPL FiberNet Email: Mauricio.Rodriguez at fpl.com From wim at nyetwork.org Thu Mar 5 16:28:07 2009 From: wim at nyetwork.org (Wim Kerkhoff) Date: Thu, 05 Mar 2009 14:28:07 -0800 Subject: Usage-Based Billing for DIA In-Reply-To: References: Message-ID: <49B051F7.9090808@nyetwork.org> Rodriguez, Mauricio said the following, On 3/5/2009 2:02 PM: > Looking at possibilities for an implementation of usage-based billing, it seems that the same techniques and tools always come up. I'm looking for some feedback from the list on experiences with these tools and techniques as well as alternatives that may not be listed here. > > +Techniques > --Flow data (Netflow, SFlow, etc) analysis to determine 95th percentile traffic levels > --SNMP polling of interface counters to determine 95th percentile traffic levels > I've been using pmacctd for several years with good success. It is designed for actual usage accounting (for instance, GB per month per IP/subnet) rather then 95th percentile. The beauty of pmacctd is that it simply puts the data into an SQL database. Once the data is stored, you can write any SQL queries as required for reporting. http://www.pmacct.net/ Wim From frnkblk at iname.com Thu Mar 5 16:58:07 2009 From: frnkblk at iname.com (Frank Bulk) Date: Thu, 5 Mar 2009 16:58:07 -0600 Subject: Clueful T-Mobile contact on the Circuit switched side? In-Reply-To: References: Message-ID: You may have more luck posting on one of these listservs: http://listserv.neustar.biz/mailman/listinfo Frank -----Original Message----- From: Aaron D. Osgood [mailto:AOsgood at Streamline-Solutions.net] Sent: Thursday, March 05, 2009 8:11 AM To: nanog at nanog.org Subject: Clueful T-Mobile contact on the Circuit switched side? Please accept my apologies for the waste of space - Will someone from T-Mobile please contact me off list? It seems there is a 10k block of NPA-NXX #'s not in your table. All other rectification contact attempts have failed Thanks! Aaron D. Osgood Streamline Solutions L.L.C P.O. Box 6115 Falmouth, ME 04105 TEL: 207-781-5561 FAX: 207-781-8067 MOBILE: 207-831-5829 PAGE: 2078315829 at vtext.com AOLIM: OzCom1 ICQ: 206889374 AOsgood at Streamline-Solutions.net Blog: http://streamlinesolutionsllc.blogspot.com/ http://www.streamline-solutions.net http://www.WMDaWARe.com Introducing Efficiency to Business since 1986. From castellan2004-nsm at yahoo.com Thu Mar 5 17:23:59 2009 From: castellan2004-nsm at yahoo.com (Subba Rao) Date: Thu, 5 Mar 2009 15:23:59 -0800 (PST) Subject: Cisco Audit Tool? Message-ID: <47518.66953.qm@web30805.mail.mud.yahoo.com> For auditing, is there any Cisco Router/Switch configuration analysis tool? Thank you in advance. Subba Rao From msmith at internap.com Thu Mar 5 17:26:31 2009 From: msmith at internap.com (Michael Smith) Date: Thu, 5 Mar 2009 18:26:31 -0500 Subject: Cisco Audit Tool? Message-ID: <65C5927BEED3C2428307863DB5C6C6FB02006556@cx49.800onemail.com> RANCID is useful. ----- Original Message ----- From: Subba Rao To: nanog at nanog.org Sent: Thu Mar 05 18:23:59 2009 Subject: Cisco Audit Tool? For auditing, is there any Cisco Router/Switch configuration analysis tool? Thank you in advance. Subba Rao From meenoo at gmail.com Thu Mar 5 17:43:30 2009 From: meenoo at gmail.com (Meenoo Shivdasani) Date: Thu, 5 Mar 2009 18:43:30 -0500 Subject: Cisco Audit Tool? In-Reply-To: <47518.66953.qm@web30805.mail.mud.yahoo.com> References: <47518.66953.qm@web30805.mail.mud.yahoo.com> Message-ID: On Thu, Mar 5, 2009 at 6:23 PM, Subba Rao wrote: > For auditing, is there any Cisco Router/Switch configuration analysis tool? If you mean auditing for security purposes, try the Router Audit Tool at http://www.cisecurity.org/bench_cisco.html M From andre at operations.net Thu Mar 5 17:46:52 2009 From: andre at operations.net (Andre Gironda) Date: Thu, 5 Mar 2009 15:46:52 -0800 Subject: Cisco Audit Tool? In-Reply-To: References: <47518.66953.qm@web30805.mail.mud.yahoo.com> Message-ID: <2fd9390e0903051546g72b92f8cp385ef0af86948dc3@mail.gmail.com> On Thu, Mar 5, 2009 at 3:43 PM, Meenoo Shivdasani wrote: > On Thu, Mar 5, 2009 at 6:23 PM, Subba Rao wrote: >> For auditing, is there any Cisco Router/Switch configuration analysis tool? > > If you mean auditing for security purposes, try the Router Audit Tool > at http://www.cisecurity.org/bench_cisco.html Or Nipper - http://nipper.sf.net dre From jlewis at lewis.org Thu Mar 5 18:41:32 2009 From: jlewis at lewis.org (Jon Lewis) Date: Thu, 5 Mar 2009 19:41:32 -0500 (EST) Subject: Usage-Based Billing for DIA In-Reply-To: References: Message-ID: On Thu, 5 Mar 2009, Rodriguez, Mauricio wrote: > Looking at possibilities for an implementation of usage-based billing, > it seems that the same techniques and tools always come up. I'm looking > for some feedback from the list on experiences with these tools and > techniques as well as alternatives that may not be listed here. > > +Techniques > --Flow data (Netflow, SFlow, etc) analysis to determine > 95th percentile traffic levels > --SNMP polling of interface counters to determine 95th > percentile traffic levels I need to look into this in the near future as well. The problems I'm aware of are: 1) we have customers on policed ports, and the interface snmp counters count packets before service-policy. It doesn't seem right to bill for packets we dropped :)...so this isn't useful data for billing purposes. 2) our customer agg gear (cisco 3550s) don't do netflow. Our bigger switches the agg gear uplinks to does (6509 sup720-3bxls), but can't handle export of full netflow, so we run sampled. It's still useful for abuse tracking, but billing based on it would require some large assumptions and multipliers...unlikely to be of use. The remaining option I'm aware of is to use monitor sessions to send a copy of our traffic to a system/device which would then either generate "full" netflow data or just distill the traffic into data xfered per IP/network. What are people using for this on the several hundred mbit/s to a few gigabits/s or more range? Are there other ways? ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From jack at crepinc.com Thu Mar 5 19:19:02 2009 From: jack at crepinc.com (Jack Carrozzo) Date: Thu, 5 Mar 2009 20:19:02 -0500 Subject: Usage-Based Billing for DIA In-Reply-To: References: Message-ID: <2ad0f9f60903051719w5b8b762fgb2be58221c63306e@mail.gmail.com> I use netacct - can grab data per cidr block and dumps data into mysql. I wrote scripts from there to graph in rrdtool, bill on total usage, or bill on 95th percentile. http://netacct-mysql.gabrovo.com/ -Jack Carrozzo On Thu, Mar 5, 2009 at 7:41 PM, Jon Lewis wrote: > On Thu, 5 Mar 2009, Rodriguez, Mauricio wrote: > >> Looking at possibilities for an implementation of usage-based billing, it >> seems that the same techniques and tools always come up. ?I'm looking for >> some feedback from the list on experiences with these tools and techniques >> as well as alternatives that may not be listed here. >> >> +Techniques >> ? ? ? ? ? ? ? --Flow data (Netflow, SFlow, etc) analysis to determine 95th >> percentile traffic levels >> ? ? ? ? ? ? ? --SNMP polling of interface counters to determine 95th >> percentile traffic levels > > > I need to look into this in the near future as well. ?The problems I'm aware > of are: > > 1) we have customers on policed ports, and the interface snmp counters count > packets before service-policy. ?It doesn't seem right to bill for packets we > dropped :)...so this isn't useful data for billing purposes. > > 2) our customer agg gear (cisco 3550s) don't do netflow. ?Our bigger > switches the agg gear uplinks to does (6509 sup720-3bxls), but can't handle > export of full netflow, so we run sampled. ?It's still useful for abuse > tracking, but billing based on it would require some large assumptions and > multipliers...unlikely to be of use. > > The remaining option I'm aware of is to use monitor sessions to send a copy > of our traffic to a system/device which would then either generate "full" > netflow data or just distill the traffic into data xfered per IP/network. > ?What are people using for this on the several hundred mbit/s to a few > gigabits/s or more range? > > Are there other ways? > > ---------------------------------------------------------------------- > ?Jon Lewis ? ? ? ? ? ? ? ? ? | ?I route > ?Senior Network Engineer ? ? | ?therefore you are > ?Atlantic Net ? ? ? ? ? ? ? ?| > _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ > > From cmadams at hiwaay.net Thu Mar 5 19:41:37 2009 From: cmadams at hiwaay.net (Chris Adams) Date: Thu, 5 Mar 2009 19:41:37 -0600 Subject: Usage-Based Billing for DIA In-Reply-To: References: Message-ID: <20090306014136.GA693822@hiwaay.net> Once upon a time, Jon Lewis said: > 1) we have customers on policed ports, and the interface snmp counters > count packets before service-policy. It doesn't seem right to bill for > packets we dropped :)...so this isn't useful data for billing purposes. Not sure how you are policing, but I belive both Juniper and Cisco have MIBs that show the policed traffic. For example, when we used Cisco CAR to limit traffic on some ports, I set up Cricket to monitor both the base port and the CAR stats (so we could see how much traffic was actually passed). I haven't got around to doing it for Juniper firewall policers, but I pretty sure the info is in a MIB. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From js.lists at gmail.com Fri Mar 6 02:12:42 2009 From: js.lists at gmail.com (Joe S) Date: Fri, 6 Mar 2009 00:12:42 -0800 Subject: Cisco Audit Tool? In-Reply-To: <47518.66953.qm@web30805.mail.mud.yahoo.com> References: <47518.66953.qm@web30805.mail.mud.yahoo.com> Message-ID: Depends on your goal. Trying to identify and fix configuration problems? Take a look at NetMRI from Netcordia. We demo'd it. We liked it and bought it. On Thu, Mar 5, 2009 at 3:23 PM, Subba Rao wrote: > For auditing, is there any Cisco Router/Switch configuration analysis tool? > > Thank you in advance. > > Subba Rao > > From cidr-report at potaroo.net Fri Mar 6 05:00:02 2009 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 6 Mar 2009 22:00:02 +1100 (EST) Subject: BGP Update Report Message-ID: <200903061100.n26B02ft088533@wattle.apnic.net> BGP Update Report Interval: 02-Feb-09 -to- 05-Mar-09 (32 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS9583 371772 7.9% 304.2 -- SIFY-AS-IN Sify Limited 2 - AS7643 85782 1.8% 191.1 -- VNN-AS-AP Vietnam Posts and Telecommunications (VNPT) 3 - AS3130 76761 1.6% 590.5 -- RGNET-3130 RGnet/PSGnet 4 - AS6629 48185 1.0% 741.3 -- NOAA-AS - NOAA 5 - AS30890 46688 1.0% 104.4 -- EVOLVA Evolva Telecom 6 - AS35805 46332 1.0% 122.6 -- UTG-AS United Telecom AS 7 - AS17974 33739 0.7% 65.6 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 8 - AS5056 32081 0.7% 276.6 -- INS-NET-2 - Iowa Network Services 9 - AS6458 31080 0.7% 83.5 -- Telgua 10 - AS27757 29317 0.6% 240.3 -- ANDINATEL S.A. 11 - AS30306 29166 0.6% 7291.5 -- AfOL-Sz-AS 12 - AS17488 26400 0.6% 16.1 -- HATHWAY-NET-AP Hathway IP Over Cable Internet 13 - AS4771 25926 0.6% 97.5 -- NZTELECOM Netgate 14 - AS30969 24110 0.5% 3013.8 -- TAN-NET TransAfrica Networks 15 - AS5050 24045 0.5% 1849.6 -- PSC-EXT - Pittsburgh Supercomputing Center 16 - AS9829 22631 0.5% 35.4 -- BSNL-NIB National Internet Backbone 17 - AS29372 20867 0.4% 254.5 -- SFR-NETWORK SFR 18 - AS4648 20817 0.4% 101.5 -- NZIX-2 Netgate 19 - AS8103 19963 0.4% 33.4 -- STATE-OF-FLA - Florida Department of Management Services - Technology Program 20 - AS1785 19665 0.4% 10.4 -- AS-PAETEC-NET - PaeTec Communications, Inc. TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS30306 29166 0.6% 7291.5 -- AfOL-Sz-AS 2 - AS30287 5633 0.1% 5633.0 -- ALON-USA - ALON USA, LP 3 - AS19017 4461 0.1% 4461.0 -- QUALCOMM-QWBS-LV - Qualcomm, Inc. 4 - AS12500 14961 0.3% 3740.2 -- RCS-AS RCS Autonomus System 5 - AS30969 24110 0.5% 3013.8 -- TAN-NET TransAfrica Networks 6 - AS41382 2953 0.1% 2953.0 -- TELEPORT-AS Teleport LLC Network AS 7 - AS28194 5834 0.1% 2917.0 -- 8 - AS35335 1896 0.0% 1896.0 -- ESSTU-AS East-Siberian State Technological University AS 9 - AS5050 24045 0.5% 1849.6 -- PSC-EXT - Pittsburgh Supercomputing Center 10 - AS32398 11217 0.2% 1402.1 -- REALNET-ASN-1 11 - AS5033 11816 0.2% 1312.9 -- ISW - Internet Specialties West Inc. 12 - AS35410 7322 0.1% 1220.3 -- RU-LVS-AS LVS AS Number 13 - AS39107 2262 0.1% 1131.0 -- INTERLAN-AS Asociatia Interlan 14 - AS29224 2148 0.1% 1074.0 -- HELLMANN Hellmann Worldwide Logistics GmbH & Co KG 15 - AS48144 1014 0.0% 1014.0 -- NETWORKTECH Network Technology 16 - AS16559 19125 0.4% 1006.6 -- REALCONNECT-01 - RealConnect, Inc 17 - AS46781 916 0.0% 916.0 -- ASN1 - White Nile Group, Inc. 18 - AS46328 7720 0.2% 857.8 -- PTCNEBRASKA - PIERCE TELEPHONE COMPANY, INCORPORATED 19 - AS5691 10194 0.2% 784.2 -- MITRE-AS-5 - The MITRE Corporation 20 - AS41343 1505 0.0% 752.5 -- TRIUNFOTEL-ASN TRIUNFOTEL TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 221.134.32.0/24 38589 0.7% AS9583 -- SIFY-AS-IN Sify Limited 2 - 210.214.177.0/24 27805 0.5% AS9583 -- SIFY-AS-IN Sify Limited 3 - 210.214.232.0/24 27574 0.5% AS9583 -- SIFY-AS-IN Sify Limited 4 - 210.214.132.0/24 27557 0.5% AS9583 -- SIFY-AS-IN Sify Limited 5 - 210.214.222.0/24 27505 0.5% AS9583 -- SIFY-AS-IN Sify Limited 6 - 210.214.146.0/24 27424 0.5% AS9583 -- SIFY-AS-IN Sify Limited 7 - 210.214.117.0/24 27140 0.5% AS9583 -- SIFY-AS-IN Sify Limited 8 - 210.214.184.0/24 26128 0.5% AS9583 -- SIFY-AS-IN Sify Limited 9 - 210.210.127.0/24 25305 0.5% AS9583 -- SIFY-AS-IN Sify Limited 10 - 221.135.105.0/24 25020 0.5% AS9583 -- SIFY-AS-IN Sify Limited 11 - 210.214.156.0/24 24565 0.5% AS9583 -- SIFY-AS-IN Sify Limited 12 - 72.23.246.0/24 23922 0.5% AS5050 -- PSC-EXT - Pittsburgh Supercomputing Center 13 - 192.35.129.0/24 16134 0.3% AS6629 -- NOAA-AS - NOAA 14 - 192.102.88.0/24 15940 0.3% AS6629 -- NOAA-AS - NOAA 15 - 198.77.177.0/24 15849 0.3% AS6629 -- NOAA-AS - NOAA 16 - 221.135.107.0/24 15322 0.3% AS9583 -- SIFY-AS-IN Sify Limited 17 - 212.85.223.0/24 14479 0.3% AS30306 -- AfOL-Sz-AS 18 - 212.85.220.0/24 14447 0.3% AS30306 -- AfOL-Sz-AS 19 - 190.152.100.0/24 14301 0.3% AS27757 -- ANDINATEL S.A. 20 - 190.152.103.0/24 13454 0.2% AS27757 -- ANDINATEL S.A. Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Mar 6 05:00:00 2009 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 6 Mar 2009 22:00:00 +1100 (EST) Subject: The Cidr Report Message-ID: <200903061100.n26B00vC088524@wattle.apnic.net> This report has been generated at Fri Mar 6 21:18:40 2009 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 27-02-09 288243 180060 28-02-09 288312 180388 01-03-09 288699 180352 02-03-09 288534 180327 03-03-09 288768 180064 04-03-09 288388 180088 05-03-09 288622 180096 06-03-09 288940 180192 AS Summary 30863 Number of ASes in routing system 13119 Number of ASes announcing only one prefix 4364 Largest number of prefixes announced by an AS AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc. 89807872 Largest address span announced by an AS (/32s) AS27064: DDN-ASNBLK1 - DoD Network Information Center Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 06Mar09 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 289238 180181 109057 37.7% All ASes AS6389 4364 351 4013 92.0% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4323 4233 1827 2406 56.8% TWTC - tw telecom holdings, inc. AS209 2839 1256 1583 55.8% ASN-QWEST - Qwest Communications Corporation AS4766 1815 529 1286 70.9% KIXS-AS-KR Korea Telecom AS17488 1527 350 1177 77.1% HATHWAY-NET-AP Hathway IP Over Cable Internet AS22773 1028 65 963 93.7% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS4755 1210 255 955 78.9% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS8452 1236 328 908 73.5% TEDATA TEDATA AS8151 1442 602 840 58.3% Uninet S.A. de C.V. AS1785 1725 943 782 45.3% AS-PAETEC-NET - PaeTec Communications, Inc. AS11492 1191 458 733 61.5% CABLEONE - CABLE ONE, INC. AS19262 958 248 710 74.1% VZGNI-TRANSIT - Verizon Internet Services Inc. AS7545 754 192 562 74.5% TPG-INTERNET-AP TPG Internet Pty Ltd AS3356 1159 598 561 48.4% LEVEL3 Level 3 Communications AS18101 751 195 556 74.0% RIL-IDC Reliance Infocom Ltd Internet Data Centre, AS6478 1277 731 546 42.8% ATT-INTERNET3 - AT&T WorldNet Services AS2706 545 26 519 95.2% HKSUPER-HK-AP Pacific Internet (Hong Kong) Limited AS22047 608 120 488 80.3% VTR BANDA ANCHA S.A. AS17908 600 120 480 80.0% TCISL Tata Communications AS855 631 166 465 73.7% CANET-ASN-4 - Bell Aliant AS4808 607 157 450 74.1% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS10620 806 361 445 55.2% TV Cable S.A. AS24560 675 239 436 64.6% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS7018 1441 1007 434 30.1% ATT-INTERNET4 - AT&T WorldNet Services AS4134 927 505 422 45.5% CHINANET-BACKBONE No.31,Jin-rong Street AS4668 701 285 416 59.3% LGNET-AS-KR LG CNS AS9443 507 91 416 82.1% INTERNETPRIMUS-AS-AP Primus Telecommunications AS17676 527 117 410 77.8% GIGAINFRA BB TECHNOLOGY Corp. AS7011 954 552 402 42.1% FRONTIER-AND-CITIZENS - Frontier Communications of America, Inc. AS6471 440 61 379 86.1% ENTEL CHILE S.A. Total 37478 12735 24743 66.0% Top 30 total Possible Bogus Routes 24.75.116.0/22 AS10796 SCRR-10796 - Road Runner HoldCo LLC 24.75.160.0/19 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 24.245.128.0/17 AS11492 CABLEONE - CABLE ONE, INC. 24.246.0.0/17 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 24.246.128.0/18 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 41.220.16.0/20 AS8668 TELONE-AS TelOne Zimbabwe P/L 41.223.112.0/22 AS5713 SAIX-NET 41.223.188.0/24 AS22351 INTELSAT Intelsat Global BGP Routing Policy 41.223.189.0/24 AS26452 BRING-AS - BringCom, Inc. 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 63.140.213.0/24 AS22555 UTC - Universal Talkware Corporation 63.143.251.0/24 AS22555 UTC - Universal Talkware Corporation 64.31.32.0/19 AS11955 SCRR-11955 - Road Runner HoldCo LLC 64.31.32.0/22 AS10796 SCRR-10796 - Road Runner HoldCo LLC 64.31.36.0/23 AS10796 SCRR-10796 - Road Runner HoldCo LLC 64.31.38.0/23 AS12262 RR-CINCINNATI-ASN-01 - Road Runner HoldCo LLC 64.31.40.0/23 AS12262 RR-CINCINNATI-ASN-01 - Road Runner HoldCo LLC 64.31.42.0/23 AS10796 SCRR-10796 - Road Runner HoldCo LLC 64.31.44.0/23 AS10796 SCRR-10796 - Road Runner HoldCo LLC 64.31.46.0/24 AS10796 SCRR-10796 - Road Runner HoldCo LLC 64.31.48.0/22 AS11060 NEO-RR-COM - Road Runner HoldCo LLC 64.31.53.0/24 AS10796 SCRR-10796 - Road Runner HoldCo LLC 64.31.55.0/24 AS10796 SCRR-10796 - Road Runner HoldCo LLC 64.31.59.0/24 AS7017 SCRR-7015 - Road Runner HoldCo LLC 64.31.60.0/24 AS7017 SCRR-7015 - Road Runner HoldCo LLC 64.64.159.0/24 AS32004 BIG-ASN - Business Information Group, Inc. 64.79.88.0/24 AS26096 LODDEN - Lodden Services 64.79.89.0/24 AS26096 LODDEN - Lodden Services 64.147.64.0/19 AS40156 THEOPT-HOU - The Optimal Link Corporation 66.11.32.0/20 AS6261 VISINET - Visionary Systems, Inc. 66.11.40.0/21 AS6261 VISINET - Visionary Systems, Inc. 66.54.91.0/24 AS30506 BLACKSUN-1 - Blacksun Technologies LLC 66.55.160.0/19 AS29994 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.206.32.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.33.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.34.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.35.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.40.0/22 AS174 COGENT Cogent/PSI 66.206.44.0/23 AS174 COGENT Cogent/PSI 66.206.47.0/24 AS17557 PKTELECOM-AS-AP Pakistan Telecom 66.207.32.0/20 AS23011 69.71.192.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 69.80.0.0/17 AS3043 AMPHIB-AS - Amphibian Media Corporation 80.88.0.0/21 AS33774 DJAWEB 80.88.8.0/22 AS33774 DJAWEB 80.88.10.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 95.140.112.0/20 AS29433 MEDIAWORKS-AS Media Works ISP Autonomous System 95.140.112.0/22 AS29433 MEDIAWORKS-AS Media Works ISP Autonomous System 95.140.116.0/22 AS29433 MEDIAWORKS-AS Media Works ISP Autonomous System 95.140.120.0/22 AS29433 MEDIAWORKS-AS Media Works ISP Autonomous System 95.140.124.0/22 AS29433 MEDIAWORKS-AS Media Works ISP Autonomous System 95.215.128.0/22 AS34863 HEXANET Hexanet 98.96.0.0/13 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 109.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 109.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 109.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 121.50.168.0/21 AS9931 CAT-AP The Communication Authoity of Thailand, CAT 122.128.120.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. 137.0.0.0/13 AS27064 DDN-ASNBLK1 - DoD Network Information Center 163.142.0.0/16 AS2500 WIDE-BB WIDE Project 172.7.0.0/24 AS28175 172.10.1.0/30 AS18305 POSNET POSDATA Co.,Ltd 178.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 178.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 178.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc 192.9.200.0/24 AS3602 AS3602-RTI - Rogers Telecom Inc. 192.64.85.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.107.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.108.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.177.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.70.164.0/24 AS25689 NRCNET-AS - National Research Council of Canada 192.96.36.0/24 AS5713 SAIX-NET 192.96.37.0/24 AS10474 NETACTIVE 192.96.135.0/24 AS2018 TENET-1 192.96.136.0/23 AS2018 TENET-1 192.96.141.0/24 AS2018 TENET-1 192.96.143.0/24 AS2018 TENET-1 192.96.145.0/24 AS2018 TENET-1 192.96.177.0/24 AS6083 POSIX-AFRICA 192.101.45.0/24 AS2905 TICSA-ASN 192.101.46.0/24 AS6503 Avantel, S.A. 192.101.64.0/21 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.72.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.74.0/24 AS1239 SPRINTLINK - Sprint 192.124.248.0/23 AS680 DFN-IP service G-WiN 192.124.252.0/22 AS680 DFN-IP service G-WiN 192.131.233.0/24 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 192.133.6.0/24 AS10282 ORANGE-BUSINESS-SERVICES-CEEUR Orange Business Services (formerly Equant) AS for CEEUR 192.153.144.0/21 AS27064 DDN-ASNBLK1 - DoD Network Information Center 192.154.32.0/19 AS81 NCREN - MCNC 192.188.208.0/20 AS27064 DDN-ASNBLK1 - DoD Network Information Center 196.6.108.0/24 AS5713 SAIX-NET 196.10.119.0/24 AS2018 TENET-1 196.10.122.0/23 AS2018 TENET-1 196.10.251.0/24 AS2018 TENET-1 196.10.252.0/23 AS2018 TENET-1 196.10.254.0/24 AS2018 TENET-1 196.13.101.0/24 AS2018 TENET-1 196.13.102.0/23 AS2018 TENET-1 196.13.104.0/24 AS2018 TENET-1 196.13.121.0/24 AS2018 TENET-1 196.13.125.0/24 AS2018 TENET-1 196.13.126.0/24 AS2018 TENET-1 196.13.169.0/24 AS2018 TENET-1 196.13.174.0/23 AS2018 TENET-1 196.13.176.0/21 AS2018 TENET-1 196.13.192.0/22 AS2018 TENET-1 196.13.196.0/24 AS2018 TENET-1 196.32.96.0/20 AS6453 GLOBEINTERNET TATA Communications 196.202.224.0/21 AS8818 TELE Greenland Autonomous System 198.1.2.0/24 AS4761 INDOSAT-INP-AP INDOSAT Internet Network Provider 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc. 198.54.82.0/24 AS2018 TENET-1 198.54.92.0/24 AS2018 TENET-1 198.54.222.0/24 AS2018 TENET-1 198.97.72.0/21 AS27064 DDN-ASNBLK1 - DoD Network Information Center 198.97.80.0/20 AS27064 DDN-ASNBLK1 - DoD Network Information Center 198.97.96.0/19 AS27064 DDN-ASNBLK1 - DoD Network Information Center 198.97.240.0/20 AS27064 DDN-ASNBLK1 - DoD Network Information Center 198.161.87.0/24 AS6539 GT-BELL - Bell Canada 198.167.0.0/16 AS7456 INTERHOP - Interhop Network SERVICES Inc. 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 198.169.0.0/16 AS803 SASKTEL - Saskatchewan Telecommunications 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services 199.10.0.0/16 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.114.0.0/21 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.114.128.0/18 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.114.130.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.131.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.132.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.134.0/24 AS3541 ITSDN-U4 - DoD Network Information Center 199.114.136.0/24 AS27044 DDN-ASNBLK1 - DoD Network Information Center 199.114.138.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.140.0/24 AS3544 ITSDN-U7 - DoD Network Information Center 199.114.142.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.144.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.148.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.150.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.152.0/24 AS27033 DDN-ASNBLK1 - DoD Network Information Center 199.114.153.0/24 AS27034 DDN-ASNBLK1 - DoD Network Information Center 199.114.154.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.114.156.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.114.160.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.121.0.0/16 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.123.0.0/18 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.123.16.0/20 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.123.80.0/21 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.189.32.0/19 AS7332 IQUEST-AS - IQuest Internet 199.202.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.202.216.0/21 AS577 BACOM - Bell Canada 199.246.116.0/24 AS813 UUNET-CANADA - MCI Communications Services, Inc. d/b/a Verizon Business 202.6.176.0/20 AS24316 202.58.113.0/24 AS19161 INNOCOM-TELECOM - INNOCOM TELECOM 202.58.224.0/19 AS17925 202.58.224.0/20 AS17925 202.58.240.0/20 AS17925 202.58.240.0/24 AS17925 202.58.244.0/24 AS17925 202.58.249.0/24 AS17925 202.58.250.0/24 AS17925 202.58.253.0/24 AS17925 202.72.46.0/24 AS38205 202.72.47.0/24 AS38205 202.73.144.0/20 AS4788 TMNET-AS-AP TM Net, Internet Service Provider 202.80.192.0/20 AS2706 HKSUPER-HK-AP Pacific Internet (Hong Kong) Limited 202.86.252.0/22 AS4748 RESOLINK-AS-AP Resources Link Network Limited 202.86.252.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.253.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.254.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.255.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.94.70.0/24 AS9837 POWERTEL-AP Powertel Ltd 202.122.120.0/21 AS17494 BTTB-AS-AP Telecom Operator & Internet Service Provider as well 202.124.195.0/24 AS17557 PKTELECOM-AS-AP Pakistan Telecom 202.133.70.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.133.73.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.136.254.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.136.255.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.140.160.0/24 AS4841 202.140.161.0/24 AS4841 202.140.162.0/24 AS4841 202.140.163.0/24 AS4841 202.140.164.0/24 AS4841 202.140.165.0/24 AS4841 202.140.166.0/24 AS4841 202.140.167.0/24 AS4841 202.140.168.0/24 AS4841 202.140.169.0/24 AS4841 202.140.170.0/24 AS4841 202.140.171.0/24 AS4841 202.140.172.0/24 AS4841 202.140.173.0/24 AS4841 202.140.174.0/24 AS4841 202.140.175.0/24 AS4841 202.140.180.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.140.181.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.140.182.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.150.227.0/24 AS17727 NAPINFO-AS-AP PT. NAP Info Lintas Nusa 202.181.32.0/24 AS4645 ASN-HKNET-AP HKNet Co. Ltd 203.12.45.0/24 AS4854 NETSPACE-AS-AP Netspace Online Systems 203.62.0.0/17 AS7575 AARNET-AS-AP Australian Academic and Reasearch Network (AARNet) 203.78.48.0/20 AS9299 IPG-AS-AP Philippine Long Distance Telephone Company 203.89.139.0/24 AS17911 BRAINPK-AS-AP Brain Telecommunication Ltd. 203.111.192.0/20 AS7473 SINGTEL-AS-AP Singapore Telecommunications Ltd 203.112.111.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.113.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.114.0/24 AS4802 ASN-IINET iiNet Limited 203.112.116.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.117.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.118.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.119.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.120.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.121.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.127.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.128.128.0/19 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 203.128.128.0/24 AS23849 CNNIC-NET263-AP Beijing Capital-online science development Co.,Ltd. 203.152.154.0/23 AS9583 SIFY-AS-IN Sify Limited 204.9.216.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.9.217.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.9.218.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.13.140.0/22 AS7270 NET2PHONE - Net2Phone Corp. 204.16.120.0/23 AS12077 204.16.122.0/23 AS12077 204.19.14.0/23 AS577 BACOM - Bell Canada 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.189.134.0/24 AS11814 CYBERSURF - Cybersurf Inc. 205.210.145.0/24 AS11814 CYBERSURF - Cybersurf Inc. 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 207.204.168.0/24 AS15150 BELLTECH-AS - BELLWETHER TECHNOLOGY CORPORATION 207.204.222.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 209.54.93.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 209.54.111.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 209.54.123.0/24 AS6062 NETPLEX - NETPLEX 209.54.240.0/21 AS10887 BPSI-AS - BPSI Internet Services 209.74.96.0/19 AS10912 INTERNAP-BLK - Internap Network Services Corporation 209.140.90.0/24 AS14461 NTSL - NET SOLUTIONS 209.140.224.0/21 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.234.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.235.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.236.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.237.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.238.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.239.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.141.16.0/21 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.141.48.0/22 AS14461 NTSL - NET SOLUTIONS 209.145.192.0/18 AS3043 AMPHIB-AS - Amphibian Media Corporation 209.222.5.0/24 AS26699 PSI-CT - Printing For Systems Inc 209.222.6.0/24 AS26699 PSI-CT - Printing For Systems Inc 209.236.64.0/19 AS7911 LVLT-7911 - Level 3 Communications, Inc. 209.236.96.0/19 AS7911 LVLT-7911 - Level 3 Communications, Inc. 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 216.37.114.0/23 AS3549 GBLX Global Crossing Ltd. 216.37.120.0/23 AS13377 216.99.16.0/24 AS6395 LVLT-6395 - Level 3 Communications, Inc. 216.99.20.0/24 AS6395 LVLT-6395 - Level 3 Communications, Inc. 216.172.198.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.172.199.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.210.86.0/24 AS577 BACOM - Bell Canada 216.240.240.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.240.241.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.240.242.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.251.207.0/24 AS1239 SPRINTLINK - Sprint 217.78.71.0/24 AS12491 IPPLANET-AS IPPlanet 217.78.72.0/24 AS12491 IPPLANET-AS IPPlanet 217.78.73.0/24 AS12491 IPPLANET-AS IPPlanet Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cscora at apnic.net Fri Mar 6 12:16:11 2009 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 7 Mar 2009 04:16:11 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <200903061816.n26IGBEW008416@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 07 Mar, 2009 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 282074 Prefixes after maximum aggregation: 133839 Deaggregation factor: 2.11 Unique aggregates announced to Internet: 138127 Total ASes present in the Internet Routing Table: 30765 Prefixes per ASN: 9.17 Origin-only ASes present in the Internet Routing Table: 26774 Origin ASes announcing only one prefix: 13039 Transit ASes present in the Internet Routing Table: 3991 Transit-only ASes present in the Internet Routing Table: 90 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 25 Max AS path prepend of ASN (18678) 21 Prefixes from unregistered ASNs in the Routing Table: 497 Unregistered ASNs in the Routing Table: 167 Number of 32-bit ASNs allocated by the RIRs: 116 Prefixes from 32-bit ASNs in the Routing Table: 18 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 216 Number of addresses announced to Internet: 2012808064 Equivalent to 119 /8s, 249 /16s and 3 /24s Percentage of available address space announced: 54.3 Percentage of allocated address space announced: 63.5 Percentage of available address space allocated: 85.5 Percentage of address space in use by end-sites: 76.0 Total number of prefixes smaller than registry allocations: 138822 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 65026 Total APNIC prefixes after maximum aggregation: 23342 APNIC Deaggregation factor: 2.79 Prefixes being announced from the APNIC address blocks: 61870 Unique aggregates announced from the APNIC address blocks: 28110 APNIC Region origin ASes present in the Internet Routing Table: 3557 APNIC Prefixes per ASN: 17.39 APNIC Region origin ASes announcing only one prefix: 961 APNIC Region transit ASes present in the Internet Routing Table: 543 Average APNIC Region AS path length visible: 3.5 Max APNIC Region AS path length visible: 17 Number of APNIC addresses announced to Internet: 405211808 Equivalent to 24 /8s, 39 /16s and 10 /24s Percentage of available APNIC address space announced: 80.5 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 APNIC Address Blocks 58/8, 59/8, 60/8, 61/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 124101 Total ARIN prefixes after maximum aggregation: 65393 ARIN Deaggregation factor: 1.90 Prefixes being announced from the ARIN address blocks: 93432 Unique aggregates announced from the ARIN address blocks: 36029 ARIN Region origin ASes present in the Internet Routing Table: 12837 ARIN Prefixes per ASN: 7.28 ARIN Region origin ASes announcing only one prefix: 4937 ARIN Region transit ASes present in the Internet Routing Table: 1239 Average ARIN Region AS path length visible: 3.3 Max ARIN Region AS path length visible: 20 Number of ARIN addresses announced to Internet: 417006400 Equivalent to 24 /8s, 219 /16s and 3 /24s Percentage of available ARIN address space announced: 80.2 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 ARIN Address Blocks 24/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 108/8, 173/8, 174/8, 184/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 64239 Total RIPE prefixes after maximum aggregation: 37596 RIPE Deaggregation factor: 1.71 Prefixes being announced from the RIPE address blocks: 58840 Unique aggregates announced from the RIPE address blocks: 39192 RIPE Region origin ASes present in the Internet Routing Table: 12763 RIPE Prefixes per ASN: 4.61 RIPE Region origin ASes announcing only one prefix: 6710 RIPE Region transit ASes present in the Internet Routing Table: 1929 Average RIPE Region AS path length visible: 4.0 Max RIPE Region AS path length visible: 22 Number of RIPE addresses announced to Internet: 390554912 Equivalent to 23 /8s, 71 /16s and 101 /24s Percentage of available RIPE address space announced: 83.1 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-49151 RIPE Address Blocks 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 178/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 23498 Total LACNIC prefixes after maximum aggregation: 5752 LACNIC Deaggregation factor: 4.09 Prefixes being announced from the LACNIC address blocks: 21672 Unique aggregates announced from the LACNIC address blocks: 11739 LACNIC Region origin ASes present in the Internet Routing Table: 1078 LACNIC Prefixes per ASN: 20.10 LACNIC Region origin ASes announcing only one prefix: 346 LACNIC Region transit ASes present in the Internet Routing Table: 178 Average LACNIC Region AS path length visible: 4.1 Max LACNIC Region AS path length visible: 25 Number of LACNIC addresses announced to Internet: 61303808 Equivalent to 3 /8s, 167 /16s and 108 /24s Percentage of available LACNIC address space announced: 60.9 LACNIC AS Blocks 26592-26623, 27648-28671, plus ERX transfers LACNIC Address Blocks 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 4746 Total AfriNIC prefixes after maximum aggregation: 1375 AfriNIC Deaggregation factor: 3.45 Prefixes being announced from the AfriNIC address blocks: 4456 Unique aggregates announced from the AfriNIC address blocks: 1334 AfriNIC Region origin ASes present in the Internet Routing Table: 284 AfriNIC Prefixes per ASN: 15.69 AfriNIC Region origin ASes announcing only one prefix: 85 AfriNIC Region transit ASes present in the Internet Routing Table: 58 Average AfriNIC Region AS path length visible: 4.0 Max AfriNIC Region AS path length visible: 15 Number of AfriNIC addresses announced to Internet: 10109184 Equivalent to 0 /8s, 154 /16s and 65 /24s Percentage of available AfriNIC address space announced: 30.1 AfriNIC AS Blocks 36864-37887 & ERX transfers AfriNIC Address Blocks 41/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 1689 6928 396 Korea Telecom (KIX) 17488 1527 119 96 Hathway IP Over Cable Interne 4755 1212 430 183 TATA Communications formerly 9583 1097 87 528 Sify Limited 4134 927 16271 367 CHINANET-BACKBONE 18101 750 198 29 Reliance Infocom Ltd Internet 7545 733 158 100 TPG Internet Pty Ltd 9498 690 297 51 BHARTI BT INTERNET LTD. 24560 675 228 174 Bharti Airtel Ltd. 9829 636 490 21 BSNL National Internet Backbo Complete listing at http://thyme.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 4363 3686 339 bellsouth.net, inc. 209 2837 4149 619 Qwest 4323 1780 1081 376 Time Warner Telecom 1785 1724 717 137 PaeTec Communications, Inc. 20115 1586 1429 718 Charter Communications 7018 1444 5880 1007 AT&T WorldNet Services 6478 1277 296 523 AT&T Worldnet Services 2386 1266 681 900 AT&T Data Communications Serv 11492 1191 192 12 Cable One 3356 1159 10976 444 Level 3 Communications, LLC Complete listing at http://thyme.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8452 1236 188 7 TEDATA 3292 444 1762 389 TDC Tele Danmark 30890 444 87 200 SC Kappa Invexim SRL 12479 402 578 6 Uni2 Autonomous System 3320 350 7081 293 Deutsche Telekom AG 3301 341 1685 306 TeliaNet Sweden 8866 337 109 22 Bulgarian Telecommunication C 3215 335 2986 104 France Telecom Transpac 29049 328 26 3 AzerSat LLC. 8551 313 288 40 Bezeq International Complete listing at http://thyme.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 1441 2831 230 UniNet S.A. de C.V. 10620 811 181 97 TVCABLE BOGOTA 11830 701 299 9 Instituto Costarricense de El 22047 608 302 14 VTR PUNTO NET S.A. 7303 515 257 79 Telecom Argentina Stet-France 16814 491 31 10 NSS, S.A. 6471 440 95 32 ENTEL CHILE S.A. 11172 406 118 74 Servicios Alestra S.A de C.V 7738 397 794 28 Telecomunicacoes da Bahia S.A 28573 378 506 23 NET Servicos de Comunicao S.A Complete listing at http://thyme.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 805 75 26 LINKdotNET AS number 20858 292 34 3 This AS will be used to conne 3741 271 857 229 The Internet Solution 2018 241 215 141 Tertiary Education Network 6713 159 150 15 Itissalat Al-MAGHRIB 33783 150 10 8 EEPAD TISP TELECOM & INTERNET 29571 130 15 8 Ci Telecom Autonomous system 5536 122 8 14 Internet Egypt Network 33776 118 6 3 Starcomms Nigeria Limited 5713 117 523 65 Telkom SA Ltd Complete listing at http://thyme.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 4363 3686 339 bellsouth.net, inc. 209 2837 4149 619 Qwest 4323 1780 1081 376 Time Warner Telecom 1785 1724 717 137 PaeTec Communications, Inc. 4766 1689 6928 396 Korea Telecom (KIX) 20115 1586 1429 718 Charter Communications 17488 1527 119 96 Hathway IP Over Cable Interne 7018 1444 5880 1007 AT&T WorldNet Services 8151 1441 2831 230 UniNet S.A. de C.V. 6478 1277 296 523 AT&T Worldnet Services Complete listing at http://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 209 2837 2218 Qwest 1785 1724 1587 PaeTec Communications, Inc. 17488 1527 1431 Hathway IP Over Cable Interne 4323 1780 1404 Time Warner Telecom 4766 1689 1293 Korea Telecom (KIX) 8452 1236 1229 TEDATA 8151 1441 1211 UniNet S.A. de C.V. 11492 1191 1179 Cable One 18566 1061 1051 Covad Communications 4755 1212 1029 TATA Communications formerly Complete listing at http://thyme.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 16927 UNALLOCATED 12.0.252.0/23 7018 AT&T WorldNet Servic 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 7018 AT&T WorldNet Servic 13746 UNALLOCATED 12.24.56.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.25.107.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.152.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.154.0/23 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.159.0/24 7018 AT&T WorldNet Servic 32326 UNALLOCATED 12.40.49.0/24 7018 AT&T WorldNet Servic 25639 UNALLOCATED 12.41.169.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 24.75.116.0/22 10796 ServiceCo LLC - Road Runner 24.75.160.0/19 7843 Adelphia Corp. 24.246.0.0/17 7018 AT&T WorldNet Services 24.246.128.0/18 7018 AT&T WorldNet Services 41.220.16.0/20 8668 TelOne Zimbabwe P/L 41.223.112.0/22 5713 Telkom SA Ltd 41.223.188.0/24 22351 Intelsat 41.223.189.0/24 26452 Local Communications Networks 62.61.220.0/24 24974 Tachyon Europe BV - Wireless 62.61.221.0/24 24974 Tachyon Europe BV - Wireless Complete listing at http://thyme.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:19 /9:10 /10:20 /11:55 /12:162 /13:319 /14:573 /15:1126 /16:10354 /17:4599 /18:7941 /19:16956 /20:20029 /21:19749 /22:25161 /23:25173 /24:147558 /25:702 /26:860 /27:584 /28:106 /29:8 /30:3 /31:0 /32:7 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2841 4363 bellsouth.net, inc. 209 1572 2837 Qwest 4766 1394 1689 Korea Telecom (KIX) 17488 1296 1527 Hathway IP Over Cable Interne 8452 1215 1236 TEDATA 11492 1148 1191 Cable One 1785 1131 1724 PaeTec Communications, Inc. 18566 1042 1061 Covad Communications 2386 959 1266 AT&T Data Communications Serv 9583 949 1097 Sify Limited Complete listing at http://thyme.apnic.net/current/data/sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 4:13 8:171 12:2199 13:2 15:20 16:3 17:4 20:35 24:1116 32:51 38:541 40:97 41:1966 43:1 44:2 47:19 52:3 55:2 56:3 57:25 58:534 59:623 60:460 61:1103 62:1102 63:2004 64:3537 65:2426 66:3546 67:1479 68:663 69:2493 70:510 71:157 72:1629 73:2 74:1431 75:201 76:310 77:811 78:564 79:325 80:969 81:847 82:555 83:420 84:590 85:1012 86:397 87:626 88:348 89:1389 90:42 91:2020 92:271 93:1159 94:1166 95:557 96:97 97:181 98:229 99:16 109:1 110:8 112:75 113:82 114:203 115:230 116:1120 117:493 118:287 119:601 120:133 121:706 122:965 123:542 124:941 125:1286 128:220 129:224 130:135 131:413 132:74 133:9 134:336 135:38 136:223 137:142 138:145 139:79 140:417 141:109 142:391 143:321 144:326 145:40 146:369 147:150 148:510 149:231 150:141 151:201 152:151 153:134 154:10 155:263 156:170 157:294 158:131 159:243 160:281 161:138 162:269 163:145 164:519 165:523 166:274 167:357 168:664 169:163 170:476 171:39 172:10 173:239 174:134 178:1 186:9 187:43 188:6 189:308 190:2680 192:5814 193:4219 194:3326 195:2714 196:1057 198:3713 199:3301 200:5483 201:1516 202:7794 203:8037 204:3776 205:2160 206:2347 207:2823 208:3880 209:3462 210:2641 211:1120 212:1493 213:1708 214:69 215:24 216:4558 217:1232 218:366 219:399 220:1204 221:341 222:316 End of report From jloiacon at csc.com Fri Mar 6 13:04:36 2009 From: jloiacon at csc.com (Joe Loiacono) Date: Fri, 6 Mar 2009 14:04:36 -0500 Subject: Usage-Based Billing for DIA In-Reply-To: Message-ID: I'd like to add: --flow-tools and FlowViewer ( http://ensight.eos.nasa.gov/FlowViewer ) Keeps max, mean, and 95th pct. for up to three years for any predefined customer (defined by a flow-tool filter and stored in RRDtool). Can group customers for visual comparison. Joe "Rodriguez, Mauricio" wrote on 03/05/2009 05:02:02 PM: > Looking at possibilities for an implementation of usage-based > billing, it seems that the same techniques and tools always come up. > I'm looking for some feedback from the list on experiences with > these tools and techniques as well as alternatives that may not be > listed here. > > +Techniques > --Flow data (Netflow, SFlow, etc) analysis to > determine 95th percentile traffic levels > --SNMP polling of interface counters to determine > 95th percentile traffic levels > > Granted, there are many interpretations of how to calculate "95th > percentile traffic levels" that may differ from provider to > provider. Assume that we have established the method that we will use. > > +Tools > --RTG > --MRTG > --Cacti > --solarwinds Orion > --Various, expensive PM tools such as Netcool > Proviso, JDSU NetComplete, InfoVista tools, etc > --flow-tools and FlowScan combo > --Arbor Networks Peakflow > > Any follow up to this thread, either on or off list, or pointers to > previous threads with good information would be appreciated! My > search didn't turn up any, but that doesn't mean that they don't exist! > > Thanks! > > Regards, > Mauricio Rodriguez > Manager of IP/Data Engineering, FPL FiberNet > Email: Mauricio.Rodriguez at fpl.com > From marc at ena.com Fri Mar 6 15:58:28 2009 From: marc at ena.com (Marc Powell) Date: Fri, 6 Mar 2009 15:58:28 -0600 Subject: Yahoo Mail Engineer Message-ID: Hello, Any Yahoo Mail engineers or techs on-list that can help an ISP identify the cause of 'Error 999' when accessing mail.yahoo.com (or escalate our current ticket)? I'm in an infinite loop with Tier 1 support (KMM86704582V3563L0KM). I suspect you may be flagging traffic volume from our web filtering proxies. Thanks! (yes, I tried mailop first). -- Marc Powell Senior Systems Engineer Education Networks of America From andy at nosignal.org Fri Mar 6 19:29:09 2009 From: andy at nosignal.org (Andy Davidson) Date: Sat, 7 Mar 2009 01:29:09 +0000 Subject: Usage-Based Billing for DIA In-Reply-To: References: Message-ID: <6D62221B-327F-4D7D-9EEF-BCDB5A40B407@nosignal.org> On 5 Mar 2009, at 22:02, Rodriguez, Mauricio wrote: > Looking at possibilities for an implementation of usage-based billing, [...] > +Techniques > --SNMP polling of interface counters to determine > 95th percentile traffic levels > +Tools > --RTG > --MRTG > --Cacti You can be pretty sure that there are probably a lot of billing systems based loosely around the tools mentioned here, and that in their particular environments they are robust enough to be successful. If you go down this route, or a similar route, you need to remember that you MUST update the default RRD storage behaviours so that the most granular data is not aggregated until four or five months after the billing month, otherwise you will find that the averaging causes different results to fall out of your scripts when you look into customer queries on their bill ! Best wishes Andy From jbfixurpc at gmail.com Fri Mar 6 19:36:47 2009 From: jbfixurpc at gmail.com (Joe Blanchard) Date: Fri, 6 Mar 2009 20:36:47 -0500 Subject: A new twist in email scams? Message-ID: <002101c99ec5$31572370$0101a8c0@E520> Sorry if I've missed some notes regarding this in previous threads, been off the air for a bit. A new twist on scamming email? I posted an ad to offer services in my area, got a rather odd email, obviously broken english typed, so proceeded cautiously. Someone in a foreign country wants my to install MSWindows, Office, and anti-virus bla bla.. So seems that he is wanting to send these items (5 laptops) to me for this installation. Ok, first thought scam. But I'll go ahead and play along. Seems he is adimit about paying me in advance for this work, as long as I can carry the check amount to pay the "shipper". Ok, well I'll be brave, send him some information, tracephone num etc. let see if this goes any where. Next email confirms hes got the info, will be sending details shortly. This sounds like a total scam, but is this a turn from the "5million dollars, you help me transfer" Nigerrian scan, looking to go after some of those folks wanting work? I am thinking so. Struck me as an odd situation. Sorry if this is off topic, but wondering how far this might go, (Can you configure my router/switch/firewall) and wanted to warn folks. Take Care, -Joe From ops.lists at gmail.com Fri Mar 6 19:47:23 2009 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Sat, 7 Mar 2009 07:17:23 +0530 Subject: A new twist in email scams? In-Reply-To: <002101c99ec5$31572370$0101a8c0@E520> References: <002101c99ec5$31572370$0101a8c0@E520> Message-ID: On Sat, Mar 7, 2009 at 7:06 AM, Joe Blanchard wrote: > Seems he is adimit about paying me in advance for this work, as long as I > can carry the check amount to pay the "shipper". Ok, well I'll be brave, > send him some information, tracephone num etc. let see if this goes any Reshipping scams are almost as old as the 'i'm the widow of a tinpot dictator' type scams srs From Billt at Mahagonny.com Fri Mar 6 20:03:24 2009 From: Billt at Mahagonny.com (Bill Thompson) Date: Fri, 6 Mar 2009 18:03:24 -0800 Subject: A new twist in email scams? In-Reply-To: <002101c99ec5$31572370$0101a8c0@E520> References: <002101c99ec5$31572370$0101a8c0@E520> Message-ID: <20090306180324.53f1f446@bebop.mahagonny.com> On Fri, 6 Mar 2009 20:36:47 -0500 "Joe Blanchard" wrote: > > Sorry if I've missed some notes regarding this in previous threads, > been off the air for a bit. > > A new twist on scamming email? > A) I don't think this really belongs on NANOG, but I don't want to leave you hanging. B) He is going to send you a check for over the amount of money you agreed on and then ask you to wire the overage back to him minus a small amount "For your trouble". Google "Overpayment Scam". Good Luck, -- Bill Thompson BillT at Mahagonny.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 272 bytes Desc: not available URL: From lorell at hathcock.org Fri Mar 6 23:58:02 2009 From: lorell at hathcock.org (Lorell Hathcock) Date: Fri, 6 Mar 2009 23:58:02 -0600 Subject: Wireless (Cell Phone) Interconnection Agreements and Equipment Message-ID: <007601c99ee9$ad917750$08b465f0$@org> I know this is off-topic, but can someone push me toward cell phone wireless interconnect lists or groups? Sincerely, Lorell Hathcock OfficeConnect.net | 832-665-3400 (o) | 713-992-2343 (f) | lorell at OfficeConnect.net ocbannerjoomla ONSSI Certified Channel Partner C1731 Axis Communications Channel Partner | BICSI Corporate Member Leviton Authorized Installer, Strategic Partner Program -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 7350 bytes Desc: not available URL: From msaqib at gmail.com Sat Mar 7 05:12:07 2009 From: msaqib at gmail.com (Saqib Ilyas) Date: Sat, 7 Mar 2009 16:12:07 +0500 Subject: Network SLA In-Reply-To: <4fff97de0902230019tce5e53q2ddb501171436dc@mail.gmail.com> References: <262b67200902190750m556cf72ve2ae25e4b64378e7@mail.gmail.com> <499DBE2A.6020907@gmail.com> <4fff97de0902230019tce5e53q2ddb501171436dc@mail.gmail.com> Message-ID: <262b67200903070312j55bded5dq26c978feb0b66441@mail.gmail.com> I must thank everyone who has answered my queries. Just a couple more short questions. For instance, if one is using MRTG, and wants to check if we can meet a 1 Mbps end-to-end throughput between a couple of customer sites, I believe you would need to use some traffic generator tools, because MRTG merely imports counters from routers and plots them. Is that correct? We've heard of the BRIX active measurement tool in replies to my earlier email. Also, I've found Cisco IP SLA that also sends traffic into the service provider network and measures performance. How many people really use IP SLA feature? Thanks and best regards On Mon, Feb 23, 2009 at 1:19 PM, Zartash Uzmi wrote: > As I gather, there is a mix of answers, ranging from "building the resources > according to requirements and HOPE for the best" to "use of arguably > sophisticated tools and perhaps sharing the results with the legal > department". > > I would be particularly interested in hearing the service providers' > viewpoint on the following situation. > > Consider a service provider with MPLS deployed within its own network. > > (A) When the SP enters into a relation with the customer, does the SP > establish new MPLS paths based on customer demands (this is perhaps similar > to "building" based on requirements as pointed out by David)? If yes, > between what sites/POPs? I assume the answer may be different depending upon > a single-site customer or a customer with multiple sites. > > (B) For entering into the relationship for providing X units of bandwidth > (to another site of same customer or to the Tier-1 backbone), does the SP > use any wisdom (in addition to MRTG and the likes)? If so, what scientific > parameters are kept in mind? > > (C) How does the customer figure out that a promise for X units of bandwidth > is maintained by the SP? I believe customers may install some measuring > tools but is that really the case in practice? > > Thanks, > Zartash > > On Fri, Feb 20, 2009 at 1:16 AM, Stefan wrote: > >> Saqib Ilyas wrote: >> >>> Greetings >>> I am curious to know about any tools/techniques that a service provider >>> uses >>> to assess an SLA before signing it. That is to say, how does an >>> administrator know if he/she can meet what he is promising. Is it based on >>> experience? Are there commonly used tools for this? >>> Thanks and best regards >>> >>> >> Not necessarily as a direct answer (I am pretty sure there'll be others on >> this list giving details in the area of specific tools and standards), but I >> think this may be a question (especially considering your end result >> concern: *signing the SLA!) equally applicable to your legal department. In >> the environment we live, nowadays, the SLA could (should?!? ... >> unfortunately) be "refined" and (at the other end - i.e. receiving) >> "interpreted" by the lawyers, with possibly equal effects (mostly financial >> and as overall impact on the business) as the tools we (the technical >> people) would be using to measure latency, uptime, bandwidth, jitter, etc... >> >> Stefan >> >> > -- Muhammad Saqib Ilyas PhD Student, Computer Science and Engineering Lahore University of Management Sciences From cmeidinger at sendmail.com Sat Mar 7 05:26:45 2009 From: cmeidinger at sendmail.com (Chris Meidinger) Date: Sat, 7 Mar 2009 12:26:45 +0100 Subject: Network SLA In-Reply-To: <262b67200903070312j55bded5dq26c978feb0b66441@mail.gmail.com> References: <262b67200902190750m556cf72ve2ae25e4b64378e7@mail.gmail.com> <499DBE2A.6020907@gmail.com> <4fff97de0902230019tce5e53q2ddb501171436dc@mail.gmail.com> <262b67200903070312j55bded5dq26c978feb0b66441@mail.gmail.com> Message-ID: <30F21D2E-8631-421A-80BE-5D078B2C841A@sendmail.com> Saqib, On 07.03.2009, at 12:12, Saqib Ilyas wrote: > I must thank everyone who has answered my queries. Just a couple more > short questions. > For instance, if one is using MRTG, and wants to check if we can meet > a 1 Mbps end-to-end throughput between a couple of customer sites, I > believe you would need to use some traffic generator tools, because > MRTG merely imports counters from routers and plots them. Is that > correct? Yes, if you want to do a test bandwidth, iperf should probably be your first stop. > We've heard of the BRIX active measurement tool in replies to my > earlier email. Also, I've found Cisco IP SLA that also sends traffic > into the service provider network and measures performance. How many > people really use IP SLA feature? I know a lot of people that use IPSLA. Remember, that you set it up between two routers or higher-end switches and it constantly tests that connection. However, IPSLA is the wrong tool for a one-off test of whether you can push a Mbps from site A to site B, because you need to saturate the link to do that test. IPSLA is great for monitoring things like jitter. HTH, Chris > Thanks and best regards > > On Mon, Feb 23, 2009 at 1:19 PM, Zartash Uzmi > wrote: >> As I gather, there is a mix of answers, ranging from "building the >> resources >> according to requirements and HOPE for the best" to "use of arguably >> sophisticated tools and perhaps sharing the results with the legal >> department". >> >> I would be particularly interested in hearing the service providers' >> viewpoint on the following situation. >> >> Consider a service provider with MPLS deployed within its own >> network. >> >> (A) When the SP enters into a relation with the customer, does the SP >> establish new MPLS paths based on customer demands (this is perhaps >> similar >> to "building" based on requirements as pointed out by David)? If yes, >> between what sites/POPs? I assume the answer may be different >> depending upon >> a single-site customer or a customer with multiple sites. >> >> (B) For entering into the relationship for providing X units of >> bandwidth >> (to another site of same customer or to the Tier-1 backbone), does >> the SP >> use any wisdom (in addition to MRTG and the likes)? If so, what >> scientific >> parameters are kept in mind? >> >> (C) How does the customer figure out that a promise for X units of >> bandwidth >> is maintained by the SP? I believe customers may install some >> measuring >> tools but is that really the case in practice? >> >> Thanks, >> Zartash >> >> On Fri, Feb 20, 2009 at 1:16 AM, Stefan wrote: >> >>> Saqib Ilyas wrote: >>> >>>> Greetings >>>> I am curious to know about any tools/techniques that a service >>>> provider >>>> uses >>>> to assess an SLA before signing it. That is to say, how does an >>>> administrator know if he/she can meet what he is promising. Is it >>>> based on >>>> experience? Are there commonly used tools for this? >>>> Thanks and best regards >>>> >>>> >>> Not necessarily as a direct answer (I am pretty sure there'll be >>> others on >>> this list giving details in the area of specific tools and >>> standards), but I >>> think this may be a question (especially considering your end result >>> concern: *signing the SLA!) equally applicable to your legal >>> department. In >>> the environment we live, nowadays, the SLA could (should?!? ... >>> unfortunately) be "refined" and (at the other end - i.e. receiving) >>> "interpreted" by the lawyers, with possibly equal effects (mostly >>> financial >>> and as overall impact on the business) as the tools we (the >>> technical >>> people) would be using to measure latency, uptime, bandwidth, >>> jitter, etc... >>> >>> Stefan >>> >>> >> > > > > -- > Muhammad Saqib Ilyas > PhD Student, Computer Science and Engineering > Lahore University of Management Sciences > From nanog-post at rsuc.gweep.net Sat Mar 7 15:21:00 2009 From: nanog-post at rsuc.gweep.net (Joe Provo) Date: Sat, 7 Mar 2009 16:21:00 -0500 Subject: Network SLA In-Reply-To: <30F21D2E-8631-421A-80BE-5D078B2C841A@sendmail.com> References: <262b67200902190750m556cf72ve2ae25e4b64378e7@mail.gmail.com> <499DBE2A.6020907@gmail.com> <4fff97de0902230019tce5e53q2ddb501171436dc@mail.gmail.com> <262b67200903070312j55bded5dq26c978feb0b66441@mail.gmail.com> <30F21D2E-8631-421A-80BE-5D078B2C841A@sendmail.com> Message-ID: <20090307212100.GA55070@gweep.net> On Sat, Mar 07, 2009 at 12:26:45PM +0100, Chris Meidinger wrote: > Saqib, > > On 07.03.2009, at 12:12, Saqib Ilyas wrote: > > >I must thank everyone who has answered my queries. Just a couple more > >short questions. > >For instance, if one is using MRTG, and wants to check if we can meet > >a 1 Mbps end-to-end throughput between a couple of customer sites, I > >believe you would need to use some traffic generator tools, because > >MRTG merely imports counters from routers and plots them. Is that > >correct? > > Yes, if you want to do a test bandwidth, iperf should probably be your > first stop. Or for more sophisticated matricies of spot-checks, BWCTL (http://www.nanog.org/meetings/nanog43/presentations/Boote_tools_N43.pdf) > >We've heard of the BRIX active measurement tool in replies to my > >earlier email. Also, I've found Cisco IP SLA that also sends traffic > >into the service provider network and measures performance. How many > >people really use IP SLA feature? > > I know a lot of people that use IPSLA. Remember, that you set it up > between two routers or higher-end switches and it constantly tests > that connection. However, IPSLA is the wrong tool for a one-off test > of whether you can push a Mbps from site A to site B, because you need > to saturate the link to do that test. IPSLA is great for monitoring > things like jitter. While Birx is awesome and a cisco-heavy site certainly should use rtr/ipsla in their mix, don't underestimate the value of a lightweight system built on smokeping (http://oss.oetiker.ch/smokeping/). Choose the right set of tools for your budget and environment. Cheers! Joe -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE From carlos at race.com Sat Mar 7 19:07:11 2009 From: carlos at race.com (Carlos Alcantar) Date: Sat, 7 Mar 2009 17:07:11 -0800 Subject: level3 out of san francisco Message-ID: <859604546CD1FF488BDB6EA94C896AFB593139@racexchange.race.local> Anyone else having level3 issues out of san Francisco ? -carlos From gohyk at singnet.com.sg Sun Mar 8 11:14:44 2009 From: gohyk at singnet.com.sg (Goh Yang Kwang) Date: Mon, 9 Mar 2009 00:14:44 +0800 Subject: TR69 References: <859604546CD1FF488BDB6EA94C896AFB5930CF@racexchange.race.local> Message-ID: <003301c9a008$fed2cc20$646b300a@sg.ibm.com> Hi, Does anyone know any free tool to monitor a CPE via TR69? Thanks! Regards, YK From jsw at inconcepts.biz Mon Mar 9 01:26:28 2009 From: jsw at inconcepts.biz (Jeff S Wheeler) Date: Mon, 09 Mar 2009 02:26:28 -0400 Subject: ALTDB.NET DNS? Message-ID: <1236579988.6854.354.camel@guardian.inconcepts.net> I notice the ALTDB.NET DNS has been updated, and WWW.ALTDB.NET goes to a GoDaddy "parked domain" landing page, and also, email bounces. Jacked? -- Jeff From jeremy at evilrouters.net Mon Mar 9 03:04:14 2009 From: jeremy at evilrouters.net (Jeremy Gaddis) Date: Mon, 9 Mar 2009 04:04:14 -0400 Subject: ALTDB.NET DNS? In-Reply-To: <1236579988.6854.354.camel@guardian.inconcepts.net> References: <1236579988.6854.354.camel@guardian.inconcepts.net> Message-ID: <8623d07f0903090104y8472758vc649d9c62f7aa7a@mail.gmail.com> On Mon, Mar 9, 2009 at 2:26 AM, Jeff S Wheeler wrote: > I notice the ALTDB.NET DNS has been updated, and WWW.ALTDB.NET goes to a > GoDaddy "parked domain" landing page, and also, email bounces. ?Jacked? $ whois altdb.net | grep Expiration Expiration Date: 08-mar-2009 -- Jeremy L. Gaddis http://evilrouters.net/ From ser at tch.org Mon Mar 9 04:25:20 2009 From: ser at tch.org (Steve Rubin) Date: Mon, 09 Mar 2009 02:25:20 -0700 Subject: ALTDB.NET DNS? In-Reply-To: <8623d07f0903090104y8472758vc649d9c62f7aa7a@mail.gmail.com> References: <1236579988.6854.354.camel@guardian.inconcepts.net> <8623d07f0903090104y8472758vc649d9c62f7aa7a@mail.gmail.com> Message-ID: <49B4E080.40203@tch.org> Jeremy Gaddis wrote: > On Mon, Mar 9, 2009 at 2:26 AM, Jeff S Wheeler wrote: >> I notice the ALTDB.NET DNS has been updated, and WWW.ALTDB.NET goes to a >> GoDaddy "parked domain" landing page, and also, email bounces. Jacked? > > $ whois altdb.net | grep Expiration > Expiration Date: 08-mar-2009 > Whoops. Sorry about that. It's been renewed. -- Steve Rubin / AE6CH / http://www.altdb.net/ Email: ser at tch.org / N6441C / http://www.tch.org/~ser/ From sam_mailinglists at spacething.org Mon Mar 9 04:30:14 2009 From: sam_mailinglists at spacething.org (Sam Stickland) Date: Mon, 09 Mar 2009 09:30:14 +0000 Subject: Usage-Based Billing for DIA In-Reply-To: References: Message-ID: <49B4E1A6.8040905@spacething.org> Jon Lewis wrote: > On Thu, 5 Mar 2009, Rodriguez, Mauricio wrote: > >> Looking at possibilities for an implementation of usage-based >> billing, it seems that the same techniques and tools always come up. >> I'm looking for some feedback from the list on experiences with these >> tools and techniques as well as alternatives that may not be listed >> here. >> >> +Techniques >> --Flow data (Netflow, SFlow, etc) analysis to >> determine 95th percentile traffic levels >> --SNMP polling of interface counters to determine 95th >> percentile traffic levels > > > I need to look into this in the near future as well. The problems I'm > aware of are: > > 1) we have customers on policed ports, and the interface snmp counters > count packets before service-policy. It doesn't seem right to bill > for packets we dropped :)...so this isn't useful data for billing > purposes. > Torrus (www.torrus.org) can use the Cisco MIBs to graph pre and post-policy packets. http://www.torrus.org/plugins/tp-cisco-cbqos.pod.html Sam From dholmes at mwdh2o.com Mon Mar 9 12:27:29 2009 From: dholmes at mwdh2o.com (Holmes,David A) Date: Mon, 9 Mar 2009 10:27:29 -0700 Subject: Network SLA In-Reply-To: <262b67200903070312j55bded5dq26c978feb0b66441@mail.gmail.com> References: <262b67200902190750m556cf72ve2ae25e4b64378e7@mail.gmail.com><499DBE2A.6020907@gmail.com><4fff97de0902230019tce5e53q2ddb501171436dc@mail.gmail.com> <262b67200903070312j55bded5dq26c978feb0b66441@mail.gmail.com> Message-ID: <485ED9BA02629E4BBBA53AC892EDA50E08851696@usmsxt104.mwd.h2o> We use BRIX for SLA's by measuring round trip times, jitter, and packet loss across all of our backbone links. In conjunction with a traffic generator to add background traffic, and potentially invoke queueing on interfaces, we have found that BRIX enables us to accurately predict the behavior of new applications, particularly multicast and HD video, without the need to implement elaborate QoS configurations. BRIX is now owned by EXFO, a fiber optic test equipment manufacturer. Low values for rtt, jitter, and packet loss imply a relatively queue-free network, which makes confident predictions about network behavior easier. When we last looked at the technology, the Cisco IP SLA probes did not capture a random distribution of network events, as the probes are triggered every N minutes. BRIX randomizes the probes within a configurable window, so that, over time, all time intervals are covered by the accumulated probes. -----Original Message----- From: Saqib Ilyas [mailto:msaqib at gmail.com] Sent: Saturday, March 07, 2009 3:12 AM To: nanog at nanog.org Subject: Re: Network SLA I must thank everyone who has answered my queries. Just a couple more short questions. For instance, if one is using MRTG, and wants to check if we can meet a 1 Mbps end-to-end throughput between a couple of customer sites, I believe you would need to use some traffic generator tools, because MRTG merely imports counters from routers and plots them. Is that correct? We've heard of the BRIX active measurement tool in replies to my earlier email. Also, I've found Cisco IP SLA that also sends traffic into the service provider network and measures performance. How many people really use IP SLA feature? Thanks and best regards On Mon, Feb 23, 2009 at 1:19 PM, Zartash Uzmi wrote: > As I gather, there is a mix of answers, ranging from "building the resources > according to requirements and HOPE for the best" to "use of arguably > sophisticated tools and perhaps sharing the results with the legal > department". > > I would be particularly interested in hearing the service providers' > viewpoint on the following situation. > > Consider a service provider with MPLS deployed within its own network. > > (A) When the SP enters into a relation with the customer, does the SP > establish new MPLS paths based on customer demands (this is perhaps similar > to "building" based on requirements as pointed out by David)? If yes, > between what sites/POPs? I assume the answer may be different depending upon > a single-site customer or a customer with multiple sites. > > (B) For entering into the relationship for providing X units of bandwidth > (to another site of same customer or to the Tier-1 backbone), does the SP > use any wisdom (in addition to MRTG and the likes)? If so, what scientific > parameters are kept in mind? > > (C) How does the customer figure out that a promise for X units of bandwidth > is maintained by the SP? I believe customers may install some measuring > tools but is that really the case in practice? > > Thanks, > Zartash > > On Fri, Feb 20, 2009 at 1:16 AM, Stefan wrote: > >> Saqib Ilyas wrote: >> >>> Greetings >>> I am curious to know about any tools/techniques that a service provider >>> uses >>> to assess an SLA before signing it. That is to say, how does an >>> administrator know if he/she can meet what he is promising. Is it based on >>> experience? Are there commonly used tools for this? >>> Thanks and best regards >>> >>> >> Not necessarily as a direct answer (I am pretty sure there'll be others on >> this list giving details in the area of specific tools and standards), but I >> think this may be a question (especially considering your end result >> concern: *signing the SLA!) equally applicable to your legal department. In >> the environment we live, nowadays, the SLA could (should?!? ... >> unfortunately) be "refined" and (at the other end - i.e. receiving) >> "interpreted" by the lawyers, with possibly equal effects (mostly financial >> and as overall impact on the business) as the tools we (the technical >> people) would be using to measure latency, uptime, bandwidth, jitter, etc... >> >> Stefan >> >> > -- Muhammad Saqib Ilyas PhD Student, Computer Science and Engineering Lahore University of Management Sciences From charles at thewybles.com Mon Mar 9 12:37:08 2009 From: charles at thewybles.com (Charles Wyble) Date: Mon, 09 Mar 2009 10:37:08 -0700 Subject: Network SLA In-Reply-To: <485ED9BA02629E4BBBA53AC892EDA50E08851696@usmsxt104.mwd.h2o> References: <262b67200902190750m556cf72ve2ae25e4b64378e7@mail.gmail.com><499DBE2A.6020907@gmail.com><4fff97de0902230019tce5e53q2ddb501171436dc@mail.gmail.com> <262b67200903070312j55bded5dq26c978feb0b66441@mail.gmail.com> <485ED9BA02629E4BBBA53AC892EDA50E08851696@usmsxt104.mwd.h2o> Message-ID: <49B553C4.20304@thewybles.com> What products/services do you use for traffic generation? Also what sort of testing methodology do you use? As for random probes that certainly seems like a nice feature. Holmes,David A wrote: > We use BRIX for SLA's by measuring round trip times, jitter, and packet > loss across all of our backbone links. In conjunction with a traffic > generator to add background traffic, and potentially invoke queueing on > interfaces, we have found that BRIX enables us to accurately predict the > behavior of new applications, particularly multicast and HD video, > without the need to implement elaborate QoS configurations. BRIX is now > owned by EXFO, a fiber optic test equipment manufacturer. Low values for > rtt, jitter, and packet loss imply a relatively queue-free network, > which makes confident predictions about network behavior easier. > When we last looked at the technology, the Cisco IP SLA probes did not > capture a random distribution of network events, as the probes are > triggered every N minutes. BRIX randomizes the probes within a > configurable window, so that, over time, all time intervals are covered > by the accumulated probes. > > -- Charles N Wyble charles at thewybles.com (818)280-7059 http://charlesnw.blogspot.com CTO SocalWiFI.net From stefan at csudsu.com Tue Mar 10 11:05:19 2009 From: stefan at csudsu.com (Stefan Molnar) Date: Tue, 10 Mar 2009 08:05:19 -0800 (PST) Subject: XO peering. In-Reply-To: <1236579988.6854.354.camel@guardian.inconcepts.net> References: <1236579988.6854.354.camel@guardian.inconcepts.net> Message-ID: <20090310080212.K18723@clockwork> There was a peering issue in San Jose with XO, that impacted our operations this morning. But looks like a side effect is after the hand off to NTT. Anyone who has an XO link can reach areas insdie NTT? As an example our route to Salesforce /21 is via NTT and it is not happy right now. Thanks, Stefan From ops.lists at gmail.com Tue Mar 10 11:18:34 2009 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Tue, 10 Mar 2009 21:48:34 +0530 Subject: XO peering. In-Reply-To: <20090310080212.K18723@clockwork> References: <1236579988.6854.354.camel@guardian.inconcepts.net> <20090310080212.K18723@clockwork> Message-ID: On Tue, Mar 10, 2009 at 9:35 PM, Stefan Molnar wrote: > There was a peering issue in San Jose with XO, that impacted our operations > this morning. ?But looks like a side effect is after the hand off to NTT. > Anyone who has an XO link can reach areas insdie NTT? > As an example our route to Salesforce /21 is via NTT and it is not happy > right now. This is from a host in XO AS2828 I can reach, for example, www.verio.net 204.202.20.3 / AS2914 NTT-COMMUNICATIONS-2914 just fine. www.salesforce.com is also reachable, through NTT -- Suresh Ramasubramanian (ops.lists at gmail.com) From jmartinez at zero11.com Tue Mar 10 11:23:03 2009 From: jmartinez at zero11.com (John Martinez) Date: Tue, 10 Mar 2009 09:23:03 -0700 Subject: XO peering. In-Reply-To: <20090310080212.K18723@clockwork> References: <1236579988.6854.354.camel@guardian.inconcepts.net> <20090310080212.K18723@clockwork> Message-ID: <49B693E7.7020006@zero11.com> We saw an issue with Level 3 hand off to XO in Chicago. Stefan Molnar wrote: > > There was a peering issue in San Jose with XO, that impacted our > operations this morning. But looks like a side effect is after the hand > off to NTT. > > Anyone who has an XO link can reach areas insdie NTT? > > As an example our route to Salesforce /21 is via NTT and it is not happy > right now. > > Thanks, > Stefan > From jake at nobistech.net Tue Mar 10 11:34:02 2009 From: jake at nobistech.net (Jake Mertel) Date: Tue, 10 Mar 2009 11:34:02 -0500 Subject: XO peering. In-Reply-To: <49B693E7.7020006@zero11.com> References: <1236579988.6854.354.camel@guardian.inconcepts.net> <20090310080212.K18723@clockwork> <49B693E7.7020006@zero11.com> Message-ID: <18DCD1A1EB78DF41B564964698425DE201AF71BD25@srv372.exchange.nobistech.net> We had a number of issues in the Seattle area this morning, seemed to be isolated to traffic transiting via Level 3. We were forced to turn off the connection, and it's still disabled until we get an update from XO. -- Regards, Jake Mertel Nobis Technology Group, L.L.C. Web: http://www.nobistech.net/ Phone: (312) 281-5101 ext. 401 Fax: (808) 356-0417 Mail: 201 West Olive Street Second Floor, Suite 2B Bloomington, IL 61701 -----Original Message----- From: John Martinez [mailto:jmartinez at zero11.com] Sent: Tuesday, March 10, 2009 11:23 AM To: nanog at nanog.org Subject: Re: XO peering. We saw an issue with Level 3 hand off to XO in Chicago. Stefan Molnar wrote: > > There was a peering issue in San Jose with XO, that impacted our > operations this morning. But looks like a side effect is after the hand > off to NTT. > > Anyone who has an XO link can reach areas insdie NTT? > > As an example our route to Salesforce /21 is via NTT and it is not happy > right now. > > Thanks, > Stefan > From jmartinez at zero11.com Tue Mar 10 11:39:30 2009 From: jmartinez at zero11.com (John Martinez) Date: Tue, 10 Mar 2009 09:39:30 -0700 Subject: XO peering. In-Reply-To: <18DCD1A1EB78DF41B564964698425DE201AF71BD25@srv372.exchange.nobistech.net> References: <1236579988.6854.354.camel@guardian.inconcepts.net> <20090310080212.K18723@clockwork> <49B693E7.7020006@zero11.com> <18DCD1A1EB78DF41B564964698425DE201AF71BD25@srv372.exchange.nobistech.net> Message-ID: <49B697C2.7090304@zero11.com> Do you have the XO ticket number? Jake Mertel wrote: > We had a number of issues in the Seattle area this morning, seemed to be isolated to traffic transiting via Level 3. We were forced to turn off the connection, and it's still disabled until we get an update from XO. > > > -- > Regards, > > Jake Mertel > Nobis Technology Group, L.L.C. > > > > Web: http://www.nobistech.net/ > Phone: (312) 281-5101 ext. 401 > Fax: (808) 356-0417 > > Mail: 201 West Olive Street > Second Floor, Suite 2B > Bloomington, IL 61701 > > > -----Original Message----- > From: John Martinez [mailto:jmartinez at zero11.com] > Sent: Tuesday, March 10, 2009 11:23 AM > To: nanog at nanog.org > Subject: Re: XO peering. > > We saw an issue with Level 3 hand off to XO in Chicago. > > Stefan Molnar wrote: >> There was a peering issue in San Jose with XO, that impacted our >> operations this morning. But looks like a side effect is after the hand >> off to NTT. >> >> Anyone who has an XO link can reach areas insdie NTT? >> >> As an example our route to Salesforce /21 is via NTT and it is not happy >> right now. >> >> Thanks, >> Stefan >> > > > From EMort at xo.com Tue Mar 10 11:41:19 2009 From: EMort at xo.com (Mort, Eric) Date: Tue, 10 Mar 2009 11:41:19 -0500 Subject: XO peering. In-Reply-To: <18DCD1A1EB78DF41B564964698425DE201AF71BD25@srv372.exchange.nobistech.net> References: <1236579988.6854.354.camel@guardian.inconcepts.net><20090310080212.K18723@clockwork> <49B693E7.7020006@zero11.com> <18DCD1A1EB78DF41B564964698425DE201AF71BD25@srv372.exchange.nobistech.net> Message-ID: <2E209CF1536C0C42A260E215DA598E9606373D4B@TXPLANMAIL02.mail.inthosts.net> We had some hardware issues in San Jose which triggered some other ugliness. We believe we have the issues mitigated at this time. Folks still seeing issues are encouraged to hit me up offline. Thanks, Eric J. Mort XO Communications Sr. Manager - IP Operations Desk - 314-787-7826 Cell - 314.486-9057 emort at xo.com -----Original Message----- From: Jake Mertel [mailto:jake at nobistech.net] Sent: Tuesday, March 10, 2009 11:34 AM To: John Martinez; nanog at nanog.org Subject: RE: XO peering. We had a number of issues in the Seattle area this morning, seemed to be isolated to traffic transiting via Level 3. We were forced to turn off the connection, and it's still disabled until we get an update from XO. -- Regards, Jake Mertel Nobis Technology Group, L.L.C. Web: http://www.nobistech.net/ Phone: (312) 281-5101 ext. 401 Fax: (808) 356-0417 Mail: 201 West Olive Street Second Floor, Suite 2B Bloomington, IL 61701 -----Original Message----- From: John Martinez [mailto:jmartinez at zero11.com] Sent: Tuesday, March 10, 2009 11:23 AM To: nanog at nanog.org Subject: Re: XO peering. We saw an issue with Level 3 hand off to XO in Chicago. Stefan Molnar wrote: > > There was a peering issue in San Jose with XO, that impacted our > operations this morning. But looks like a side effect is after the hand > off to NTT. > > Anyone who has an XO link can reach areas insdie NTT? > > As an example our route to Salesforce /21 is via NTT and it is not happy > right now. > > Thanks, > Stefan > From stefan at csudsu.com Tue Mar 10 11:42:21 2009 From: stefan at csudsu.com (Stefan Molnar) Date: Tue, 10 Mar 2009 08:42:21 -0800 (PST) Subject: XO peering. In-Reply-To: References: <1236579988.6854.354.camel@guardian.inconcepts.net> <20090310080212.K18723@clockwork> Message-ID: <20090310084159.N18723@clockwork> It just cleared up for me. Nice to have a call center complain constantly. Thanks On Tue, 10 Mar 2009, Suresh Ramasubramanian wrote: > On Tue, Mar 10, 2009 at 9:35 PM, Stefan Molnar wrote: >> There was a peering issue in San Jose with XO, that impacted our operations >> this morning. ?But looks like a side effect is after the hand off to NTT. >> Anyone who has an XO link can reach areas insdie NTT? >> As an example our route to Salesforce /21 is via NTT and it is not happy >> right now. > > This is from a host in XO AS2828 > > I can reach, for example, www.verio.net 204.202.20.3 / AS2914 > NTT-COMMUNICATIONS-2914 just fine. > > www.salesforce.com is also reachable, through NTT > > -- > Suresh Ramasubramanian (ops.lists at gmail.com) > > From chris at chrisserafin.com Tue Mar 10 13:18:44 2009 From: chris at chrisserafin.com (ChrisSerafin) Date: Tue, 10 Mar 2009 13:18:44 -0500 Subject: XO peering. In-Reply-To: <20090310084159.N18723@clockwork> References: <1236579988.6854.354.camel@guardian.inconcepts.net> <20090310080212.K18723@clockwork> <20090310084159.N18723@clockwork> Message-ID: <49B6AF04.3070803@chrisserafin.com> Our office has XO, and sent an email out complainging about Salesforce.....In Chicago. --chris Stefan Molnar wrote: > > It just cleared up for me. Nice to have a call center complain > constantly. > > Thanks > > On Tue, 10 Mar 2009, Suresh Ramasubramanian wrote: > >> On Tue, Mar 10, 2009 at 9:35 PM, Stefan Molnar >> wrote: >>> There was a peering issue in San Jose with XO, that impacted our >>> operations >>> this morning. But looks like a side effect is after the hand off to >>> NTT. >>> Anyone who has an XO link can reach areas insdie NTT? >>> As an example our route to Salesforce /21 is via NTT and it is not >>> happy >>> right now. >> >> This is from a host in XO AS2828 >> >> I can reach, for example, www.verio.net 204.202.20.3 / AS2914 >> NTT-COMMUNICATIONS-2914 just fine. >> >> www.salesforce.com is also reachable, through NTT >> >> -- >> Suresh Ramasubramanian (ops.lists at gmail.com) >> >> > ------------------------------------------------------------------------ > > > No virus found in this incoming message. > Checked by AVG - www.avg.com > Version: 8.0.237 / Virus Database: 270.11.9/1993 - Release Date: 03/10/09 07:19:00 > > From oberman at es.net Tue Mar 10 14:40:51 2009 From: oberman at es.net (Kevin Oberman) Date: Tue, 10 Mar 2009 12:40:51 -0700 Subject: XO peering. In-Reply-To: <2E209CF1536C0C42A260E215DA598E9606373D4B@TXPLANMAIL02.mail.inthosts.net> References: <1236579988.6854.354.camel@guardian.inconcepts.net> <20090310080212.K18723@clockwork> <49B693E7.7020006@zero11.com> <18DCD1A1EB78DF41B564964698425DE201AF71BD25@srv372.exchange.nobistech.net> <2E209CF1536C0C42A260E215DA598E9606373D4B@TXPLANMAIL02.mail.inthosts.net> Message-ID: <1236714051.86405.2.camel@slan.es.net> On Tue, 2009-03-10 at 11:41 -0500, Mort, Eric wrote: > We had some hardware issues in San Jose which triggered some other > ugliness. We believe we have the issues mitigated at this time. Folks > still seeing issues are encouraged to hit me up offline. > > Thanks, > > Eric J. Mort > XO Communications > Sr. Manager - IP Operations > Desk - 314-787-7826 > Cell - 314.486-9057 > emort at xo.com > > > -----Original Message----- > From: Jake Mertel [mailto:jake at nobistech.net] > Sent: Tuesday, March 10, 2009 11:34 AM > To: John Martinez; nanog at nanog.org > Subject: RE: XO peering. > > We had a number of issues in the Seattle area this morning, seemed to be > isolated to traffic transiting via Level 3. We were forced to turn off > the connection, and it's still disabled until we get an update from XO. > > > -- > Regards, > > Jake Mertel > Nobis Technology Group, L.L.C. > > > > Web: http://www.nobistech.net/ > Phone: (312) 281-5101 ext. 401 > Fax: (808) 356-0417 > > Mail: 201 West Olive Street > Second Floor, Suite 2B > Bloomington, IL 61701 > > > -----Original Message----- > From: John Martinez [mailto:jmartinez at zero11.com] > Sent: Tuesday, March 10, 2009 11:23 AM > To: nanog at nanog.org > Subject: Re: XO peering. > > We saw an issue with Level 3 hand off to XO in Chicago. > > Stefan Molnar wrote: > > > > There was a peering issue in San Jose with XO, that impacted our > > operations this morning. But looks like a side effect is after the > hand > > off to NTT. > > > > Anyone who has an XO link can reach areas insdie NTT? > > > > As an example our route to Salesforce /21 is via NTT and it is not > happy > > right now. > > > > Thanks, > > Stefan > > > > > > > > > No joy from our (AS293) perspective. I still see traffic to XO at SJ black-holed. eqx-sj-rt1-re1> traceroute 198.17.75.45 traceroute to 198.17.75.45 (198.17.75.45), 30 hops max, 40 byte packets ^C Works fine from Ashburn, though. I've pref'ed XO down at SJ until it is working again. -- R. Kevin Oberman Energy Sciences Network (ESnet) Ernest Orlando Lawrence Berkeley National Laboratory (Berkeley Lab) E-Mail: oberman at es.net Phone: +1 510-486-8634 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 196 bytes Desc: This is a digitally signed message part URL: From jake at nobistech.net Tue Mar 10 16:18:53 2009 From: jake at nobistech.net (Jake Mertel) Date: Tue, 10 Mar 2009 16:18:53 -0500 Subject: XO peering. In-Reply-To: <1236714051.86405.2.camel@slan.es.net> References: <1236579988.6854.354.camel@guardian.inconcepts.net> <20090310080212.K18723@clockwork> <49B693E7.7020006@zero11.com> <18DCD1A1EB78DF41B564964698425DE201AF71BD25@srv372.exchange.nobistech.net> <2E209CF1536C0C42A260E215DA598E9606373D4B@TXPLANMAIL02.mail.inthosts.net> <1236714051.86405.2.camel@slan.es.net> Message-ID: <18DCD1A1EB78DF41B564964698425DE201AF71BD3A@srv372.exchange.nobistech.net> I did some preliminary tests static-routing some prefixes that were not working earlier over our XO connection and everything seemed fine. I went ahead and turned the session back up, no reports of trouble yet. I'll update if we have any issues. -- Regards, Jake Mertel Nobis Technology Group, L.L.C. Web: http://www.nobistech.net/ Phone: (312) 281-5101 ext. 401 Fax: (808) 356-0417 Mail: 201 West Olive Street Second Floor, Suite 2B Bloomington, IL 61701 -----Original Message----- From: Kevin Oberman [mailto:oberman at es.net] Sent: Tuesday, March 10, 2009 2:41 PM To: Mort, Eric Cc: Jake Mertel; John Martinez; nanog at nanog.org Subject: RE: XO peering. On Tue, 2009-03-10 at 11:41 -0500, Mort, Eric wrote: > We had some hardware issues in San Jose which triggered some other > ugliness. We believe we have the issues mitigated at this time. > Folks still seeing issues are encouraged to hit me up offline. > > Thanks, > > Eric J. Mort > XO Communications > Sr. Manager - IP Operations > Desk - 314-787-7826 > Cell - 314.486-9057 > emort at xo.com > > > -----Original Message----- > From: Jake Mertel [mailto:jake at nobistech.net] > Sent: Tuesday, March 10, 2009 11:34 AM > To: John Martinez; nanog at nanog.org > Subject: RE: XO peering. > > We had a number of issues in the Seattle area this morning, seemed to > be isolated to traffic transiting via Level 3. We were forced to turn > off the connection, and it's still disabled until we get an update from XO. > > > -- > Regards, > > Jake Mertel > Nobis Technology Group, L.L.C. > > > > Web: http://www.nobistech.net/ > Phone: (312) 281-5101 ext. 401 > Fax: (808) 356-0417 > > Mail: 201 West Olive Street > Second Floor, Suite 2B > Bloomington, IL 61701 > > > -----Original Message----- > From: John Martinez [mailto:jmartinez at zero11.com] > Sent: Tuesday, March 10, 2009 11:23 AM > To: nanog at nanog.org > Subject: Re: XO peering. > > We saw an issue with Level 3 hand off to XO in Chicago. > > Stefan Molnar wrote: > > > > There was a peering issue in San Jose with XO, that impacted our > > operations this morning. But looks like a side effect is after the > hand > > off to NTT. > > > > Anyone who has an XO link can reach areas insdie NTT? > > > > As an example our route to Salesforce /21 is via NTT and it is not > happy > > right now. > > > > Thanks, > > Stefan > > > > > > > > > No joy from our (AS293) perspective. I still see traffic to XO at SJ black-holed. eqx-sj-rt1-re1> traceroute 198.17.75.45 traceroute to 198.17.75.45 (198.17.75.45), 30 hops max, 40 byte packets ^C Works fine from Ashburn, though. I've pref'ed XO down at SJ until it is working again. -- R. Kevin Oberman Energy Sciences Network (ESnet) Ernest Orlando Lawrence Berkeley National Laboratory (Berkeley Lab) E-Mail: oberman at es.net Phone: +1 510-486-8634 From tim at tetro.net Tue Mar 10 18:01:58 2009 From: tim at tetro.net (Tim Utschig) Date: Tue, 10 Mar 2009 16:01:58 -0700 Subject: Redundant Array of Inexpensive ISP's? Message-ID: <20090310230158.GA19876@tetro.net> [Please reply off-list. I'll summarize back to the list if there is more than a little interest in me doing so.] I'm curious if anyone has experience with products from Talari Networks, or anything similar, and would like to share. Did they live up to your expectations? Caveats? -- - Tim Utschig From charles at thewybles.com Tue Mar 10 18:26:22 2009 From: charles at thewybles.com (Charles Wyble) Date: Tue, 10 Mar 2009 16:26:22 -0700 Subject: Redundant Array of Inexpensive ISP's? In-Reply-To: <20090310230158.GA19876@tetro.net> References: <20090310230158.GA19876@tetro.net> Message-ID: <49B6F71E.5070804@thewybles.com> This seems similiar to Cisco performance routing. See http://www.cisco.com/en/US/products/ps8787/products_ios_protocol_option_home.html for more. Tim Utschig wrote: > Talari > Networks -- Charles N Wyble charles at thewybles.com (818)280-7059 http://charlesnw.blogspot.com CTO SocalWiFI.net From jasondearborn at gmail.com Tue Mar 10 18:45:52 2009 From: jasondearborn at gmail.com (Jason Dearborn) Date: Tue, 10 Mar 2009 16:45:52 -0700 Subject: Redundant Array of Inexpensive ISP's? In-Reply-To: <20090310230158.GA19876@tetro.net> References: <20090310230158.GA19876@tetro.net> Message-ID: <4296d7270903101645v4d6b119fp512858e279b76c15@mail.gmail.com> Good question. I'm also curious if anyone has experience with the Mushroom BBNA device and how it compares to Talari. Due to various premises and telco issues, I've been unable to get anything faster than a DSL connection pulled into a certain branch office. I'm considering any and every alternative at this point. On Tue, Mar 10, 2009 at 4:01 PM, Tim Utschig wrote: > > [Please reply off-list. ?I'll summarize back to the list if there > is more than a little interest in me doing so.] > > I'm curious if anyone has experience with products from Talari > Networks, or anything similar, and would like to share. ?Did they > live up to your expectations? ?Caveats? > > -- > ? - Tim Utschig > > From dholmes at mwdh2o.com Tue Mar 10 19:19:39 2009 From: dholmes at mwdh2o.com (Holmes,David A) Date: Tue, 10 Mar 2009 17:19:39 -0700 Subject: Redundant Array of Inexpensive ISP's? In-Reply-To: <20090310230158.GA19876@tetro.net> References: <20090310230158.GA19876@tetro.net> Message-ID: <485ED9BA02629E4BBBA53AC892EDA50E08901FC4@usmsxt104.mwd.h2o> The Talari device appears to operate like the old Routescience Pathcontrol BGP load balancer circa 2002 (Routescience is now owned by Avaya I believe). Routescience was able to compile the best path to Internet BGP prefixes so that a web site could connect to multiple 2nd tier ISPs (for circuit cost and redundancy reasons), and control the Mbps traffic over the best path, irrespective of the BGP feed supplied by the upstream ISP. In my experience devices such as Routescience automated the tedious work of using CAIDA tools to manually calculate the best BGP path to destination prefixes, and eliminated the almost daily reconfiguration of BGP route maps on Internet border routers. Routescience was a great product that put dashboard BGP routing control in the hands of the network engineer, and saved MRC circuit costs to pay for itself within a few months. -----Original Message----- From: Tim Utschig [mailto:tim at tetro.net] Sent: Tuesday, March 10, 2009 4:02 PM To: nanog at nanog.org Subject: Redundant Array of Inexpensive ISP's? [Please reply off-list. I'll summarize back to the list if there is more than a little interest in me doing so.] I'm curious if anyone has experience with products from Talari Networks, or anything similar, and would like to share. Did they live up to your expectations? Caveats? -- - Tim Utschig From rveloso at CS.UCLA.EDU Wed Mar 11 01:03:03 2009 From: rveloso at CS.UCLA.EDU (Ricardo Oliveira) Date: Tue, 10 Mar 2009 23:03:03 -0700 Subject: Cyclops: an open eye to your network (beta release) Message-ID: Hi, Just to let you know about Cyclops (beta for now), a tool for topology visibility and real-time routing anomaly detection/alerting for service providers and enterprise networks. Cyclops uses real time data from hundreds of vantage points of route-views, ripe-ris, packet clearing house and Univ. of Colorado bgpmon to assess how the rest of the world is reaching your network. Cyclops features include: - real-time alerting of prefix hijacks and misconfigured announcements - alerting of next-hop changes, AS in the middle (transit) and new prefix - alerting of new AS neighbor (false link announcement/leakages) - Global visibility on AS connectivity and prefix origins - Monitoring of routes to critical infrastructure, e.g. DNS TLDs - Anomaly listings (anomalous depeerings, bogus ASNs, bogon prefixes, long/short prefixes) To register for Cyclops please visit: http://cyclops.cs.ucla.edu/?l=reg To start configuring your network go to: http://cyclops.cs.ucla.edu/?v=ma&tab=1 (need to be logged in) You need to tell cyclops what are your prefixes, your ASNes and your neighbor ASNs. Please do not hesitate to contact me in case you have questions/ comments/bug reports. Thanks for being a Cycloper! --Ricardo In name of the Cyclops Team From brett at wrl.org Wed Mar 11 08:34:18 2009 From: brett at wrl.org (Brett Charbeneau) Date: Wed, 11 Mar 2009 09:34:18 -0400 (EDT) Subject: Dynamic IP log retention = 0? Message-ID: I've been nudging an operator at Covad about a handful of hosts from his DHCP pool that have been attacking - relentlessly port scanning - our assets. I've been informed by this individual that there's "no way" to determine which customer had that address at the times I list in my logs - even though these logs are sent within 48 hours of the incidents. The operator advised that I block the specific IP's that are attacking us at my perimeter. When I mentioned the fact that blocking individual addresses will only be as effective as the length of lease for that DHCP pool I get the email equivalent of a shrug. "Well, maybe you want to ban our entire /15 at your perimeter..." I'm reluctant to ban over 65,000 hosts as my staff have colleagues all over the continental US with whom they communicate regularly. I realize these are tough times and that large ISP's may trim abuse team budgets before other things, but to have NO MECHANISM to audit who has what address at any given time kinda blows my mind. Does one have to get to the level of a subpoena before abuse teams pull out the tools they need to make such a determination? Or am I naive enough to think port scans are as important to them as they are to me on the receiving end? -- ******************************************************************** Brett Charbeneau, GSEC Gold, GCIH Gold Network Administrator Williamsburg Regional Library 7770 Croaker Road Williamsburg, VA 23188-7064 (757)259-4044 www.wrl.org (757)259-4079 (fax) brett at wrl.org ******************************************************************** From darden at armc.org Wed Mar 11 08:46:41 2009 From: darden at armc.org (Darden, Patrick S.) Date: Wed, 11 Mar 2009 09:46:41 -0400 Subject: Dynamic IP log retention = 0? In-Reply-To: Message-ID: I think your next step is your lawyer. Put all your missives, your email, your phone conversations, your logs, your auditing results, your detection troubleshooting and sleuthing trails etc. in a folder, create a one page summary including any damages you feel might have been caused (e.g. time, effort, and money spent on this so far) and a timeline, and make an appointment with your lawyer. --Patrick Darden -----Original Message----- From: Brett Charbeneau [mailto:brett at wrl.org] Sent: Wednesday, March 11, 2009 9:34 AM To: nanog at nanog.org Subject: Dynamic IP log retention = 0? I've been nudging an operator at Covad about a handful of hosts from his DHCP pool that have been attacking - relentlessly port scanning - our assets. I've been informed by this individual that there's "no way" to determine which customer had that address at the times I list in my logs - even though these logs are sent within 48 hours of the incidents. The operator advised that I block the specific IP's that are attacking us at my perimeter. When I mentioned the fact that blocking individual addresses will only be as effective as the length of lease for that DHCP pool I get the email equivalent of a shrug. "Well, maybe you want to ban our entire /15 at your perimeter..." I'm reluctant to ban over 65,000 hosts as my staff have colleagues all over the continental US with whom they communicate regularly. I realize these are tough times and that large ISP's may trim abuse team budgets before other things, but to have NO MECHANISM to audit who has what address at any given time kinda blows my mind. Does one have to get to the level of a subpoena before abuse teams pull out the tools they need to make such a determination? Or am I naive enough to think port scans are as important to them as they are to me on the receiving end? -- ******************************************************************** Brett Charbeneau, GSEC Gold, GCIH Gold Network Administrator Williamsburg Regional Library 7770 Croaker Road Williamsburg, VA 23188-7064 (757)259-4044 www.wrl.org (757)259-4079 (fax) brett at wrl.org ******************************************************************** From jlewis at lewis.org Wed Mar 11 09:03:42 2009 From: jlewis at lewis.org (Jon Lewis) Date: Wed, 11 Mar 2009 10:03:42 -0400 (EDT) Subject: Dynamic IP log retention = 0? In-Reply-To: References: Message-ID: On Wed, 11 Mar 2009, Darden, Patrick S. wrote: > I think your next step is your lawyer. Put all your missives, your > email, your phone conversations, your logs, your auditing results, your > detection troubleshooting and sleuthing trails etc. in a folder, create > a one page summary including any damages you feel might have been caused > (e.g. time, effort, and money spent on this so far) and a timeline, and > make an appointment with your lawyer. I wouldn't necessarily believe the response from Covad and try to escalate to someone with a bit more clue there...but what's the point in getting lawyers involved? Whatever access isn't supposed to be open should be filtered. Beyond that, you should expect regular scans from random hosts on the net. That's the way it's been for the past 20 or more years, and it's unlikely to stop just because you don't like it. What effect will your lawers have next week when the 'abusive scans' are coming from Romania, China, Russia, etc.? If port scans really bother you, then you should setup a system to detect them, and regularly rebuild ACLs/null route lists/etc. to stop them in near real time. AFAIK, Cisco sells such a product, as do other network vendors I'm sure. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From jabley at hopcount.ca Wed Mar 11 09:28:33 2009 From: jabley at hopcount.ca (Joe Abley) Date: Wed, 11 Mar 2009 10:28:33 -0400 Subject: Dynamic IP log retention = 0? In-Reply-To: References: Message-ID: On 11-Mar-2009, at 10:03, Jon Lewis wrote: > but what's the point in getting lawyers involved? It might convince some pointy-haired person at covad to review the policies and procedures on the abuse desk, maybe. > Whatever access isn't supposed to be open should be filtered. If you can demonstrate reasonable costs resulting from the behaviour of others, perhaps that's not relevant. Note that in the grand NANOG tradition I say these things without the faintest glimmer of knowledge of the law. Joe From william.allen.simpson at gmail.com Wed Mar 11 09:42:14 2009 From: william.allen.simpson at gmail.com (William Allen Simpson) Date: Wed, 11 Mar 2009 10:42:14 -0400 Subject: Dynamic IP log retention = 0? In-Reply-To: References: Message-ID: <49B7CDC6.8070304@gmail.com> Brett Charbeneau wrote: > I've been nudging an operator at Covad about a handful of hosts from > his DHCP pool that have been attacking - relentlessly port scanning - > our assets. Port scanning is rather common, and shouldn't be considered "attacking" -- unless it's taking a significant amount of bandwidth. The latter is a Denial of Service (DoS) attack, and should be reported as such. I understand that a library might have limited bandwidth. Often port scanning is followed by an actual attack, ssh attempts, etc. That's what should be reported. > ... I've been informed by this individual that there's "no way" > to determine which customer had that address at the times I list in my > logs - even though these logs are sent within 48 hours of the incidents. Now that's just odd, and probably the "operator" at Covad simply doesn't have access to the logs. DHCP should be logged. In my experience, the usual practice is to keep the logs for 3 days, or until the log files roll over. > Does one have to get to the level of a subpoena before abuse teams > pull out the tools they need to make such a determination? Or am I naive > enough to think port scans are as important to them as they are to me on > the receiving end? > While I applaud your taking security seriously, and your active monitoring of your resources, other folks might be handling huge numbers of Conficker, Mebroot, and Torpig infections these days. So, they might be rather busy. Are your library systems all clean? You don't seem to have your own ARIN allocation for wrl.org, so it's kinda hard to tell from here.... AS | IP | AS Name 4565 | 66.200.204.71 | MEGAPATH2-US - MegaPath Networks Inc. From brett at wrl.org Wed Mar 11 09:55:43 2009 From: brett at wrl.org (Brett Charbeneau) Date: Wed, 11 Mar 2009 10:55:43 -0400 (EDT) Subject: Dynamic IP log retention = 0? In-Reply-To: <49B7CDC6.8070304@gmail.com> References: <49B7CDC6.8070304@gmail.com> Message-ID: On Wed, 11 Mar 2009, William Allen Simpson wrote: WAS> While I applaud your taking security seriously, and your active monitoring WAS> of your resources, other folks might be handling huge numbers of Conficker, WAS> Mebroot, and Torpig infections these days. So, they might be rather busy. Excellent point. And with dwindling staff levels outgoing worm traffic may be super low priority for them. I know every operation is different - I just wanted to check with the group before cranking up my level of indignation. =8^) WAS> Are your library systems all clean? I believe them to be. I have a Snort-based network intrusion detection system (using sguil) running with eight taps - and we subscribe to the Snort VRT rules. That's on top of host-based intrusion (OSSEC) on all of our servers and critical workstations. And centrallly-manged anti-virus (Kaspersky) on all desktops. WAS> You don't seem to have your own ARIN allocation for wrl.org, so it's kinda WAS> hard to tell from here.... WAS> WAS> AS | IP | AS Name WAS> 4565 | 66.200.204.71 | MEGAPATH2-US - MegaPath Networks Inc. Yes - while we handle our own DNS our ISP prefers to mask our ARIN entry for (their) ease of management. I try to be the anti-salmon with this and go WITH the flow... -- ******************************************************************** Brett Charbeneau, GSEC Gold, GCIH Gold Network Administrator Williamsburg Regional Library 7770 Croaker Road Williamsburg, VA 23188-7064 (757)259-4044 www.wrl.org (757)259-4079 (fax) brett at wrl.org ******************************************************************** From smb at cs.columbia.edu Wed Mar 11 10:28:28 2009 From: smb at cs.columbia.edu (Steven M. Bellovin) Date: Wed, 11 Mar 2009 11:28:28 -0400 Subject: Dynamic IP log retention = 0? In-Reply-To: References: Message-ID: <20090311112828.6c3eec84@cs.columbia.edu> On Wed, 11 Mar 2009 10:28:33 -0400 Joe Abley wrote: > > On 11-Mar-2009, at 10:03, Jon Lewis wrote: > > > but what's the point in getting lawyers involved? > > It might convince some pointy-haired person at covad to review the > policies and procedures on the abuse desk, maybe. > > > Whatever access isn't supposed to be open should be filtered. > > If you can demonstrate reasonable costs resulting from the behaviour > of others, perhaps that's not relevant. Note that in the grand NANOG > tradition I say these things without the faintest glimmer of > knowledge of the law. > I had long discussions on this with a lawyer ~15 years ago. A "tort" can arise from failure to do something you have a duty to do. Do ISPs have a duty to filter against port scans? I've never seen consensus on that here -- quite the contrary, in many cases. Now -- the courts can rule that you do have a duty to filter, even if the industry does not do it. Do we really want to be there, where ISPs are liable for the actions of their users? Of course, the attacker -- assuming that a scan is really an attack, which is itself a controversial question -- is liable. Is the OP really planning on filing suit? Let me play devil's advocate: how does Covad know that there were really port scans? Perhaps the logs are fakes, designed to uncover the name of someone doing file-sharing or criticizing someone on a blog. Maybe the offended site is a front for the government of Freedonia, which is trying to track down and harass (or worse) expatriate dissidents. Note that courts have held that under the DMCA, at least, the RIAA et al. can't learn alleged infringers' names via mandatory process (i.e., a subpoena) until they have actually filed suit for infringement. And of course, if Covad has a privacy policy, they might be liable to a customer for improper disclosure of identifying information. Don't neglect another possibility: the net result of a disclosure is likely to reveal that the scanning machine is really a bot, in which case the information is useless to the victim. So -- be careful what you wish for; you might get it. --Steve Bellovin, http://www.cs.columbia.edu/~smb From rubensk at gmail.com Wed Mar 11 10:42:40 2009 From: rubensk at gmail.com (Rubens Kuhl) Date: Wed, 11 Mar 2009 12:42:40 -0300 Subject: Dynamic IP log retention = 0? In-Reply-To: References: Message-ID: <6bb5f5b10903110842mfd063cfgd2a0b193dfef3eb6@mail.gmail.com> Covad telling you they don't keep logs is different from them not really having the logs... but, if they really don't keep logs, they are posing a risk that FBI or DHS might not be happy with. The feds will probably be more persuasive than you, so maybe hinting them about this situation may change something to better. Rubens On Wed, Mar 11, 2009 at 10:34 AM, Brett Charbeneau wrote: > ? ? ? ?I've been nudging an operator at Covad about a handful of hosts from > his DHCP pool that have been attacking - relentlessly port scanning - our > assets. I've been informed by this individual that there's "no way" to > determine which customer had that address at the times I list in my logs - > even though these logs are sent within 48 hours of the incidents. > ? ? ? ?The operator advised that I block the specific IP's that are > attacking us at my perimeter. When I mentioned the fact that blocking > individual addresses will only be as effective as the length of lease for > that DHCP pool I get the email equivalent of a shrug. > ? ? ? ?"Well, maybe you want to ban our entire /15 at your perimeter..." > ? ? ? ?I'm reluctant to ban over 65,000 hosts as my staff have colleagues > all over the continental US with whom they communicate regularly. > ? ? ? ?I realize these are tough times and that large ISP's may trim abuse > team budgets before other things, but to have NO MECHANISM to audit who has > what address at any given time kinda blows my mind. > ? ? ? ?Does one have to get to the level of a subpoena before abuse teams > pull out the tools they need to make such a determination? Or am I naive > enough to think port scans are as important to them as they are to me on the > receiving end? > > -- > ******************************************************************** > Brett Charbeneau, GSEC Gold, GCIH Gold > Network Administrator > Williamsburg Regional Library > 7770 Croaker Road > Williamsburg, VA 23188-7064 > (757)259-4044 ? ? ? ? ?www.wrl.org > (757)259-4079 (fax) ? ?brett at wrl.org > ******************************************************************** > > > From smb at cs.columbia.edu Wed Mar 11 10:52:57 2009 From: smb at cs.columbia.edu (Steven M. Bellovin) Date: Wed, 11 Mar 2009 11:52:57 -0400 Subject: Dynamic IP log retention = 0? In-Reply-To: <6bb5f5b10903110842mfd063cfgd2a0b193dfef3eb6@mail.gmail.com> References: <6bb5f5b10903110842mfd063cfgd2a0b193dfef3eb6@mail.gmail.com> Message-ID: <20090311115257.1fa0fadd@cs.columbia.edu> On Wed, 11 Mar 2009 12:42:40 -0300 Rubens Kuhl wrote: > Covad telling you they don't keep logs is different from them not > really having the logs... but, if they really don't keep logs, they > are posing a risk that FBI or DHS might not be happy with. The feds > will probably be more persuasive than you, so maybe hinting them about > this situation may change something to better. > There is no US legal requirement for keeping logs. The FBI et al. may want you to, and there is a bill before Congress to mandate retention (and that has been discussed on NANOG -- look for the Subject: 'Legislation and its effects in our world', or you can find the text itself at http://thomas.loc.gov/cgi-bin/query/z?c111:H.R.1076:) but there is no legal obligation to keep DHS happy. --Steve Bellovin, http://www.cs.columbia.edu/~smb From marcus at blazingdot.com Wed Mar 11 10:53:01 2009 From: marcus at blazingdot.com (Marcus Reid) Date: Wed, 11 Mar 2009 07:53:01 -0800 Subject: Dynamic IP log retention = 0? In-Reply-To: References: <49B7CDC6.8070304@gmail.com> Message-ID: <20090311155301.GA99262@blazingdot.com> On Wed, Mar 11, 2009 at 10:55:43AM -0400, Brett Charbeneau wrote: > On Wed, 11 Mar 2009, William Allen Simpson wrote: > > WAS> While I applaud your taking security seriously, and your active monitoring > WAS> of your resources, other folks might be handling huge numbers of Conficker, > WAS> Mebroot, and Torpig infections these days. So, they might be rather busy. > > Excellent point. And with dwindling staff levels outgoing worm traffic > may be super low priority for them. > I know every operation is different - I just wanted to check with the > group before cranking up my level of indignation. =8^) > > WAS> Are your library systems all clean? > > I believe them to be. I have a Snort-based network intrusion detection > system (using sguil) running with eight taps - and we subscribe to the Snort VRT > rules. That's on top of host-based intrusion (OSSEC) on all of our servers and > critical workstations. And centrallly-manged anti-virus (Kaspersky) on all > desktops. > > WAS> You don't seem to have your own ARIN allocation for wrl.org, so it's kinda > WAS> hard to tell from here.... > WAS> > WAS> AS | IP | AS Name > WAS> 4565 | 66.200.204.71 | MEGAPATH2-US - MegaPath Networks Inc. > > Yes - while we handle our own DNS our ISP prefers to mask our ARIN > entry for (their) ease of management. I try to be the anti-salmon with this and > go WITH the flow... A quick scan of the reverse mapping for your address space in DNS reveals that you have basically your entire network on public addresses. No wonder you're worried about portscans when the printer down the hall and the receptionists machine are sitting on public addresses. I think you are trying to secure your network from the wrong end here. Marcus From Charles at thewybles.com Wed Mar 11 11:11:13 2009 From: Charles at thewybles.com (Charles at thewybles.com) Date: Wed, 11 Mar 2009 16:11:13 +0000 Subject: Dynamic IP log retention = 0? Message-ID: <1739912429-1236787899-cardhu_decombobulator_blackberry.rim.net-1114677510-@bxe1216.bisx.prod.on.blackberry> Hope you did that scan from covad. Lol. *ducks* Sent via BlackBerry from T-Mobile From jabley at hopcount.ca Wed Mar 11 11:19:47 2009 From: jabley at hopcount.ca (Joe Abley) Date: Wed, 11 Mar 2009 12:19:47 -0400 Subject: Dynamic IP log retention = 0? In-Reply-To: <20090311155301.GA99262@blazingdot.com> References: <49B7CDC6.8070304@gmail.com> <20090311155301.GA99262@blazingdot.com> Message-ID: <81F650F7-F40C-4605-B519-DC56625AF1B7@hopcount.ca> On 11 Mar 2009, at 11:53, Marcus Reid wrote: > A quick scan of the reverse mapping for your address space in DNS > reveals > that you have basically your entire network on public addresses. It's indeed nice to see people deploying networks the way there were supposed to be built, for once. Nice troll, though. It has been at least a few weeks since the last "security = NAT" thread exploded in my inbox. Joe From brett at wrl.org Wed Mar 11 11:39:01 2009 From: brett at wrl.org (Brett Charbeneau) Date: Wed, 11 Mar 2009 12:39:01 -0400 (EDT) Subject: Dynamic IP log retention = 0? In-Reply-To: <20090311155301.GA99262@blazingdot.com> References: <49B7CDC6.8070304@gmail.com> <20090311155301.GA99262@blazingdot.com> Message-ID: On Wed, 11 Mar 2009, Marcus Reid wrote: MR> A quick scan of the reverse mapping for your address space in DNS reveals MR> that you have basically your entire network on public addresses. No wonder MR> you're worried about portscans when the printer down the hall and the MR> receptionists machine are sitting on public addresses. I think you are MR> trying to secure your network from the wrong end here. I apologize to the list for the static - I'm not sure how a question about log retention morphed into a misinformed critique of my organization's security posture. -- ******************************************************************** Brett Charbeneau, GSEC Gold, GCIH Gold Network Administrator Williamsburg Regional Library 7770 Croaker Road Williamsburg, VA 23188-7064 (757)259-4044 www.wrl.org (757)259-4079 (fax) brett at wrl.org ******************************************************************** From alec.berry at restontech.com Wed Mar 11 11:57:19 2009 From: alec.berry at restontech.com (Alec Berry) Date: Wed, 11 Mar 2009 12:57:19 -0400 Subject: Dynamic IP log retention = 0? In-Reply-To: References: Message-ID: <49B7ED6F.9070508@restontech.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jon Lewis wrote: > If port scans really bother you, then you should setup a system to detect > them, and regularly rebuild ACLs/null route lists/etc. to stop them in > near real time. AFAIK, Cisco sells such a product, as do other network > vendors I'm sure. It is pretty easy to do this with pf running on OpenBSD (et al). You can even set a timeout so that additions to a banned list get removed after x {hours,days,weeks} table evil persist {0.0.0.0} block in log quick from to any label "evil" pass in quick proto {tcp,udp} from any to any port 1024:65000 \ synproxy state \ (max-src-conn-rate 5/15, overload flush global) Pick a port range and/or ip address range combo that you don't have anything running on for the rule, then as scans take place the offending IP will be added to the evil table and blocked. OK, there are some additional details for expiring the evil IPs, and of course your own network details. But this has worked quite well for me, and I love checking the evil table from time to time to see who's been naughty. My best guess is other firewalls can do something similar. ... alec - -- `____________ / Alec Berry \______________________________ | Senior Partner and Director of Technology \ | PGP/GPG key 0xE8E9030F | | http://alec.restontech.com/#PGP | |-------------------------------------------| | RestonTech, Ltd. | | http://www.restontech.com/ | | Phone: (703) 234-2914 | \___________________________________________/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJt+1tREO1P+jpAw8RAhkXAKDlZK1gv00oxswqjkRu6TmG7JkoGACfcdSX S0mIegpuf++j+yMTjoNHLOI= =nIb7 -----END PGP SIGNATURE----- From chris.ranch at nokia.com Wed Mar 11 12:31:26 2009 From: chris.ranch at nokia.com (chris.ranch at nokia.com) Date: Wed, 11 Mar 2009 18:31:26 +0100 Subject: Redundant Array of Inexpensive ISP's? In-Reply-To: <485ED9BA02629E4BBBA53AC892EDA50E08901FC4@usmsxt104.mwd.h2o> References: <20090310230158.GA19876@tetro.net> <485ED9BA02629E4BBBA53AC892EDA50E08901FC4@usmsxt104.mwd.h2o> Message-ID: Yes and no. Yes, in that it does best path selection, no in that it does not use BGP, since low cost assumes DSL or cable, over which I've never seen BGP deployed. This class of device assumes an appliance at each end. Performance data is collected, compression and load balancing techniques applied, and a sum total improvement of capacity and reliability is achieved. If you notice similarity between Talari and Route Science, they both do cover the same field and by several of the same people. Also, there are several producers of BGP route selectors, netVMG (now FCP at InterNAP), Proficient Networks (InfiniRoute) and Cisco's follow-on product. I have no direct experience with Talari appliances. Chris >The Talari device appears to operate like the old Routescience >Pathcontrol BGP load balancer circa 2002 From jeremy at evilrouters.net Wed Mar 11 13:06:24 2009 From: jeremy at evilrouters.net (Jeremy L. Gaddis) Date: Wed, 11 Mar 2009 14:06:24 -0400 Subject: Dynamic IP log retention = 0? In-Reply-To: <49B7ED6F.9070508@restontech.com> References: <49B7ED6F.9070508@restontech.com> Message-ID: <8623d07f0903111106h37cce4c0p6aae1a90ea6a7e0@mail.gmail.com> On Wed, Mar 11, 2009 at 12:57 PM, Alec Berry wrote: > block in log quick from to any label "evil" RFC 3514? :-) -- Jeremy L. Gaddis http://evilrouters.net/ From BBlackford at nwresd.k12.or.us Wed Mar 11 13:18:11 2009 From: BBlackford at nwresd.k12.or.us (Bill Blackford) Date: Wed, 11 Mar 2009 11:18:11 -0700 Subject: SUP720 vs. SUP32 Message-ID: <6069A203FD01884885C037F81DD75080CA064DA9@wsc-mail-01.intra.nwresd.k12.or.us> Anyone have any experience with SUP32? Please contact me off list. I'm trying to evaluate a lower-cost alternative to the 720-3bxl. I'm only pushing a few hundred megs of traffic, exchanging a few routes with less than 20 peers and don't see the need for a 720's worth of throughput in the near future. Can the 32 handle a full table? How does the MFSC2A compare to the MFSC3? V6 support? Thank you. -- Bill Blackford Senior Network Engineer my /home away from home From adrian at creative.net.au Wed Mar 11 13:24:07 2009 From: adrian at creative.net.au (Adrian Chadd) Date: Thu, 12 Mar 2009 03:24:07 +0900 Subject: SUP720 vs. SUP32 In-Reply-To: <6069A203FD01884885C037F81DD75080CA064DA9@wsc-mail-01.intra.nwresd.k12.or.us> References: <6069A203FD01884885C037F81DD75080CA064DA9@wsc-mail-01.intra.nwresd.k12.or.us> Message-ID: <20090311182407.GB12934@skywalker.creative.net.au> On Wed, Mar 11, 2009, Bill Blackford wrote: > Can the 32 handle a full table? Start here: http://www.mail-archive.com/cisco-nsp at puck.nether.net/msg12492.html adrian From bfeeny at mac.com Wed Mar 11 13:29:08 2009 From: bfeeny at mac.com (Brian Feeny) Date: Wed, 11 Mar 2009 14:29:08 -0400 Subject: SUP720 vs. SUP32 In-Reply-To: <6069A203FD01884885C037F81DD75080CA064DA9@wsc-mail-01.intra.nwresd.k12.or.us> References: <6069A203FD01884885C037F81DD75080CA064DA9@wsc-mail-01.intra.nwresd.k12.or.us> Message-ID: Honestly, my advise is don't handle full tables in switches unless you want to use 3bxl. Use routers, any old ISR can do 1GB memory or so and handle the table just fine, and run you a fraction of the cost. Keep internal routes, defaults, etc in the switching core. Brian On Mar 11, 2009, at 2:18 PM, Bill Blackford wrote: > Anyone have any experience with SUP32? Please contact me off list. > > I'm trying to evaluate a lower-cost alternative to the 720-3bxl. > I'm only pushing a few hundred megs of traffic, exchanging a few > routes with less than 20 peers and don't see the need for a 720's > worth of throughput in the near future. > > Can the 32 handle a full table? > How does the MFSC2A compare to the MFSC3? > V6 support? > > Thank you. > > -- > Bill Blackford > Senior Network Engineer > > my /home away from home > > > From jlewis at lewis.org Wed Mar 11 13:36:16 2009 From: jlewis at lewis.org (Jon Lewis) Date: Wed, 11 Mar 2009 14:36:16 -0400 (EDT) Subject: SUP720 vs. SUP32 In-Reply-To: <6069A203FD01884885C037F81DD75080CA064DA9@wsc-mail-01.intra.nwresd.k12.or.us> References: <6069A203FD01884885C037F81DD75080CA064DA9@wsc-mail-01.intra.nwresd.k12.or.us> Message-ID: On Wed, 11 Mar 2009, Bill Blackford wrote: > I'm trying to evaluate a lower-cost alternative to the 720-3bxl. > I'm only pushing a few hundred megs of traffic, exchanging a few routes with less than 20 peers and don't see the need for a 720's worth of throughput in the near future. > > Can the 32 handle a full table? No...not unless things have changed and you can get/put a pfc 3bxl on a sup32. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From bfeeny at mac.com Wed Mar 11 13:36:21 2009 From: bfeeny at mac.com (Brian Feeny) Date: Wed, 11 Mar 2009 14:36:21 -0400 Subject: SUP720 vs. SUP32 In-Reply-To: References: <6069A203FD01884885C037F81DD75080CA064DA9@wsc-mail-01.intra.nwresd.k12.or.us> Message-ID: Actually let me amend that and say 3800's as far as inexpensive routers. They are basically NPE400 class devices, with alot of memory and sufficient to handle the full table. Other router devices like 7200's etc will work fine as well. On Mar 11, 2009, at 2:29 PM, Brian Feeny wrote: > > Honestly, my advise is don't handle full tables in switches unless > you want to use 3bxl. Use routers, any old ISR can do 1GB memory or > so and handle the table just fine, and run you a fraction of the > cost. Keep internal routes, defaults, etc in the switching core. > > Brian > > On Mar 11, 2009, at 2:18 PM, Bill Blackford wrote: > >> Anyone have any experience with SUP32? Please contact me off list. >> >> I'm trying to evaluate a lower-cost alternative to the 720-3bxl. >> I'm only pushing a few hundred megs of traffic, exchanging a few >> routes with less than 20 peers and don't see the need for a 720's >> worth of throughput in the near future. >> >> Can the 32 handle a full table? >> How does the MFSC2A compare to the MFSC3? >> V6 support? >> >> Thank you. >> >> -- >> Bill Blackford >> Senior Network Engineer >> >> my /home away from home >> >> >> > > From alec.berry at restontech.com Wed Mar 11 13:43:09 2009 From: alec.berry at restontech.com (Alec Berry) Date: Wed, 11 Mar 2009 14:43:09 -0400 Subject: Dynamic IP log retention = 0? In-Reply-To: <8623d07f0903111106h37cce4c0p6aae1a90ea6a7e0@mail.gmail.com> References: <49B7ED6F.9070508@restontech.com> <8623d07f0903111106h37cce4c0p6aae1a90ea6a7e0@mail.gmail.com> Message-ID: <49B8063D.20309@restontech.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jeremy L. Gaddis wrote: > RFC 3514? :-) Ah, but if it was just that easy... The choice of "evil" for a table name was not random, of course! I do appreciate that the pf syntax makes for such entertaining configuration snippets. I have yet to pen a functional haiku, however. ... alec - -- `____________ / Alec Berry \______________________________ | Senior Partner and Director of Technology \ | PGP/GPG key 0xE8E9030F | | http://alec.restontech.com/#PGP | |-------------------------------------------| | RestonTech, Ltd. | | http://www.restontech.com/ | | Phone: (703) 234-2914 | \___________________________________________/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJuAY8REO1P+jpAw8RAkXNAJ490Lz1hbEvRwiwyFp7fvemcBVrvQCfSUfE 17LKUrs7ts871zQPUCLnH6o= =1/i9 -----END PGP SIGNATURE----- From BBlackford at nwresd.k12.or.us Wed Mar 11 14:06:05 2009 From: BBlackford at nwresd.k12.or.us (Bill Blackford) Date: Wed, 11 Mar 2009 12:06:05 -0700 Subject: SUP720 vs. SUP32 In-Reply-To: <6069A203FD01884885C037F81DD75080CA064DA9@wsc-mail-01.intra.nwresd.k12.or.us> References: <6069A203FD01884885C037F81DD75080CA064DA9@wsc-mail-01.intra.nwresd.k12.or.us> Message-ID: <6069A203FD01884885C037F81DD75080CA064DD9@wsc-mail-01.intra.nwresd.k12.or.us> Thank you to everyone who offered advice. I thinks it's clearer what my path should be. Incidentally, I am using 7300/7200 based units with G1 RP and found that at 200M they start seeing 50% CPU load which is why I'm looking to go to the next step. Again, thanks to all -b -----Original Message----- From: Bill Blackford [mailto:BBlackford at nwresd.k12.or.us] Sent: Wednesday, March 11, 2009 11:18 AM To: nanog at nanog.org Subject: SUP720 vs. SUP32 Anyone have any experience with SUP32? Please contact me off list. I'm trying to evaluate a lower-cost alternative to the 720-3bxl. I'm only pushing a few hundred megs of traffic, exchanging a few routes with less than 20 peers and don't see the need for a 720's worth of throughput in the near future. Can the 32 handle a full table? How does the MFSC2A compare to the MFSC3? V6 support? Thank you. -- Bill Blackford Senior Network Engineer my /home away from home From adrian at creative.net.au Wed Mar 11 14:34:12 2009 From: adrian at creative.net.au (Adrian Chadd) Date: Thu, 12 Mar 2009 04:34:12 +0900 Subject: SUP720 vs. SUP32 In-Reply-To: <6069A203FD01884885C037F81DD75080CA064DD9@wsc-mail-01.intra.nwresd.k12.or.us> References: <6069A203FD01884885C037F81DD75080CA064DA9@wsc-mail-01.intra.nwresd.k12.or.us> <6069A203FD01884885C037F81DD75080CA064DD9@wsc-mail-01.intra.nwresd.k12.or.us> Message-ID: <20090311193412.GC12934@skywalker.creative.net.au> On Wed, Mar 11, 2009, Bill Blackford wrote: > Thank you to everyone who offered advice. I thinks it's clearer what my path should be. > > Incidentally, I am using 7300/7200 based units with G1 RP and found that at 200M they start seeing 50% CPU load which is why I'm looking to go to the next step. Check the cisco-nsp archive, specifically from Rodney; he has talked about what the CPU load versus throughput implications are on the G1 and G2. It might surprise you a little. Adrian From gdt at gdt.id.au Wed Mar 11 14:56:25 2009 From: gdt at gdt.id.au (Glen Turner) Date: Thu, 12 Mar 2009 06:26:25 +1030 Subject: Dynamic IP log retention = 0? In-Reply-To: <49B7CDC6.8070304@gmail.com> References: <49B7CDC6.8070304@gmail.com> Message-ID: <49B81769.9080106@gdt.id.au> William Allen Simpson wrote: > Port scanning is rather common, and shouldn't be considered "attacking" -- > unless it's taking a significant amount of bandwidth. Attempting to gain unauthorised access to a computing system is a crime in most countries. Port scanning is a tool used to gain unauthorised access. (Yes, port scanning can be used for other things, but it's difficult to argue for those when scanning someone else's machines.) A telecommunications carrier releasing a customer's details without their permission, to a non-investigatory third party, without a court order. Hmmm. It's certainly illegal here in Australia. And last I checked wasn't the US firm Hewlett Packard in trouble for hiring people to do just that? So your basic problem is that you have a law enforcement problem, and the law enforcers don't give this priority. Which leads to one of those vicious circle thingies, where the ISPs don't give a stuff about their customers running scans, since they aren't seeing any hassle from Mr Plod, those customers aren't seeing any consequences, and so the amount of scanning increases, to the extent where people believe it is normal and acceptable. Why not contact the FBI. Not because it will help. But because if even 1% of the libraries in the country do that then the FBI will take the path of least resistance, which is to hassle ISPs with enough warrants until the ISPs find it economic to clean up their act, at least with regard to their own customers. -- Glen Turner From Rich_Andreas at Cable.Comcast.com Wed Mar 11 15:20:49 2009 From: Rich_Andreas at Cable.Comcast.com (Andreas, Rich) Date: Wed, 11 Mar 2009 16:20:49 -0400 Subject: Network SLA In-Reply-To: <262b67200903070312j55bded5dq26c978feb0b66441@mail.gmail.com> References: <262b67200902190750m556cf72ve2ae25e4b64378e7@mail.gmail.com><499DBE2A.6020907@gmail.com><4fff97de0902230019tce5e53q2ddb501171436dc@mail.gmail.com> <262b67200903070312j55bded5dq26c978feb0b66441@mail.gmail.com> Message-ID: <997BC128AE961E4A8B880CD7442D94800A1EC529@NJCHLEXCMB01.cable.comcast.com> I have found that Cisco IPSLA is heavily used in the MSO/Service Provider Space. Juniper has equivalent functionality via RPM. Rich -----Original Message----- From: Saqib Ilyas [mailto:msaqib at gmail.com] Sent: Saturday, March 07, 2009 6:12 AM To: nanog at nanog.org Subject: Re: Network SLA I must thank everyone who has answered my queries. Just a couple more short questions. For instance, if one is using MRTG, and wants to check if we can meet a 1 Mbps end-to-end throughput between a couple of customer sites, I believe you would need to use some traffic generator tools, because MRTG merely imports counters from routers and plots them. Is that correct? We've heard of the BRIX active measurement tool in replies to my earlier email. Also, I've found Cisco IP SLA that also sends traffic into the service provider network and measures performance. How many people really use IP SLA feature? Thanks and best regards On Mon, Feb 23, 2009 at 1:19 PM, Zartash Uzmi wrote: > As I gather, there is a mix of answers, ranging from "building the resources > according to requirements and HOPE for the best" to "use of arguably > sophisticated tools and perhaps sharing the results with the legal > department". > > I would be particularly interested in hearing the service providers' > viewpoint on the following situation. > > Consider a service provider with MPLS deployed within its own network. > > (A) When the SP enters into a relation with the customer, does the SP > establish new MPLS paths based on customer demands (this is perhaps similar > to "building" based on requirements as pointed out by David)? If yes, > between what sites/POPs? I assume the answer may be different depending upon > a single-site customer or a customer with multiple sites. > > (B) For entering into the relationship for providing X units of bandwidth > (to another site of same customer or to the Tier-1 backbone), does the SP > use any wisdom (in addition to MRTG and the likes)? If so, what scientific > parameters are kept in mind? > > (C) How does the customer figure out that a promise for X units of bandwidth > is maintained by the SP? I believe customers may install some measuring > tools but is that really the case in practice? > > Thanks, > Zartash > > On Fri, Feb 20, 2009 at 1:16 AM, Stefan wrote: > >> Saqib Ilyas wrote: >> >>> Greetings >>> I am curious to know about any tools/techniques that a service provider >>> uses >>> to assess an SLA before signing it. That is to say, how does an >>> administrator know if he/she can meet what he is promising. Is it based on >>> experience? Are there commonly used tools for this? >>> Thanks and best regards >>> >>> >> Not necessarily as a direct answer (I am pretty sure there'll be others on >> this list giving details in the area of specific tools and standards), but I >> think this may be a question (especially considering your end result >> concern: *signing the SLA!) equally applicable to your legal department. In >> the environment we live, nowadays, the SLA could (should?!? ... >> unfortunately) be "refined" and (at the other end - i.e. receiving) >> "interpreted" by the lawyers, with possibly equal effects (mostly financial >> and as overall impact on the business) as the tools we (the technical >> people) would be using to measure latency, uptime, bandwidth, jitter, etc... >> >> Stefan >> >> > -- Muhammad Saqib Ilyas PhD Student, Computer Science and Engineering Lahore University of Management Sciences From ncnet at sbcglobal.net Wed Mar 11 16:29:05 2009 From: ncnet at sbcglobal.net (Larry Stites) Date: Wed, 11 Mar 2009 13:29:05 -0800 Subject: SUP720 vs. SUP32 In-Reply-To: <6069A203FD01884885C037F81DD75080CA064DA9@wsc-mail-01.intra.nwresd.k12.or.us> Message-ID: Bill, As far as pricing for refurbished Cisco Supervisor Engines the 3BXL is selling for around $7500 whereas the WS-SUP32-10GE-3B $5500, WS-SUP32-GE-3B $2500... Best regards, Larry E. Stites Northern California Networks, Inc. LIC# 2004 SR KH 100-484111 Nevada City, CA 95959 on 3/11/09 10:18 AM, Bill Blackford wrote: > Anyone have any experience with SUP32? Please contact me off list. > > I'm trying to evaluate a lower-cost alternative to the 720-3bxl. > I'm only pushing a few hundred megs of traffic, exchanging a few routes with > less than 20 peers and don't see the need for a 720's worth of throughput in > the near future. > > Can the 32 handle a full table? > How does the MFSC2A compare to the MFSC3? > V6 support? > > Thank you. > > -- > Bill Blackford > Senior Network Engineer > > my /home away from home From dholmes at mwdh2o.com Wed Mar 11 15:37:48 2009 From: dholmes at mwdh2o.com (Holmes,David A) Date: Wed, 11 Mar 2009 13:37:48 -0700 Subject: SUP720 vs. SUP32 In-Reply-To: <6069A203FD01884885C037F81DD75080CA064DA9@wsc-mail-01.intra.nwresd.k12.or.us> References: <6069A203FD01884885C037F81DD75080CA064DA9@wsc-mail-01.intra.nwresd.k12.or.us> Message-ID: <485ED9BA02629E4BBBA53AC892EDA50E089021D9@usmsxt104.mwd.h2o> Make sure that the new 10 GiGE line cards are not in your plans if you choose the SUP32. This holds for some of the other copper and fiber line cards where line card buffer capacity may be critical to effective throughput. Some new line cards only connect to the 720 Gig backplane. -----Original Message----- From: Bill Blackford [mailto:BBlackford at nwresd.k12.or.us] Sent: Wednesday, March 11, 2009 11:18 AM To: nanog at nanog.org Subject: SUP720 vs. SUP32 Anyone have any experience with SUP32? Please contact me off list. I'm trying to evaluate a lower-cost alternative to the 720-3bxl. I'm only pushing a few hundred megs of traffic, exchanging a few routes with less than 20 peers and don't see the need for a 720's worth of throughput in the near future. Can the 32 handle a full table? How does the MFSC2A compare to the MFSC3? V6 support? Thank you. -- Bill Blackford Senior Network Engineer my /home away from home From jgreco at ns.sol.net Wed Mar 11 16:32:17 2009 From: jgreco at ns.sol.net (Joe Greco) Date: Wed, 11 Mar 2009 15:32:17 -0600 (CST) Subject: Dynamic IP log retention = 0? In-Reply-To: <20090311155301.GA99262@blazingdot.com> from "Marcus Reid" at Mar 11, 2009 07:53:01 AM Message-ID: <200903112132.n2BLWHBv006094@aurora.sol.net> > A quick scan of the reverse mapping for your address space in DNS reveals > that you have basically your entire network on public addresses. No wonder > you're worried about portscans when the printer down the hall and the > receptionists machine are sitting on public addresses. I think you are > trying to secure your network from the wrong end here. Your idea of "security" is strange and unrealistic. Putting all of your network behind NAT is not a guarantee of security. IPv4 is slowly grinding to a close. NAT has been an aid to reduce the requirement for routable IP space at many sites, but it has never been required to stick your entire network behind NAT. Anyone capable of justifying the IP space and acquiring it from an upstream ISP is able to put all their IP-enabled gizmos, no matter even if it's just a bunch of printers, scanners, UPS's, and other random IP-capable gear, on the public Internet. It should not be the operator community's job to be the arbiter of what devices are worthy of public IP space. And take that and think about it, because IPv6 is coming. This will encourage the deployment of networks that connect every IP-capable device in reach. This implies many things. It is clear that we've not done a real good job of designing IPv4 devices with sufficient layers of security to be able to stick random devices on the Internet without a firewall and some contemplation of rules, something I hope changes between now and IPv6 widespread deployment. The question shouldn't be about whether this gentleman is securing his network from the wrong end. In our neighbourhood, we don't have a high crime rate. Despite that, if we saw someone walking from house to house, trying doorknobs, we'd call the cops. The fact that everyone has locks on their doors does not make it all right for someone to go around from house to house to see if they're all locked. In that same fashion, there's no particular reason to expect that the gentleman who started this thread hasn't already provided some layers of protection for his network. Trying to address the attacker is a sane and reasonable next step. We have some real and difficult questions to address in terms of how much do we want to do in response to such complaints. There are a lot of potential impacts on operators for dealing with abuse complaints, but we should be aware that this issue isn't going to go away, that blaming the target site's security rather than the attacker is simply wrong, that we're going to see even more devices attached under IPv6, and that if we don't want legislative solutions handed to us to implement, I would expect that it's a better idea to stop people from doing things from your network that causes others to squawk (and obviously I'm talking about Covad and the Covad-emitted traffic here). ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From mike at rockynet.com Wed Mar 11 16:54:14 2009 From: mike at rockynet.com (Mike Lewinski) Date: Wed, 11 Mar 2009 15:54:14 -0600 Subject: Dynamic IP log retention = 0? In-Reply-To: <200903112132.n2BLWHBv006094@aurora.sol.net> References: <200903112132.n2BLWHBv006094@aurora.sol.net> Message-ID: <49B83306.3030004@rockynet.com> Joe Greco wrote: >> A quick scan of the reverse mapping for your address space in DNS reveals >> that you have basically your entire network on public addresses. No wonder >> you're worried about portscans when the printer down the hall and the >> receptionists machine are sitting on public addresses. I think you are >> trying to secure your network from the wrong end here. > > Your idea of "security" is strange and unrealistic. > > Putting all of your network behind NAT is not a guarantee of security. Amen. Our NOCS workstations all use public IP addresses that are routed through a firewall. The firewall applies appropriate policies that would be functionally no different from applying the same policies to NAT'd hosts. In our environment, we'd gain absolutely nothing from a security perspective by enabling NAT. But it does help ensure that poorly designed applications don't require proxies to support them through NAT (SIP, FTP etc). And we'll never have problems with a partner VPN conflicting with our internal IP space. Mike From beckman at angryox.com Wed Mar 11 17:27:44 2009 From: beckman at angryox.com (Peter Beckman) Date: Wed, 11 Mar 2009 18:27:44 -0400 Subject: Dynamic IP log retention = 0? In-Reply-To: <200903112132.n2BLWHBv006094@aurora.sol.net> References: <200903112132.n2BLWHBv006094@aurora.sol.net> Message-ID: On Wed, 11 Mar 2009, Joe Greco wrote: > In our neighbourhood, we don't have a high crime rate. Despite that, > if we saw someone walking from house to house, trying doorknobs, we'd > call the cops. The fact that everyone has locks on their doors does > not make it all right for someone to go around from house to house to > see if they're all locked. However, it's not illegal, AFAIK. It's only illegal if you enter. Either that, or I'm gonna go prosecute some Girl Scouts. More relatedly, is there some sort of obligation with IPv6 to move all of your NAT'ed hosts away from NAT? Just because you can doesn't make it a good idea. I agree, NAT != security, but it does give one a single point to manage those hosts behind it. Beckman --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ --------------------------------------------------------------------------- From jgreco at ns.sol.net Wed Mar 11 17:46:54 2009 From: jgreco at ns.sol.net (Joe Greco) Date: Wed, 11 Mar 2009 16:46:54 -0600 (CST) Subject: Dynamic IP log retention = 0? In-Reply-To: from "Peter Beckman" at Mar 11, 2009 06:27:44 PM Message-ID: <200903112246.n2BMksD3010507@aurora.sol.net> > On Wed, 11 Mar 2009, Joe Greco wrote: > > In our neighbourhood, we don't have a high crime rate. Despite that, > > if we saw someone walking from house to house, trying doorknobs, we'd > > call the cops. The fact that everyone has locks on their doors does > > not make it all right for someone to go around from house to house to > > see if they're all locked. > > However, it's not illegal, AFAIK. It's only illegal if you enter. Either > that, or I'm gonna go prosecute some Girl Scouts. It may not be technically illegal, but I'd bet hard cash that our local cops would find a way to put you in cuffs and haul you in. Girl Scouts are probably going to be treated a bit different than random adults who have no reasonable explanation to be trying the knobs. Girl Scouts could possibly be excused as not knowing any better. > More relatedly, is there some sort of obligation with IPv6 to move all of > your NAT'ed hosts away from NAT? No. There's also no obligation with a loaded shotgun to not point it at your foot. You can do it, you can pull the trigger. NAT has many drawbacks, especially including a whole bunch of shortcomings where workarounds are required for various protocols due to our insistence on inflicting the brokenness of NAT on the world. These are all well documented. http://www.circleid.com/posts/nat_just_say_no/ etc. > Just because you can doesn't make it a > good idea. I agree, NAT != security, but it does give one a single point > to manage those hosts behind it. So's a firewall. Nobody is suggesting that we throw out the baby with the bathwater. But the bathwater's old and stinky, and is a severe impediment to growth at this point. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From herrin-nanog at dirtside.com Wed Mar 11 17:57:59 2009 From: herrin-nanog at dirtside.com (William Herrin) Date: Wed, 11 Mar 2009 18:57:59 -0400 Subject: Dynamic IP log retention = 0? In-Reply-To: References: <200903112132.n2BLWHBv006094@aurora.sol.net> Message-ID: <3c3e3fca0903111557o1a579377i5a23316f5d30a135@mail.gmail.com> On Wed, Mar 11, 2009 at 6:27 PM, Peter Beckman wrote: > On Wed, 11 Mar 2009, Joe Greco wrote: > >> In our neighbourhood, we don't have a high crime rate. ?Despite that, >> if we saw someone walking from house to house, trying doorknobs, we'd >> call the cops. ?The fact that everyone has locks on their doors does >> not make it all right for someone to go around from house to house to >> see if they're all locked. > > ?However, it's not illegal, AFAIK. ?It's only illegal if you enter. ?Either > ?that, or I'm gonna go prosecute some Girl Scouts. Actually, in most jurisdictions trying strangers' doorknobs is probably misdemeanor disorderly conduct, typically punishable by fines of a few hundred dollars and jail for a few months. More often than not used as a threat: "Sir, you need to leave the neighborhood or you'll be arrested and charged with disorderly conduct." That's what "disorderly conduct" is for: folks who are obviously doing something they ought not be doing but for which an explicit law has not been written. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From mtinka at globaltransit.net Wed Mar 11 23:34:21 2009 From: mtinka at globaltransit.net (Mark Tinka) Date: Thu, 12 Mar 2009 12:34:21 +0800 Subject: SUP720 vs. SUP32 In-Reply-To: <6069A203FD01884885C037F81DD75080CA064DD9@wsc-mail-01.intra.nwresd.k12.or.us> References: <6069A203FD01884885C037F81DD75080CA064DA9@wsc-mail-01.intra.nwresd.k12.or.us> <6069A203FD01884885C037F81DD75080CA064DD9@wsc-mail-01.intra.nwresd.k12.or.us> Message-ID: <200903121234.26297.mtinka@globaltransit.net> On Thursday 12 March 2009 03:06:05 am Bill Blackford wrote: > Incidentally, I am using 7300/7200 based units with G1 RP > and found that at 200M they start seeing 50% CPU load > which is why I'm looking to go to the next step. Be sure to optimize your configuration before you upgrade. Depending on what services you have enabled (either by default or design), you can squeeze quite a bit from these boxes before you need to upgrade with a pretty lean configuration - and the NPE-G2 can sit a sweet 2GB of DRAM nicely :-). We've been able to forward some 950Mbps out of an NPE-G2 at ~72% CPU utilization as a core router, and about 600Mbps at the same CPU utilization as an edge router. With the current bloat of the routing table today, the sheer force software routers provide re: RIB/FIB memory for a couple-of-hundred Mbps of traffic forwarded is hard to ignore. Cheers, Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. URL: From ross at dillio.net Thu Mar 12 02:25:16 2009 From: ross at dillio.net (Ross) Date: Thu, 12 Mar 2009 02:25:16 -0500 (CDT) Subject: Dynamic IP log retention = 0? In-Reply-To: References: Message-ID: How did a simple thread about network scanning get so derailed....we have people talking about the legal implications of port scanning, hiring lawyers to go after ISPs, talking to the fbi, the benefits/downfalls of NAT as a security policy, etc. Wow just wow. I'll try to answer you in a more common sense approach as some have tried to do. First of all no network operator has to hand over their logs or user information over to you just because you want to know. You can ask their abuse department to intervene but that is all up to that department. They may have told you they don't have them just because they didn't want you pestering them anymore or they may really not have them, who knows. Don't try to judge them but try to fix this very minute problem in a way you can control. The ways you can control this are simple. 1) Block all of covad (not very smart) 2) Block all of covad except for essential ports (25,80,443 or whatever other common ports they may need) 3) Setup a perimeter protection that blocks hosts that are scanning you and removes them after a determined amount of time This trying to shun people in public because they aren't following your guide to network administration probably isn't going to work very well for you. If 65000 covad addresses were ddosing you then I would agree that you have a legitimate gripe but focus on what you can control and not what you believe others should be doing. -- Ross ross [at] dillio.net > I've been nudging an operator at Covad about a handful of hosts from his > DHCP pool that have been attacking - relentlessly port scanning - our > assets. > I've been informed by this individual that there's "no way" to determine > which > customer had that address at the times I list in my logs - even though > these > logs are sent within 48 hours of the incidents. > The operator advised that I block the specific IP's that are attacking > us at my perimeter. When I mentioned the fact that blocking individual > addresses > will only be as effective as the length of lease for that DHCP pool I get > the > email equivalent of a shrug. > "Well, maybe you want to ban our entire /15 at your perimeter..." > I'm reluctant to ban over 65,000 hosts as my staff have colleagues > all over the continental US with whom they communicate regularly. > I realize these are tough times and that large ISP's may trim abuse team > budgets before other things, but to have NO MECHANISM to audit who has > what > address at any given time kinda blows my mind. > Does one have to get to the level of a subpoena before abuse teams pull > out the tools they need to make such a determination? Or am I naive enough > to > think port scans are as important to them as they are to me on the > receiving > end? > > -- > ******************************************************************** > Brett Charbeneau, GSEC Gold, GCIH Gold > Network Administrator > Williamsburg Regional Library > 7770 Croaker Road > Williamsburg, VA 23188-7064 > (757)259-4044 www.wrl.org > (757)259-4079 (fax) brett at wrl.org > ******************************************************************** > > > From brett at the-watsons.org Thu Mar 12 02:38:38 2009 From: brett at the-watsons.org (Brett Watson) Date: Thu, 12 Mar 2009 00:38:38 -0700 Subject: Dynamic IP log retention = 0? In-Reply-To: References: Message-ID: On Mar 12, 2009, at 12:25 AM, Ross wrote: > How did a simple thread about network scanning get so derailed....we > have > people talking about the legal implications of port scanning, hiring > lawyers to go after ISPs, talking to the fbi, the benefits/downfalls > of > NAT as a security policy, etc. Wow just wow. it's nanog, you expect something different? :) From president at ukraine.su Thu Mar 12 06:44:28 2009 From: president at ukraine.su (Max Tulyev) Date: Thu, 12 Mar 2009 13:44:28 +0200 Subject: Redundant Array of Inexpensive ISP's? In-Reply-To: <20090310230158.GA19876@tetro.net> References: <20090310230158.GA19876@tetro.net> Message-ID: <49B8F59C.3000309@ukraine.su> Hello Tim, a lot of our customers need a very stable Internet access got their portable address space and their AS number from us (we are a LIR) and connected to 2 or even more upstreams. Sure, some of broadband ISPs didn't provide BGP for their clients, but there are companies providing BGP over L2TP or GRE. So all the solution costs ~$1000 one-time fee (PI/AS, BGP router like Cisco or Quagga box, a bit consulting). Good advice is to diverse upstreams by the media, i.e. CaTV+DSL+Fiber+Radio, so if fiber to the house is cut - radio still working. It is possible to integrate that to a complete service - i.e. install a box that connects to 2-3 ISPs and "just works", but we haven't requests to to that. Please, contact me off-list if somebody interesting in it. Tim Utschig wrote: > [Please reply off-list. I'll summarize back to the list if there > is more than a little interest in me doing so.] > > I'm curious if anyone has experience with products from Talari > Networks, or anything similar, and would like to share. Did they > live up to your expectations? Caveats? > -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253 at FIDO) From ka at pacific.net Thu Mar 12 09:17:48 2009 From: ka at pacific.net (Ken A) Date: Thu, 12 Mar 2009 09:17:48 -0500 Subject: Redundant Array of Inexpensive ISP's? In-Reply-To: <20090310230158.GA19876@tetro.net> References: <20090310230158.GA19876@tetro.net> Message-ID: <49B9198C.1020201@pacific.net> Tim Utschig wrote: > [Please reply off-list. I'll summarize back to the list if there > is more than a little interest in me doing so.] > Please do. There are many rural ISPs and WISPs that might benefit from a decent look at these products, or any open source clones that might be available to test & refine these tricks. Pricing for even a fractional DS3 in the rural US is still very high. Being able to shift bandwidth from a colo facility in a large city to a remote site served by 3 or 4 consumer grade broadband links could be a helpful development, if the bottom line works out. Thanks, Ken > I'm curious if anyone has experience with products from Talari > Networks, or anything similar, and would like to share. Did they > live up to your expectations? Caveats? > -- Ken Anderson Pacific Internet - http://www.pacific.net From ka at pacific.net Thu Mar 12 09:17:48 2009 From: ka at pacific.net (Ken A) Date: Thu, 12 Mar 2009 09:17:48 -0500 Subject: Redundant Array of Inexpensive ISP's? In-Reply-To: <20090310230158.GA19876@tetro.net> References: <20090310230158.GA19876@tetro.net> Message-ID: <49B9198C.1020201@pacific.net> Tim Utschig wrote: > [Please reply off-list. I'll summarize back to the list if there > is more than a little interest in me doing so.] > Please do. There are many rural ISPs and WISPs that might benefit from a decent look at these products, or any open source clones that might be available to test & refine these tricks. Pricing for even a fractional DS3 in the rural US is still very high. Being able to shift bandwidth from a colo facility in a large city to a remote site served by 3 or 4 consumer grade broadband links could be a helpful development, if the bottom line works out. Thanks, Ken > I'm curious if anyone has experience with products from Talari > Networks, or anything similar, and would like to share. Did they > live up to your expectations? Caveats? > -- Ken Anderson Pacific Internet - http://www.pacific.net From jcdill.lists at gmail.com Thu Mar 12 11:02:25 2009 From: jcdill.lists at gmail.com (JC Dill) Date: Thu, 12 Mar 2009 09:02:25 -0700 Subject: Dynamic IP log retention = 0? In-Reply-To: References: Message-ID: <49B93211.1060001@gmail.com> Ross wrote: > I'll try to answer you in a more common sense approach as some have tried > to do. First of all no network operator has to hand over their logs or > user information over to you just because you want to know. There seems to be a big misconception that he asked them to "hand over" the info. As I read the OP, he asked Comcast to do something about it and Comcast said "we can't do anything about it because we don't have logs". Here's a quote from the OP: > I've been nudging an operator at Covad about a handful of hosts from > his DHCP pool that have been attacking - relentlessly port scanning - > our assets. I've been informed by this individual that there's "no > way" to determine which customer had that address at the times I list > in my logs - even though these logs are sent within 48 hours of the > incidents. IMHO, that's a bunch of BS from whoever he's talking with at Comcast. In the normal course of business they would have logs of which customer had that IP just 48 hours earlier. They *can* do something about their customer. And they *should* do something about their customer who is causing problems on another network, the same as if that customer was spewing spam, or actually attacking (DDoS etc.) another network. So the question circles back around to how does the OP get Comcast to step up, internally identify and take care of their problem customer? What path should he take to get connected with someone who has more clue about this type of problem so that they can address it in a timely fashion? Has it come to needing to get a lawyer to write a strongly worded letter just to get this type of thing done today? jc From awacs at ziskind.us Thu Mar 12 11:08:28 2009 From: awacs at ziskind.us (N. Yaakov Ziskind) Date: Thu, 12 Mar 2009 12:08:28 -0400 Subject: Dynamic IP log retention = 0? In-Reply-To: <49B93211.1060001@gmail.com> References: <49B93211.1060001@gmail.com> Message-ID: <20090312120816.B668@egps.egps.com> JC Dill wrote (on Thu, Mar 12, 2009 at 09:02:25AM -0700): > Ross wrote: > > There seems to be a big misconception that he asked them to "hand over" > the info. As I read the OP, he asked Comcast to do something about it > and Comcast said "we can't do anything about it because we don't have > logs". Here's a quote from the OP: > > >I've been nudging an operator at Covad about a handful of hosts from > >his DHCP pool that have been attacking - relentlessly port scanning - > >our assets. I've been informed by this individual that there's "no > >way" to determine which customer had that address at the times I list > >in my logs - even though these logs are sent within 48 hours of the > >incidents. > > IMHO, that's a bunch of BS from whoever he's talking with at Comcast. > In the normal course of business they would have logs of which customer > had that IP just 48 hours earlier. They *can* do something about their > customer. And they *should* do something about their customer who is > causing problems on another network, the same as if that customer was > spewing spam, or actually attacking (DDoS etc.) another network. > > So the question circles back around to how does the OP get Comcast to > step up, internally identify and take care of their problem customer? > What path should he take to get connected with someone who has more clue > about this type of problem so that they can address it in a timely fashion? > > Has it come to needing to get a lawyer to write a strongly worded letter > just to get this type of thing done today? > > jc [Disclaimer - I am a lawyer, and I write strongly worded letters to pay my bills.] Not to disagree with any of your points, but the OP (which you quoted!) was talking about Covad, while you're bashing Comcast. -- _________________________________________ Nachman Yaakov Ziskind, FSPA, LLM awacs at ziskind.us Attorney and Counselor-at-Law http://ziskind.us Economic Group Pension Services http://egps.com Actuaries and Employee Benefit Consultants From Valdis.Kletnieks at vt.edu Thu Mar 12 11:31:03 2009 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 12 Mar 2009 12:31:03 -0400 Subject: Dynamic IP log retention = 0? In-Reply-To: Your message of "Wed, 11 Mar 2009 07:53:01 -0800." <20090311155301.GA99262@blazingdot.com> References: <49B7CDC6.8070304@gmail.com> <20090311155301.GA99262@blazingdot.com> Message-ID: <50821.1236875463@turing-police.cc.vt.edu> On Wed, 11 Mar 2009 07:53:01 -0800, Marcus Reid said: > A quick scan of the reverse mapping for your address space in DNS reveals > that you have basically your entire network on public addresses. No wonder > you're worried about portscans when the printer down the hall and the > receptionists machine are sitting on public addresses. I think you are > trying to secure your network from the wrong end here. You *do* realize that "has a public address" does not actually mean that the machine is reachable from random addresses, right? There *are* these nice utilities called iptables and ipf - even Windows and Macs can be configured to say "bugger off" to unwanted traffic. And you can put a firewall appliance inline without using NAT as well. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From mike at rockynet.com Thu Mar 12 11:52:48 2009 From: mike at rockynet.com (Mike Lewinski) Date: Thu, 12 Mar 2009 10:52:48 -0600 Subject: Dynamic IP log retention = 0? In-Reply-To: <50821.1236875463@turing-police.cc.vt.edu> References: <49B7CDC6.8070304@gmail.com> <20090311155301.GA99262@blazingdot.com> <50821.1236875463@turing-police.cc.vt.edu> Message-ID: <49B93DE0.3010909@rockynet.com> Valdis.Kletnieks at vt.edu wrote: > You *do* realize that "has a public address" does not actually mean that > the machine is reachable from random addresses, right? There *are* these > nice utilities called iptables and ipf - even Windows and Macs can be configured > to say "bugger off" to unwanted traffic. And you can put a firewall appliance > inline without using NAT as well. The other big benefit to using real public IPs is abuse related. There's a scenario we encounter on a semi-regular basis where we forward a report of an apparently infected host to a customer who responds back: "How can I tell which one of our hosts is infected? We've got 200 workstations inside our NAT and this abuse report only has our single public address." So I recommend a packet sniffer inside their LAN or accounting on their firewall. But sometimes the source is a salesperson's laptop, and they've gone on a business trip. So no new reports come in and everyone decides it must have been a false alarm. Now imagine that salesperson only stops back in the office once a month, at random undocumented intervals to make backups. How do we ever track him down? The abuse report cycle just doesn't turn around fast enough - often we don't even get reports for a day or two. So I find myself advising customers in this situation to give every user a public IP. Even if they still do 1:1 NAT, the problem is mostly resolved provided they faithfully document MAC addresses and keep DHCP logs for a suitable length of time. Mike From sil at infiltrated.net Thu Mar 12 11:53:13 2009 From: sil at infiltrated.net (J. Oquendo) Date: Thu, 12 Mar 2009 11:53:13 -0500 Subject: Dynamic IP log retention = 0? In-Reply-To: <49B81769.9080106@gdt.id.au> References: <49B7CDC6.8070304@gmail.com> <49B81769.9080106@gdt.id.au> Message-ID: <20090312165313.GC91005@infiltrated.net> On Thu, 12 Mar 2009, Glen Turner wrote: > William Allen Simpson wrote: > > A telecommunications carrier releasing a customer's details without their > permission, to a non-investigatory third party, without a court order. > Hmmm. It's certainly illegal here in Australia. And last I checked wasn't > the US firm Hewlett Packard in trouble for hiring people to do just that? =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ J. Oquendo SGFA, SGFE, C|EH, CNDA, CHFI, OSCP "Enough research will tend to support your conclusions." - Arthur Bloch "A conclusion is the place where you got tired of thinking" - Arthur Bloch 227C 5D35 7DCB 0893 95AA 4771 1DCE 1FD1 5CCD 6B5E http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x5CCD6B5E From leo.vegoda at icann.org Thu Mar 12 12:27:26 2009 From: leo.vegoda at icann.org (Leo Vegoda) Date: Thu, 12 Mar 2009 10:27:26 -0700 Subject: Four blocks of AS Numbers allocated Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, The IANA AS Numbers registry has been updated to reflect the allocation of four blocks of AS Numbers recently. 49152-50175 Assigned by RIPE NCC whois.ripe.net 2009-03-06 50176-51199 Assigned by RIPE NCC whois.ripe.net 2009-03-06 51200-52223 Assigned by RIPE NCC whois.ripe.net 2009-03-06 52224-53247 Assigned by LACNIC whois.lacnic.net 2009-03-11 The registry can be found at: http://www.iana.org/assignments/as-numbers/as-numbers.xml Regards, Leo Vegoda Number Resources Manager, IANA -----BEGIN PGP SIGNATURE----- Version: 9.9.1.287 wj8DBQFJuUXxvBLymJnAzRwRAkgiAJ4gPAIF9egizyMbGGB/2MAciOCsdQCfXQfX N4gRb5lyNjDDcKZ4bhf5AqY= =LKc/ -----END PGP SIGNATURE----- From tpg at bluegrass.net Thu Mar 12 14:23:43 2009 From: tpg at bluegrass.net (Thomas P. Galla) Date: Thu, 12 Mar 2009 15:23:43 -0400 Subject: microsoft please contact me off list Message-ID: Can a person in charge contact me off list mail:~ $ whois -h whois.arin.net 131.107.65.41 OrgName: Microsoft Corp OrgID: MSFT Address: One Microsoft Way City: Redmond StateProv: WA PostalCode: 98052 Country: US NetRange: 131.107.0.0 - 131.107.255.255 CIDR: 131.107.0.0/16 NetName: MICROSOFT NetHandle: NET-131-107-0-0-1 Parent: NET-131-0-0-0-0 NetType: Direct Assignment NameServer: NS1.MSFT.NET NameServer: NS5.MSFT.NET NameServer: NS2.MSFT.NET NameServer: NS3.MSFT.NET NameServer: NS4.MSFT.NET Comment: RegDate: 1988-11-11 Updated: 2004-12-09 RTechHandle: ZM39-ARIN RTechName: Microsoft RTechPhone: +1-425-882-8080 RTechEmail: noc at microsoft.com OrgAbuseHandle: ABUSE231-ARIN OrgAbuseName: Abuse OrgAbusePhone: +1-425-882-8080 OrgAbuseEmail: abuse at msn.com OrgAbuseHandle: HOTMA-ARIN OrgAbuseName: Hotmail Abuse OrgAbusePhone: +1-425-882-8080 OrgAbuseEmail: abuse at hotmail.com OrgAbuseHandle: MSNAB-ARIN OrgAbuseName: MSN ABUSE OrgAbusePhone: +1-425-882-8080 OrgAbuseEmail: abuse at msn.com OrgNOCHandle: ZM23-ARIN OrgNOCName: Microsoft Corporation OrgNOCPhone: +1-425-882-8080 OrgNOCEmail: noc at microsoft.com OrgTechHandle: MSFTP-ARIN OrgTechName: MSFT-POC OrgTechPhone: +1-425-882-8080 OrgTechEmail: iprrms at microsoft.com # ARIN WHOIS database, last updated 2009-03-11 19:10 # Enter ? for additional hints on searching ARIN's WHOIS database. mail:~ $ whois -h whois.arin.net 131.107.65.41 Thomas P Galla tpg at bluegrass.net BluegrassNet Voice (502) 589.INET [4638] Fax 502-315-0581 321 East Breckinridge St Louisville KY 40203 From tpg at bluegrass.net Thu Mar 12 14:35:20 2009 From: tpg at bluegrass.net (Thomas P. Galla) Date: Thu, 12 Mar 2009 15:35:20 -0400 Subject: microsoft please contact me off list In-Reply-To: References: Message-ID: Sorry I am getting dos attacked from below and it would be nice if microsoft working abuse ph# or noc# or a name ? Thomas P Galla tpg at bluegrass.net BluegrassNet Voice (502) 589.INET [4638] Fax 502-315-0581 321 East Breckinridge St Louisville KY 40203 -----Original Message----- From: Thomas P. Galla [mailto:tpg at bluegrass.net] Sent: Thursday, March 12, 2009 3:24 PM To: nanog at nanog.org Subject: microsoft please contact me off list Can a person in charge contact me off list mail:~ $ whois -h whois.arin.net 131.107.65.41 OrgName: Microsoft Corp OrgID: MSFT Address: One Microsoft Way City: Redmond StateProv: WA PostalCode: 98052 Country: US NetRange: 131.107.0.0 - 131.107.255.255 CIDR: 131.107.0.0/16 NetName: MICROSOFT NetHandle: NET-131-107-0-0-1 Parent: NET-131-0-0-0-0 NetType: Direct Assignment NameServer: NS1.MSFT.NET NameServer: NS5.MSFT.NET NameServer: NS2.MSFT.NET NameServer: NS3.MSFT.NET NameServer: NS4.MSFT.NET Comment: RegDate: 1988-11-11 Updated: 2004-12-09 RTechHandle: ZM39-ARIN RTechName: Microsoft RTechPhone: +1-425-882-8080 RTechEmail: noc at microsoft.com OrgAbuseHandle: ABUSE231-ARIN OrgAbuseName: Abuse OrgAbusePhone: +1-425-882-8080 OrgAbuseEmail: abuse at msn.com OrgAbuseHandle: HOTMA-ARIN OrgAbuseName: Hotmail Abuse OrgAbusePhone: +1-425-882-8080 OrgAbuseEmail: abuse at hotmail.com OrgAbuseHandle: MSNAB-ARIN OrgAbuseName: MSN ABUSE OrgAbusePhone: +1-425-882-8080 OrgAbuseEmail: abuse at msn.com OrgNOCHandle: ZM23-ARIN OrgNOCName: Microsoft Corporation OrgNOCPhone: +1-425-882-8080 OrgNOCEmail: noc at microsoft.com OrgTechHandle: MSFTP-ARIN OrgTechName: MSFT-POC OrgTechPhone: +1-425-882-8080 OrgTechEmail: iprrms at microsoft.com # ARIN WHOIS database, last updated 2009-03-11 19:10 # Enter ? for additional hints on searching ARIN's WHOIS database. mail:~ $ whois -h whois.arin.net 131.107.65.41 Thomas P Galla tpg at bluegrass.net BluegrassNet Voice (502) 589.INET [4638] Fax 502-315-0581 321 East Breckinridge St Louisville KY 40203 No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.0.237 / Virus Database: 270.11.5/1979 - Release Date: 03/11/09 20:42:00 From charles at thewybles.com Thu Mar 12 14:40:06 2009 From: charles at thewybles.com (Charles Wyble) Date: Thu, 12 Mar 2009 12:40:06 -0700 Subject: microsoft please contact me off list In-Reply-To: References: Message-ID: <49B96516.1070706@thewybles.com> You are getting dossed from a Microsoft network range? Really? Perhaps they got bit by a worm targeting windows systems? :) Thomas P. Galla wrote: > Sorry I am getting dos attacked from below and it would be nice if microsoft working abuse ph# or noc# or a name ? > > > > Thomas P Galla > tpg at bluegrass.net > BluegrassNet > Voice (502) 589.INET [4638] > Fax 502-315-0581 > 321 East Breckinridge St > Louisville KY 40203 > > > -----Original Message----- > From: Thomas P. Galla [mailto:tpg at bluegrass.net] > Sent: Thursday, March 12, 2009 3:24 PM > To: nanog at nanog.org > Subject: microsoft please contact me off list > > Can a person in charge contact me off list > > > > > mail:~ $ whois -h whois.arin.net 131.107.65.41 > > OrgName: Microsoft Corp > OrgID: MSFT > Address: One Microsoft Way > City: Redmond > StateProv: WA > PostalCode: 98052 > Country: US > > NetRange: 131.107.0.0 - 131.107.255.255 > CIDR: 131.107.0.0/16 > NetName: MICROSOFT > NetHandle: NET-131-107-0-0-1 > Parent: NET-131-0-0-0-0 > NetType: Direct Assignment > NameServer: NS1.MSFT.NET > NameServer: NS5.MSFT.NET > NameServer: NS2.MSFT.NET > NameServer: NS3.MSFT.NET > NameServer: NS4.MSFT.NET > Comment: > RegDate: 1988-11-11 > Updated: 2004-12-09 > > RTechHandle: ZM39-ARIN > RTechName: Microsoft > RTechPhone: +1-425-882-8080 > RTechEmail: noc at microsoft.com > > OrgAbuseHandle: ABUSE231-ARIN > OrgAbuseName: Abuse > OrgAbusePhone: +1-425-882-8080 > OrgAbuseEmail: abuse at msn.com > > OrgAbuseHandle: HOTMA-ARIN > OrgAbuseName: Hotmail Abuse > OrgAbusePhone: +1-425-882-8080 > OrgAbuseEmail: abuse at hotmail.com > > OrgAbuseHandle: MSNAB-ARIN > OrgAbuseName: MSN ABUSE > OrgAbusePhone: +1-425-882-8080 > OrgAbuseEmail: abuse at msn.com > > OrgNOCHandle: ZM23-ARIN > OrgNOCName: Microsoft Corporation > OrgNOCPhone: +1-425-882-8080 > OrgNOCEmail: noc at microsoft.com > > OrgTechHandle: MSFTP-ARIN > OrgTechName: MSFT-POC > OrgTechPhone: +1-425-882-8080 > OrgTechEmail: iprrms at microsoft.com > > # ARIN WHOIS database, last updated 2009-03-11 19:10 > # Enter ? for additional hints on searching ARIN's WHOIS database. > mail:~ $ whois -h whois.arin.net 131.107.65.41 > > > > > > Thomas P Galla > tpg at bluegrass.net > BluegrassNet > Voice (502) 589.INET [4638] > Fax 502-315-0581 > 321 East Breckinridge St > Louisville KY 40203 > > > > > No virus found in this incoming message. > Checked by AVG - www.avg.com > Version: 8.0.237 / Virus Database: 270.11.5/1979 - Release Date: 03/11/09 20:42:00 > -- Charles N Wyble charles at thewybles.com (818)280-7059 http://charlesnw.blogspot.com CTO SocalWiFI.net From chris.ranch at nokia.com Thu Mar 12 14:54:57 2009 From: chris.ranch at nokia.com (chris.ranch at nokia.com) Date: Thu, 12 Mar 2009 20:54:57 +0100 Subject: microsoft please contact me off list In-Reply-To: <49B96516.1070706@thewybles.com> References: <49B96516.1070706@thewybles.com> Message-ID: More likely spoofed sources. Good luck. >-----Original Message----- >From: ext Charles Wyble [mailto:charles at thewybles.com] >Sent: Thursday, March 12, 2009 12:40 PM >To: Thomas P. Galla >Cc: nanog at nanog.org >Subject: Re: microsoft please contact me off list > >You are getting dossed from a Microsoft network range? Really? >Perhaps they got bit by a worm targeting windows systems? :) > > > >Thomas P. Galla wrote: >> Sorry I am getting dos attacked from below and it would be >nice if microsoft working abuse ph# or noc# or a name ? >> >> >> >> Thomas P Galla >> tpg at bluegrass.net >> BluegrassNet >> Voice (502) 589.INET [4638] >> Fax 502-315-0581 >> 321 East Breckinridge St >> Louisville KY 40203 >> >> >> -----Original Message----- >> From: Thomas P. Galla [mailto:tpg at bluegrass.net] >> Sent: Thursday, March 12, 2009 3:24 PM >> To: nanog at nanog.org >> Subject: microsoft please contact me off list >> >> Can a person in charge contact me off list >> >> >> >> >> mail:~ $ whois -h whois.arin.net 131.107.65.41 >> >> OrgName: Microsoft Corp >> OrgID: MSFT >> Address: One Microsoft Way >> City: Redmond >> StateProv: WA >> PostalCode: 98052 >> Country: US >> >> NetRange: 131.107.0.0 - 131.107.255.255 >> CIDR: 131.107.0.0/16 >> NetName: MICROSOFT >> NetHandle: NET-131-107-0-0-1 >> Parent: NET-131-0-0-0-0 >> NetType: Direct Assignment >> NameServer: NS1.MSFT.NET >> NameServer: NS5.MSFT.NET >> NameServer: NS2.MSFT.NET >> NameServer: NS3.MSFT.NET >> NameServer: NS4.MSFT.NET >> Comment: >> RegDate: 1988-11-11 >> Updated: 2004-12-09 >> >> RTechHandle: ZM39-ARIN >> RTechName: Microsoft >> RTechPhone: +1-425-882-8080 >> RTechEmail: noc at microsoft.com >> >> OrgAbuseHandle: ABUSE231-ARIN >> OrgAbuseName: Abuse >> OrgAbusePhone: +1-425-882-8080 >> OrgAbuseEmail: abuse at msn.com >> >> OrgAbuseHandle: HOTMA-ARIN >> OrgAbuseName: Hotmail Abuse >> OrgAbusePhone: +1-425-882-8080 >> OrgAbuseEmail: abuse at hotmail.com >> >> OrgAbuseHandle: MSNAB-ARIN >> OrgAbuseName: MSN ABUSE >> OrgAbusePhone: +1-425-882-8080 >> OrgAbuseEmail: abuse at msn.com >> >> OrgNOCHandle: ZM23-ARIN >> OrgNOCName: Microsoft Corporation >> OrgNOCPhone: +1-425-882-8080 >> OrgNOCEmail: noc at microsoft.com >> >> OrgTechHandle: MSFTP-ARIN >> OrgTechName: MSFT-POC >> OrgTechPhone: +1-425-882-8080 >> OrgTechEmail: iprrms at microsoft.com >> >> # ARIN WHOIS database, last updated 2009-03-11 19:10 >> # Enter ? for additional hints on searching ARIN's WHOIS database. >> mail:~ $ whois -h whois.arin.net 131.107.65.41 >> >> >> >> >> >> Thomas P Galla >> tpg at bluegrass.net >> BluegrassNet >> Voice (502) 589.INET [4638] >> Fax 502-315-0581 >> 321 East Breckinridge St >> Louisville KY 40203 >> >> >> >> >> No virus found in this incoming message. >> Checked by AVG - www.avg.com >> Version: 8.0.237 / Virus Database: 270.11.5/1979 - Release >Date: 03/11/09 20:42:00 >> > >-- >Charles N Wyble charles at thewybles.com >(818)280-7059 http://charlesnw.blogspot.com >CTO SocalWiFI.net > > From joey at networkbit.com Thu Mar 12 15:00:42 2009 From: joey at networkbit.com (Joey Boyer) Date: Thu, 12 Mar 2009 13:00:42 -0700 Subject: microsoft please contact me off list In-Reply-To: References: <49B96516.1070706@thewybles.com> Message-ID: <6d2cdaf50903121300t31df6ab3mbace22936f1a739@mail.gmail.com> He's gonna need it! On Thu, Mar 12, 2009 at 12:54 PM, wrote: > More likely spoofed sources. > > Good luck. > > >>-----Original Message----- >>From: ext Charles Wyble [mailto:charles at thewybles.com] >>Sent: Thursday, March 12, 2009 12:40 PM >>To: Thomas P. Galla >>Cc: nanog at nanog.org >>Subject: Re: microsoft please contact me off list >> >>You are getting dossed from a Microsoft network range? Really? >>Perhaps they got bit by a worm targeting windows systems? :) >> >> >> >>Thomas P. Galla wrote: >>> Sorry I am getting dos attacked from below and it would be >>nice if microsoft working abuse ph# or noc# or a name ? >>> >>> >>> >>> Thomas P Galla >>> tpg at bluegrass.net >>> BluegrassNet >>> Voice (502) 589.INET [4638] >>> Fax 502-315-0581 >>> 321 East Breckinridge St >>> Louisville KY 40203 >>> >>> >>> -----Original Message----- >>> From: Thomas P. Galla [mailto:tpg at bluegrass.net] >>> Sent: Thursday, March 12, 2009 3:24 PM >>> To: nanog at nanog.org >>> Subject: microsoft please contact me off list >>> >>> Can a person in charge contact me off list >>> >>> >>> >>> >>> mail:~ $ whois -h whois.arin.net 131.107.65.41 >>> >>> OrgName: ? ?Microsoft Corp >>> OrgID: ? ? ?MSFT >>> Address: ? ?One Microsoft Way >>> City: ? ? ? Redmond >>> StateProv: ?WA >>> PostalCode: 98052 >>> Country: ? ?US >>> >>> NetRange: ? 131.107.0.0 - 131.107.255.255 >>> CIDR: ? ? ? 131.107.0.0/16 >>> NetName: ? ?MICROSOFT >>> NetHandle: ?NET-131-107-0-0-1 >>> Parent: ? ? NET-131-0-0-0-0 >>> NetType: ? ?Direct Assignment >>> NameServer: NS1.MSFT.NET >>> NameServer: NS5.MSFT.NET >>> NameServer: NS2.MSFT.NET >>> NameServer: NS3.MSFT.NET >>> NameServer: NS4.MSFT.NET >>> Comment: >>> RegDate: ? ?1988-11-11 >>> Updated: ? ?2004-12-09 >>> >>> RTechHandle: ZM39-ARIN >>> RTechName: ? Microsoft >>> RTechPhone: ?+1-425-882-8080 >>> RTechEmail: ?noc at microsoft.com >>> >>> OrgAbuseHandle: ABUSE231-ARIN >>> OrgAbuseName: ? Abuse >>> OrgAbusePhone: ?+1-425-882-8080 >>> OrgAbuseEmail: ?abuse at msn.com >>> >>> OrgAbuseHandle: HOTMA-ARIN >>> OrgAbuseName: ? Hotmail Abuse >>> OrgAbusePhone: ?+1-425-882-8080 >>> OrgAbuseEmail: ?abuse at hotmail.com >>> >>> OrgAbuseHandle: MSNAB-ARIN >>> OrgAbuseName: ? MSN ABUSE >>> OrgAbusePhone: ?+1-425-882-8080 >>> OrgAbuseEmail: ?abuse at msn.com >>> >>> OrgNOCHandle: ZM23-ARIN >>> OrgNOCName: ? Microsoft Corporation >>> OrgNOCPhone: ?+1-425-882-8080 >>> OrgNOCEmail: ?noc at microsoft.com >>> >>> OrgTechHandle: MSFTP-ARIN >>> OrgTechName: ? MSFT-POC >>> OrgTechPhone: ?+1-425-882-8080 >>> OrgTechEmail: ?iprrms at microsoft.com >>> >>> # ARIN WHOIS database, last updated 2009-03-11 19:10 >>> # Enter ? for additional hints on searching ARIN's WHOIS database. >>> mail:~ $ whois -h whois.arin.net 131.107.65.41 >>> >>> >>> >>> >>> >>> Thomas P Galla >>> tpg at bluegrass.net >>> BluegrassNet >>> Voice (502) 589.INET [4638] >>> Fax 502-315-0581 >>> 321 East Breckinridge St >>> Louisville KY 40203 >>> >>> >>> >>> >>> No virus found in this incoming message. >>> Checked by AVG - www.avg.com >>> Version: 8.0.237 / Virus Database: 270.11.5/1979 - Release >>Date: 03/11/09 20:42:00 >>> >> >>-- >>Charles N Wyble charles at thewybles.com >>(818)280-7059 http://charlesnw.blogspot.com >>CTO SocalWiFI.net >> >> > From william.allen.simpson at gmail.com Thu Mar 12 15:10:48 2009 From: william.allen.simpson at gmail.com (William Allen Simpson) Date: Thu, 12 Mar 2009 16:10:48 -0400 Subject: Dynamic IP log retention = 0? In-Reply-To: <20090312165313.GC91005@infiltrated.net> References: <49B7CDC6.8070304@gmail.com> <49B81769.9080106@gdt.id.au> <20090312165313.GC91005@infiltrated.net> Message-ID: <49B96C48.8020908@gmail.com> J. Oquendo wrote: > On Thu, 12 Mar 2009, Glen Turner wrote: > >> William Allen Simpson wrote: >> >> A telecommunications carrier releasing a customer's details without their >> permission, to a non-investigatory third party, without a court order. >> Hmmm. It's certainly illegal here in Australia. And last I checked wasn't >> the US firm Hewlett Packard in trouble for hiring people to do just that? > Hey, bad quotation! I'm not from Australia. That's not my writing. Nor did I ever advocate releasing a customer's details -- to anybody. :-( I also disagree with your point about responsibilities of ISPs. Yes, it's true that Microsoft externalized its costs upon its customers. But only the ISPs are in a position to detect the abuse, and that's part of the business. Some of us take network security seriously. From charles at thewybles.com Thu Mar 12 15:11:22 2009 From: charles at thewybles.com (Charles Wyble) Date: Thu, 12 Mar 2009 13:11:22 -0700 Subject: microsoft please contact me off list In-Reply-To: References: <49B96516.1070706@thewybles.com> Message-ID: <49B96C6A.1090100@thewybles.com> Yes I agree. I forgot to do the *raises an incredulous eyebrow* bit. :) By the way.... try calling that number and reaching an operator then asking for the NOC. chris.ranch at nokia.com wrote: > More likely spoofed sources. > > Good luck. > > From Valdis.Kletnieks at vt.edu Thu Mar 12 15:14:45 2009 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 12 Mar 2009 16:14:45 -0400 Subject: microsoft please contact me off list In-Reply-To: Your message of "Thu, 12 Mar 2009 12:40:06 PDT." <49B96516.1070706@thewybles.com> References: <49B96516.1070706@thewybles.com> Message-ID: <60954.1236888885@turing-police.cc.vt.edu> On Thu, 12 Mar 2009 12:40:06 PDT, Charles Wyble said: > You are getting dossed from a Microsoft network range? Really? Perhaps > they got bit by a worm targeting windows systems? :) You mean like this? http://www.theregister.co.uk/2001/07/20/code_red_bug_hits_microsoft/ (To be fair, screw-ups happen at *all* vendors eventually - the RedHat/Fedora crew had a small "whoops!" with the system that digitally signs their RPM packages a while ago. Just proves that security is harder to get right than a lot of people think...) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From jeffshultz at wvi.com Thu Mar 12 16:16:26 2009 From: jeffshultz at wvi.com (Jeff Shultz) Date: Thu, 12 Mar 2009 14:16:26 -0700 Subject: microsoft please contact me off list In-Reply-To: References: Message-ID: <49B97BAA.6010009@wvi.com> In our case we didn't bother with where it was coming from - our router guy figured out where it was going to - and had that IP shut down a couple levels away from us. Thomas P. Galla wrote: > Sorry I am getting dos attacked from below and it would be nice if microsoft working abuse ph# or noc# or a name ? > > > > Thomas P Galla > tpg at bluegrass.net > BluegrassNet > Voice (502) 589.INET [4638] > Fax 502-315-0581 > 321 East Breckinridge St > Louisville KY 40203 > > > -----Original Message----- > From: Thomas P. Galla [mailto:tpg at bluegrass.net] > Sent: Thursday, March 12, 2009 3:24 PM > To: nanog at nanog.org > Subject: microsoft please contact me off list > > Can a person in charge contact me off list > > > > > mail:~ $ whois -h whois.arin.net 131.107.65.41 > > OrgName: Microsoft Corp > OrgID: MSFT > Address: One Microsoft Way > City: Redmond > StateProv: WA > PostalCode: 98052 > Country: US > > NetRange: 131.107.0.0 - 131.107.255.255 > CIDR: 131.107.0.0/16 > NetName: MICROSOFT > NetHandle: NET-131-107-0-0-1 > Parent: NET-131-0-0-0-0 > NetType: Direct Assignment > NameServer: NS1.MSFT.NET > NameServer: NS5.MSFT.NET > NameServer: NS2.MSFT.NET > NameServer: NS3.MSFT.NET > NameServer: NS4.MSFT.NET > Comment: > RegDate: 1988-11-11 > Updated: 2004-12-09 > > RTechHandle: ZM39-ARIN > RTechName: Microsoft > RTechPhone: +1-425-882-8080 > RTechEmail: noc at microsoft.com > > OrgAbuseHandle: ABUSE231-ARIN > OrgAbuseName: Abuse > OrgAbusePhone: +1-425-882-8080 > OrgAbuseEmail: abuse at msn.com > > OrgAbuseHandle: HOTMA-ARIN > OrgAbuseName: Hotmail Abuse > OrgAbusePhone: +1-425-882-8080 > OrgAbuseEmail: abuse at hotmail.com > > OrgAbuseHandle: MSNAB-ARIN > OrgAbuseName: MSN ABUSE > OrgAbusePhone: +1-425-882-8080 > OrgAbuseEmail: abuse at msn.com > > OrgNOCHandle: ZM23-ARIN > OrgNOCName: Microsoft Corporation > OrgNOCPhone: +1-425-882-8080 > OrgNOCEmail: noc at microsoft.com > > OrgTechHandle: MSFTP-ARIN > OrgTechName: MSFT-POC > OrgTechPhone: +1-425-882-8080 > OrgTechEmail: iprrms at microsoft.com > > # ARIN WHOIS database, last updated 2009-03-11 19:10 > # Enter ? for additional hints on searching ARIN's WHOIS database. > mail:~ $ whois -h whois.arin.net 131.107.65.41 > > > > > > Thomas P Galla > tpg at bluegrass.net > BluegrassNet > Voice (502) 589.INET [4638] > Fax 502-315-0581 > 321 East Breckinridge St > Louisville KY 40203 > > > > > No virus found in this incoming message. > Checked by AVG - www.avg.com > Version: 8.0.237 / Virus Database: 270.11.5/1979 - Release Date: 03/11/09 20:42:00 > -- Jeff Shultz From Mark_Andrews at isc.org Thu Mar 12 17:26:33 2009 From: Mark_Andrews at isc.org (Mark Andrews) Date: Fri, 13 Mar 2009 09:26:33 +1100 Subject: Dynamic IP log retention = 0? In-Reply-To: Your message of "Thu, 12 Mar 2009 12:08:28 EDT." <20090312120816.B668@egps.egps.com> Message-ID: <200903122226.n2CMQXx3041169@drugs.dv.isc.org> In message <20090312120816.B668 at egps.egps.com>, "N. Yaakov Ziskind" writes: > JC Dill wrote (on Thu, Mar 12, 2009 at 09:02:25AM -0700): > > Ross wrote: > > > > There seems to be a big misconception that he asked them to "hand over" > > the info. As I read the OP, he asked Comcast to do something about it > > and Comcast said "we can't do anything about it because we don't have > > logs". Here's a quote from the OP: The real problem is that Covad claim (second hand) that they can't identify the perpetrator(s). I've been nudging an operator at Covad about a handful of hosts from his DHCP pool that have been attacking - relentlessly port scanning - our assets. I've been informed by this individual that there's "no way" to determine which customer had that address at the times I list in my logs - even though these logs are sent within 48 hours of the incidents. One shouldn't need to have to get the indentities of the perpetrators to get AUP enforced. Port scanning is against 99.9% of AUP's. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews at isc.org From tpg at bluegrass.net Thu Mar 12 17:24:14 2009 From: tpg at bluegrass.net (Thomas P. Galla) Date: Thu, 12 Mar 2009 18:24:14 -0400 Subject: FYI RE: microsoft please contact me off list In-Reply-To: References: Message-ID: Here is what I got back.... OBTW thanx Thomas ============================= Sent: Thursday, March 12, 2009 4:22 PM To: Thomas P. Galla Subject: FW: microsoft please contact me off list Importance: High Thomas, I work in the research group managing the network range that you are reporting. Your network could be randomly included Honeymonkey(http://en.wikipedia.org/wiki/HoneyMonkey) or another research project(http://research.microsoft.com/en-us/um/redmond/projects/strider). Could you give me more details on what you are seeing or the IP range on your side that is being hit? Thx Steve Thomas P Galla tpg at bluegrass.net BluegrassNet Voice (502) 589.INET [4638] Fax 502-315-0581 321 East Breckinridge St Louisville KY 40203 -----Original Message----- From: Thomas P. Galla [mailto:tpg at bluegrass.net] Sent: Thursday, March 12, 2009 3:35 PM To: nanog at nanog.org Subject: RE: microsoft please contact me off list Sorry I am getting dos attacked from below and it would be nice if microsoft working abuse ph# or noc# or a name ? Thomas P Galla tpg at bluegrass.net BluegrassNet Voice (502) 589.INET [4638] Fax 502-315-0581 321 East Breckinridge St Louisville KY 40203 -----Original Message----- From: Thomas P. Galla [mailto:tpg at bluegrass.net] Sent: Thursday, March 12, 2009 3:24 PM To: nanog at nanog.org Subject: microsoft please contact me off list Can a person in charge contact me off list mail:~ $ whois -h whois.arin.net 131.107.65.41 OrgName: Microsoft Corp OrgID: MSFT Address: One Microsoft Way City: Redmond StateProv: WA PostalCode: 98052 Country: US NetRange: 131.107.0.0 - 131.107.255.255 CIDR: 131.107.0.0/16 NetName: MICROSOFT NetHandle: NET-131-107-0-0-1 Parent: NET-131-0-0-0-0 NetType: Direct Assignment NameServer: NS1.MSFT.NET NameServer: NS5.MSFT.NET NameServer: NS2.MSFT.NET NameServer: NS3.MSFT.NET NameServer: NS4.MSFT.NET Comment: RegDate: 1988-11-11 Updated: 2004-12-09 RTechHandle: ZM39-ARIN RTechName: Microsoft RTechPhone: +1-425-882-8080 RTechEmail: noc at microsoft.com OrgAbuseHandle: ABUSE231-ARIN OrgAbuseName: Abuse OrgAbusePhone: +1-425-882-8080 OrgAbuseEmail: abuse at msn.com OrgAbuseHandle: HOTMA-ARIN OrgAbuseName: Hotmail Abuse OrgAbusePhone: +1-425-882-8080 OrgAbuseEmail: abuse at hotmail.com OrgAbuseHandle: MSNAB-ARIN OrgAbuseName: MSN ABUSE OrgAbusePhone: +1-425-882-8080 OrgAbuseEmail: abuse at msn.com OrgNOCHandle: ZM23-ARIN OrgNOCName: Microsoft Corporation OrgNOCPhone: +1-425-882-8080 OrgNOCEmail: noc at microsoft.com OrgTechHandle: MSFTP-ARIN OrgTechName: MSFT-POC OrgTechPhone: +1-425-882-8080 OrgTechEmail: iprrms at microsoft.com # ARIN WHOIS database, last updated 2009-03-11 19:10 # Enter ? for additional hints on searching ARIN's WHOIS database. mail:~ $ whois -h whois.arin.net 131.107.65.41 Thomas P Galla tpg at bluegrass.net BluegrassNet Voice (502) 589.INET [4638] Fax 502-315-0581 321 East Breckinridge St Louisville KY 40203 No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.0.237 / Virus Database: 270.11.5/1979 - Release Date: 03/11/09 20:42:00 No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.0.237 / Virus Database: 270.11.5/1979 - Release Date: 03/11/09 20:42:00 From charles at thewybles.com Thu Mar 12 17:36:13 2009 From: charles at thewybles.com (Charles Wyble) Date: Thu, 12 Mar 2009 15:36:13 -0700 Subject: FYI RE: microsoft please contact me off list In-Reply-To: References: Message-ID: <49B98E5D.70008@thewybles.com> What were the traffic characteristics that lead you to believe you were under a DDOS attack? Thomas P. Galla wrote: > Here is what I got back.... OBTW thanx > > Thomas > > > ============================= > > Sent: Thursday, March 12, 2009 4:22 PM > To: Thomas P. Galla > Subject: FW: microsoft please contact me off list > Importance: High > > Thomas, > > I work in the research group managing the network range that you are reporting. Your network could be randomly included Honeymonkey(http://en.wikipedia.org/wiki/HoneyMonkey) or another research project(http://research.microsoft.com/en-us/um/redmond/projects/strider). Could you give me more details on what you are seeing or the IP range on your side that is being hit? > > Thx > Steve > > > > Thomas P Galla > tpg at bluegrass.net > BluegrassNet > Voice (502) 589.INET [4638] > Fax 502-315-0581 > 321 East Breckinridge St > Louisville KY 40203 > > > -----Original Message----- > From: Thomas P. Galla [mailto:tpg at bluegrass.net] > Sent: Thursday, March 12, 2009 3:35 PM > To: nanog at nanog.org > Subject: RE: microsoft please contact me off list > > Sorry I am getting dos attacked from below and it would be nice if microsoft working abuse ph# or noc# or a name ? > > > > Thomas P Galla > tpg at bluegrass.net > BluegrassNet > Voice (502) 589.INET [4638] > Fax 502-315-0581 > 321 East Breckinridge St > Louisville KY 40203 > > > -----Original Message----- > From: Thomas P. Galla [mailto:tpg at bluegrass.net] > Sent: Thursday, March 12, 2009 3:24 PM > To: nanog at nanog.org > Subject: microsoft please contact me off list > > Can a person in charge contact me off list > > > > > mail:~ $ whois -h whois.arin.net 131.107.65.41 > > OrgName: Microsoft Corp > OrgID: MSFT > Address: One Microsoft Way > City: Redmond > StateProv: WA > PostalCode: 98052 > Country: US > > NetRange: 131.107.0.0 - 131.107.255.255 > CIDR: 131.107.0.0/16 > NetName: MICROSOFT > NetHandle: NET-131-107-0-0-1 > Parent: NET-131-0-0-0-0 > NetType: Direct Assignment > NameServer: NS1.MSFT.NET > NameServer: NS5.MSFT.NET > NameServer: NS2.MSFT.NET > NameServer: NS3.MSFT.NET > NameServer: NS4.MSFT.NET > Comment: > RegDate: 1988-11-11 > Updated: 2004-12-09 > > RTechHandle: ZM39-ARIN > RTechName: Microsoft > RTechPhone: +1-425-882-8080 > RTechEmail: noc at microsoft.com > > OrgAbuseHandle: ABUSE231-ARIN > OrgAbuseName: Abuse > OrgAbusePhone: +1-425-882-8080 > OrgAbuseEmail: abuse at msn.com > > OrgAbuseHandle: HOTMA-ARIN > OrgAbuseName: Hotmail Abuse > OrgAbusePhone: +1-425-882-8080 > OrgAbuseEmail: abuse at hotmail.com > > OrgAbuseHandle: MSNAB-ARIN > OrgAbuseName: MSN ABUSE > OrgAbusePhone: +1-425-882-8080 > OrgAbuseEmail: abuse at msn.com > > OrgNOCHandle: ZM23-ARIN > OrgNOCName: Microsoft Corporation > OrgNOCPhone: +1-425-882-8080 > OrgNOCEmail: noc at microsoft.com > > OrgTechHandle: MSFTP-ARIN > OrgTechName: MSFT-POC > OrgTechPhone: +1-425-882-8080 > OrgTechEmail: iprrms at microsoft.com > > # ARIN WHOIS database, last updated 2009-03-11 19:10 > # Enter ? for additional hints on searching ARIN's WHOIS database. > mail:~ $ whois -h whois.arin.net 131.107.65.41 > > > > > > Thomas P Galla > tpg at bluegrass.net > BluegrassNet > Voice (502) 589.INET [4638] > Fax 502-315-0581 > 321 East Breckinridge St > Louisville KY 40203 > > > > > No virus found in this incoming message. > Checked by AVG - www.avg.com > Version: 8.0.237 / Virus Database: 270.11.5/1979 - Release Date: 03/11/09 20:42:00 > > > No virus found in this incoming message. > Checked by AVG - www.avg.com > Version: 8.0.237 / Virus Database: 270.11.5/1979 - Release Date: 03/11/09 20:42:00 > -- Charles N Wyble charles at thewybles.com (818)280-7059 http://charlesnw.blogspot.com CTO SocalWiFI.net From ross at dillio.net Thu Mar 12 18:54:33 2009 From: ross at dillio.net (Ross) Date: Thu, 12 Mar 2009 18:54:33 -0500 (CDT) Subject: Dynamic IP log retention = 0? In-Reply-To: <200903122226.n2CMQXx3041169@drugs.dv.isc.org> References: <200903122226.n2CMQXx3041169@drugs.dv.isc.org> Message-ID: Whether Covad chooses to enforce their AUP against port scanning is a business decision up to them. Again, why worry about things out of your control, especially when we are talking about port scanning. I would think people have more pressing issues, guess not. -- Ross ross [at] dillio.net > > In message <20090312120816.B668 at egps.egps.com>, "N. Yaakov Ziskind" > writes: >> JC Dill wrote (on Thu, Mar 12, 2009 at 09:02:25AM -0700): >> > Ross wrote: >> > >> > There seems to be a big misconception that he asked them to "hand >> over" >> > the info. As I read the OP, he asked Covad to do something about it >> > and Covad said "we can't do anything about it because we don't have >> > logs". Here's a quote from the OP: > > The real problem is that Covad claim (second hand) that they can't > identify the perpetrator(s). > > I've been nudging an operator at Covad about a handful of > hosts from his DHCP pool that have been attacking - > relentlessly port scanning - our assets. I've been informed > by this individual that there's "no way" to determine which > customer had that address at the times I list in my logs - > even though these logs are sent within 48 hours of the > incidents. > > One shouldn't need to have to get the indentities of the perpetrators > to get AUP enforced. Port scanning is against 99.9% of AUP's. > > Mark > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews at isc.org > > From jgreco at ns.sol.net Thu Mar 12 19:13:02 2009 From: jgreco at ns.sol.net (Joe Greco) Date: Thu, 12 Mar 2009 18:13:02 -0600 (CST) Subject: Dynamic IP log retention = 0? In-Reply-To: from "Ross" at Mar 12, 2009 06:54:33 PM Message-ID: <200903130013.n2D0D2ao011861@aurora.sol.net> > Whether Covad chooses to enforce their AUP against port scanning is a > business decision up to them. Yes, it's all a business decision. That kind of antisocial thinking is the sort of thing that has allowed all manner of bad guys to remain attached to the Internet. > Again, why worry about things out of your > control, especially when we are talking about port scanning. Yes, why not talk about rapists and drug dealers instead. They're much worse. It's just that this forum ... isn't for that. > I would think people have more pressing issues, guess not. While I am all for increasing overall security on the Internet, the reality is that there will often be devices that are attached that are found to be vulnerable in new and intriguing ways. Port scanning is a primary method for finding these vulnerabilities. To the extent that an ISP might proactively port scan its own userbase, that's a good use and probably a good idea (has tradeoffs), but bad guys finding holes in random devices so that they can launch multiGbps attacks against random destinations is a bad thing. If your idea of "operations" is to make your router work and collect your paycheck for another day, then this discussion probably does not make any sense to you and you probably don't understand the importance of the issue. If your idea of "operations" is to ensure the reliable operation and uphold the performance standards of an IP network, then it should not be beyond comprehension that allowing miscreants access to the network is one of many things that can adversely affect operations. If you accept that the presence of miscreants on the network is a negative, it shouldn't be hard to see that complaining about consistent and persistent port scans from what is probably an identifiable host is one way to make an impact. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From orb7777 at gmail.com Thu Mar 12 19:32:52 2009 From: orb7777 at gmail.com (Jon Orb) Date: Thu, 12 Mar 2009 17:32:52 -0700 Subject: Expert Witness needed for Terry Childs case Message-ID: All: An attorney needs an Expert Witness for the Terry Childs case. I don't know much about the case and I'm not endorsing it in either way, but justice requires a vigorous defense -- and stating facts and acting on behalf of the legal process is always a good thing to participate in. This is a paid job in a high-profile case. The attorney is looking for someone in/near the SF Bay Area who knows routing, WAN, switches, routers -- a CCIE type who would be willing to act as an expert witness in this case. CCIE is not required, but would be very helpful. Also should be expert in security and protecting these types of networks and gear. Here's a summary from the attorney: I am one of the attorneys working on the defense for Terry Childs. His is a very high profile case in San Francisco. He is charged with denial of service attacks on San Francisco's fiber network for city services. He is also charged with keeping a backdoor to hack the network, by virtue of the fact that he had at least one modem hooked up to the network for his monitoring software. He was in fact the administrator who set up the network and simply failed to turn over the passwords to the network machines to his boss, and now he is being held on $5,000,000.00 bail. That is a very simplified account of what happened. Here is an O'Reilly article about the case: http://news.oreilly.com/2008/07/coverage-of-terry-childs.html They initially wanted a CCIE, because Mr. Childs has that certification. I am not sure any particular certification is required. So we need a defense expert to testify about his security practices. Mr. Childs locked out console ports, took passwords out of NVRAM, set up access lists, and did a host of stuff to make sure that no one but him had access to these machines. It is a paid job in this super high profile case. I remember that you, Dave, know all about security. I also thought Bruno might know someone who can help, because I remember that you, Bruno, know a lot about a lot. Can either of you recommend someone? Or would you like to be involved? The trial date is fast approaching. I look forward to hearing back from you guys. ======================================================================= If you can assist, let me know and I'll get you in touch with the attorney. From internetplumber at gmail.com Thu Mar 12 19:32:59 2009 From: internetplumber at gmail.com (Rob Evans) Date: Fri, 13 Mar 2009 00:32:59 +0000 Subject: Dynamic IP log retention = 0? In-Reply-To: <20090312120816.B668@egps.egps.com> References: <49B93211.1060001@gmail.com> <20090312120816.B668@egps.egps.com> Message-ID: <9a8fa98b0903121732t1b0dddf6gc3e2887af5c0bd2d@mail.gmail.com> > Not to disagree with any of your points, but the OP (which you quoted!) > was talking about Covad, while you're bashing Comcast. Any sufficiently advanced NANOG conversation is indistinguishable from Comcast-bashing. Rob (Not agreeing, just observing.) From Mark_Andrews at isc.org Thu Mar 12 19:33:22 2009 From: Mark_Andrews at isc.org (Mark Andrews) Date: Fri, 13 Mar 2009 11:33:22 +1100 Subject: Dynamic IP log retention = 0? In-Reply-To: Your message of "Thu, 12 Mar 2009 18:54:33 CDT." Message-ID: <200903130033.n2D0XMBf042996@drugs.dv.isc.org> In message , "Ross" writ es: > Whether Covad chooses to enforce their AUP against port scanning is a > business decision up to them. Again, why worry about things out of your > control, especially when we are talking about port scanning. I would think > people have more pressing issues, guess not. > > -- > Ross > ross [at] dillio.net Well most port scanning is from compromised boxes. Once a box is compromised it can be used for *any* sort of attack. If you really care about security you take reports of ports scans seriously. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews at isc.org From jgreco at ns.sol.net Thu Mar 12 19:52:45 2009 From: jgreco at ns.sol.net (Joe Greco) Date: Thu, 12 Mar 2009 18:52:45 -0600 (CST) Subject: Dynamic IP log retention = 0? In-Reply-To: <200903130033.n2D0XMBf042996@drugs.dv.isc.org> from "Mark Andrews" at Mar 13, 2009 11:33:22 AM Message-ID: <200903130052.n2D0qjW9013061@aurora.sol.net> > Well most port scanning is from compromised boxes. Once a > box is compromised it can be used for *any* sort of attack. > If you really care about security you take reports of ports > scans seriously. Yeahbut, the real problem is that port scanning is typically used as part of a process to infect _other_ boxes. If you allow this sort of illness to spread, the patient (that is, the Internet) doesn't get better. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From jcdill.lists at gmail.com Thu Mar 12 20:50:00 2009 From: jcdill.lists at gmail.com (JC Dill) Date: Thu, 12 Mar 2009 18:50:00 -0700 Subject: Dynamic IP log retention = 0? In-Reply-To: <20090312120816.B668@egps.egps.com> References: <49B93211.1060001@gmail.com> <20090312120816.B668@egps.egps.com> Message-ID: <49B9BBC8.3050607@gmail.com> N. Yaakov Ziskind wrote: > > Not to disagree with any of your points, but the OP (which you quoted!) > was talking about Covad, while you're bashing Comcast. > > Oops, my bad. Well, and Covad's bad too. :-) jc From martin at theicelandguy.com Thu Mar 12 23:23:02 2009 From: martin at theicelandguy.com (Martin Hannigan) Date: Fri, 13 Mar 2009 00:23:02 -0400 Subject: Dynamic IP log retention = 0? In-Reply-To: <200903130052.n2D0qjW9013061@aurora.sol.net> References: <200903130033.n2D0XMBf042996@drugs.dv.isc.org> <200903130052.n2D0qjW9013061@aurora.sol.net> Message-ID: On Thu, Mar 12, 2009 at 8:52 PM, Joe Greco wrote: > > Well most port scanning is from compromised boxes. Once a > > box is compromised it can be used for *any* sort of attack. > > If you really care about security you take reports of ports > > scans seriously. > > Yeahbut, the real problem is that port scanning is typically used as > part of a process to infect _other_ boxes. If you allow this sort of > illness to spread, the patient (that is, the Internet) doesn't get > better. > > Port scanning is the Internet equivelant of the common cold. They're a dime a dozen. I recommend taking some Vitamin B and D. Block, and Drop. Best, Martin -- Martin Hannigan martin at theicelandguy.com p: +16178216079 From Sam.Crooks at experian.com Fri Mar 13 00:20:41 2009 From: Sam.Crooks at experian.com (Crooks, Sam) Date: Fri, 13 Mar 2009 00:20:41 -0500 Subject: Redundant Array of Inexpensive ISP's? In-Reply-To: <49B9198C.1020201@pacific.net> Message-ID: In answer to a question below about experience with similar products... Cisco IOS has the dynamic routing injection feature as part of recent IOS versions. The feature is now called Performance Routing (PfR) formerly known as OER (Optimized Edge Routing) and as of 12.4(24)T, it can optimize routing protocols other than BGP or static routes (called PIRO Protocol Independent Route Optimization), including IS-IS, OSPF and EIGRP. RIP folks should learn about routing protocols :-D PfR does not do compressions/tokenization of the data, so it has no Caching/compression/WAN Acceleration features, BUT it does do dynamic path re-routing based on your policy or observed metrics like latency, packet loss, jitter etc and can also do it based on observed Netflow data and automatic instatiation of IP SLA active probes to see what happens for a RTP data stream marked with dscp 46 or video stream marked with dscp 34 and so on. As of recent IOS versions (12,4(9)T + I think), it can control both inbound and outbound directions, and can do things like send your traffic to ISP X up to bandwidth Bx and then shift traffic over to ISP Y up to bandwidth By to do dynamic load sharing of traffic to IP transit commit levels.... Not a bad feature for free. Larger scale deployments should probably use a dedicated controller box making the re-routing decisions, but any WAN egress point to an Internet or private WAN provider is your "border" device used by the "master" to get information, setup probes and learn netflow data to make decisions. I've used it for testing purposes on enterprise WAN deployment and it works pretty well. We are planning on deploying on a production DMVPN solution when the MGRE bug below is resolved. My main beef is a bug related to use of PfR on mGRE tunnel interfaces and the memory-hog nature of the feature... It will detect your brown-out issues like increased packet loss for traffic through provider X that cause customers to call you about broken applications and will re-route the traffic so you may never even know there was an issue!! The solution is particularly good for enterprises with only a few WAN or Internet exits from a location and for dynamically load sharing traffic to paid-for commit levels to reduce recurring cost and get the most out of existing connectivity without paying burst charges. We've done testing on use for our internet border routing in the "advice" mode, where is just says what changes it would maek, without actually making the changes. Production deployment soon as part of the ever popular cost-reduction efforts currently in vogue in enterprises right now given the current economy. http://www.cisco.com/go/pfr There's some similar solutions out there.. RouteScience was mentioned, but I didn't see anyone mention InterNAP FCP, which is part of the basis for InterNAP's PNAP business model... They also sell it to others enterprises and ISPs. -----Original Message----- From: Ken A [mailto:ka at pacific.net] Sent: Thursday, March 12, 2009 9:18 AM To: nanog at nanog.org Subject: Re: Redundant Array of Inexpensive ISP's? Tim Utschig wrote: > [Please reply off-list. I'll summarize back to the list if there is > more than a little interest in me doing so.] > Please do. There are many rural ISPs and WISPs that might benefit from a decent look at these products, or any open source clones that might be available to test & refine these tricks. Pricing for even a fractional DS3 in the rural US is still very high. Being able to shift bandwidth from a colo facility in a large city to a remote site served by 3 or 4 consumer grade broadband links could be a helpful development, if the bottom line works out. Thanks, Ken > I'm curious if anyone has experience with products from Talari > Networks, or anything similar, and would like to share. Did they live > up to your expectations? Caveats? > -- Ken Anderson Pacific Internet - http://www.pacific.net From cidr-report at potaroo.net Fri Mar 13 06:00:04 2009 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 13 Mar 2009 22:00:04 +1100 (EST) Subject: BGP Update Report Message-ID: <200903131100.n2DB0455027626@wattle.apnic.net> BGP Update Report Interval: 09-Feb-09 -to- 12-Mar-09 (32 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS9583 340993 7.2% 296.8 -- SIFY-AS-IN Sify Limited 2 - AS3130 89740 1.9% 690.3 -- RGNET-3130 RGnet/PSGnet 3 - AS6629 48665 1.0% 748.7 -- NOAA-AS - NOAA 4 - AS35805 42241 0.9% 139.0 -- UTG-AS United Telecom AS 5 - AS7643 38671 0.8% 34.9 -- VNN-AS-AP Vietnam Posts and Telecommunications (VNPT) 6 - AS30890 35698 0.8% 79.9 -- EVOLVA Evolva Telecom 7 - AS17974 35138 0.7% 69.4 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 8 - AS5056 33187 0.7% 286.1 -- INS-NET-2 - Iowa Network Services 9 - AS6458 30871 0.7% 85.5 -- Telgua 10 - AS30306 29280 0.6% 7320.0 -- AfOL-Sz-AS 11 - AS17488 27622 0.6% 16.8 -- HATHWAY-NET-AP Hathway IP Over Cable Internet 12 - AS4771 27137 0.6% 102.0 -- NZTELECOM Netgate 13 - AS29372 25369 0.5% 281.9 -- SFR-NETWORK SFR 14 - AS5050 24198 0.5% 1728.4 -- PSC-EXT - Pittsburgh Supercomputing Center 15 - AS27757 23122 0.5% 189.5 -- ANDINATEL S.A. 16 - AS9829 22760 0.5% 35.6 -- BSNL-NIB National Internet Backbone 17 - AS4648 22122 0.5% 107.9 -- NZIX-2 Netgate 18 - AS8103 19727 0.4% 32.8 -- STATE-OF-FLA - Florida Department of Management Services - Technology Program 19 - AS30969 19371 0.4% 2421.4 -- TAN-NET TransAfrica Networks 20 - AS20115 19086 0.4% 11.6 -- CHARTER-NET-HKY-NC - Charter Communications TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS30306 29280 0.6% 7320.0 -- AfOL-Sz-AS 2 - AS19017 5390 0.1% 5390.0 -- QUALCOMM-QWBS-LV - Qualcomm, Inc. 3 - AS30287 4700 0.1% 4700.0 -- ALON-USA - ALON USA, LP 4 - AS12500 12162 0.3% 4054.0 -- RCS-AS RCS Autonomus System 5 - AS41343 5895 0.1% 2947.5 -- TRIUNFOTEL-ASN TRIUNFOTEL 6 - AS28194 5460 0.1% 2730.0 -- 7 - AS30969 19371 0.4% 2421.4 -- TAN-NET TransAfrica Networks 8 - AS8755 2070 0.0% 2070.0 -- CITYLINESPB-AS CityLine-SPb Autonomous System 9 - AS48144 1882 0.0% 1882.0 -- NETWORKTECH Network Technology 10 - AS5050 24198 0.5% 1728.4 -- PSC-EXT - Pittsburgh Supercomputing Center 11 - AS35335 1627 0.0% 1627.0 -- ESSTU-AS East-Siberian State Technological University AS 12 - AS35410 9009 0.2% 1501.5 -- RU-LVS-AS LVS AS Number 13 - AS32398 11438 0.2% 1429.8 -- REALNET-ASN-1 14 - AS46328 10964 0.2% 1218.2 -- PTCNEBRASKA - PIERCE TELEPHONE COMPANY, INCORPORATED 15 - AS39107 2249 0.1% 1124.5 -- INTERLAN-AS Asociatia Interlan 16 - AS41382 1038 0.0% 1038.0 -- TELEPORT-AS Teleport LLC Network AS 17 - AS46781 916 0.0% 916.0 -- ASN1 - White Nile Group, Inc. 18 - AS19634 896 0.0% 896.0 -- HGL-22-ASN - Heidenreich GP, LLC 19 - AS46653 2601 0.1% 867.0 -- FREDRIKSON---BYRON - Fredrikson & Byron, P.A. 20 - AS29224 1676 0.0% 838.0 -- HELLMANN Hellmann Worldwide Logistics GmbH & Co KG TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 221.134.32.0/24 32037 0.6% AS9583 -- SIFY-AS-IN Sify Limited 2 - 210.214.177.0/24 27706 0.5% AS9583 -- SIFY-AS-IN Sify Limited 3 - 221.135.105.0/24 27697 0.5% AS9583 -- SIFY-AS-IN Sify Limited 4 - 210.214.184.0/24 27562 0.5% AS9583 -- SIFY-AS-IN Sify Limited 5 - 210.214.232.0/24 27525 0.5% AS9583 -- SIFY-AS-IN Sify Limited 6 - 210.214.132.0/24 27428 0.5% AS9583 -- SIFY-AS-IN Sify Limited 7 - 210.214.156.0/24 27408 0.5% AS9583 -- SIFY-AS-IN Sify Limited 8 - 210.214.222.0/24 27343 0.5% AS9583 -- SIFY-AS-IN Sify Limited 9 - 210.214.146.0/24 27261 0.5% AS9583 -- SIFY-AS-IN Sify Limited 10 - 210.214.117.0/24 26981 0.5% AS9583 -- SIFY-AS-IN Sify Limited 11 - 210.210.127.0/24 26875 0.5% AS9583 -- SIFY-AS-IN Sify Limited 12 - 72.23.246.0/24 24056 0.5% AS5050 -- PSC-EXT - Pittsburgh Supercomputing Center 13 - 192.35.129.0/24 16266 0.3% AS6629 -- NOAA-AS - NOAA 14 - 192.102.88.0/24 16109 0.3% AS6629 -- NOAA-AS - NOAA 15 - 198.77.177.0/24 16028 0.3% AS6629 -- NOAA-AS - NOAA 16 - 212.85.223.0/24 14248 0.3% AS30306 -- AfOL-Sz-AS 17 - 212.85.220.0/24 14236 0.3% AS19711 -- SWAZI-NET AS30306 -- AfOL-Sz-AS 18 - 190.152.100.0/24 12940 0.2% AS27757 -- ANDINATEL S.A. 19 - 41.204.2.0/24 11173 0.2% AS32398 -- REALNET-ASN-1 20 - 222.255.51.64/26 11063 0.2% AS7643 -- VNN-AS-AP Vietnam Posts and Telecommunications (VNPT) Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Mar 13 06:00:02 2009 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 13 Mar 2009 22:00:02 +1100 (EST) Subject: The Cidr Report Message-ID: <200903131100.n2DB02VV027620@wattle.apnic.net> This report has been generated at Fri Mar 13 21:13:26 2009 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 06-03-09 288940 180094 07-03-09 289342 180309 08-03-09 289456 180310 09-03-09 289455 180230 10-03-09 289539 180436 11-03-09 289739 180492 12-03-09 289542 180833 13-03-09 289939 180722 AS Summary 30907 Number of ASes in routing system 13132 Number of ASes announcing only one prefix 4321 Largest number of prefixes announced by an AS AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc. 89808640 Largest address span announced by an AS (/32s) AS27064: DDN-ASNBLK1 - DoD Network Information Center Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 13Mar09 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 289860 180735 109125 37.6% All ASes AS6389 4321 350 3971 91.9% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4323 4243 1833 2410 56.8% TWTC - tw telecom holdings, inc. AS209 2842 1263 1579 55.6% ASN-QWEST - Qwest Communications Corporation AS4766 1815 529 1286 70.9% KIXS-AS-KR Korea Telecom AS17488 1529 326 1203 78.7% HATHWAY-NET-AP Hathway IP Over Cable Internet AS22773 1033 66 967 93.6% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS4755 1217 261 956 78.6% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS8452 1238 326 912 73.7% TEDATA TEDATA AS1785 1733 837 896 51.7% AS-PAETEC-NET - PaeTec Communications, Inc. AS8151 1442 628 814 56.4% Uninet S.A. de C.V. AS11492 1194 481 713 59.7% CABLEONE - CABLE ONE, INC. AS19262 959 248 711 74.1% VZGNI-TRANSIT - Verizon Internet Services Inc. AS7545 764 197 567 74.2% TPG-INTERNET-AP TPG Internet Pty Ltd AS6478 1287 727 560 43.5% ATT-INTERNET3 - AT&T WorldNet Services AS18101 753 195 558 74.1% RIL-IDC Reliance Infocom Ltd Internet Data Centre, AS3356 1172 616 556 47.4% LEVEL3 Level 3 Communications AS2706 544 26 518 95.2% HKSUPER-HK-AP Pacific Internet (Hong Kong) Limited AS22047 596 115 481 80.7% VTR BANDA ANCHA S.A. AS17908 601 122 479 79.7% TCISL Tata Communications AS4808 607 157 450 74.1% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS7018 1449 1014 435 30.0% ATT-INTERNET4 - AT&T WorldNet Services AS24560 675 243 432 64.0% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS4134 927 506 421 45.4% CHINANET-BACKBONE No.31,Jin-rong Street AS9443 509 90 419 82.3% INTERNETPRIMUS-AS-AP Primus Telecommunications AS10620 827 415 412 49.8% TV Cable S.A. AS17676 530 119 411 77.5% GIGAINFRA BB TECHNOLOGY Corp. AS4668 691 284 407 58.9% LGNET-AS-KR LG CNS AS7011 953 552 401 42.1% FRONTIER-AND-CITIZENS - Frontier Communications of America, Inc. AS6471 440 62 378 85.9% ENTEL CHILE S.A. AS16814 491 130 361 73.5% NSS S.A. Total 37382 12718 24664 66.0% Top 30 total Possible Bogus Routes 24.75.116.0/22 AS10796 SCRR-10796 - Road Runner HoldCo LLC 24.75.160.0/19 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 24.245.128.0/17 AS11492 CABLEONE - CABLE ONE, INC. 24.246.0.0/17 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 24.246.128.0/18 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 41.220.16.0/20 AS8668 TELONE-AS TelOne Zimbabwe P/L 41.223.112.0/22 AS5713 SAIX-NET 41.223.188.0/24 AS22351 INTELSAT Intelsat Global BGP Routing Policy 41.223.189.0/24 AS26452 BRING-AS - BringCom, Inc. 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 63.140.213.0/24 AS22555 UTC - Universal Talkware Corporation 63.143.251.0/24 AS22555 UTC - Universal Talkware Corporation 64.31.32.0/19 AS11955 SCRR-11955 - Road Runner HoldCo LLC 64.31.32.0/22 AS10796 SCRR-10796 - Road Runner HoldCo LLC 64.31.36.0/23 AS10796 SCRR-10796 - Road Runner HoldCo LLC 64.31.38.0/23 AS12262 RR-CINCINNATI-ASN-01 - Road Runner HoldCo LLC 64.31.40.0/23 AS12262 RR-CINCINNATI-ASN-01 - Road Runner HoldCo LLC 64.31.42.0/23 AS10796 SCRR-10796 - Road Runner HoldCo LLC 64.31.44.0/23 AS10796 SCRR-10796 - Road Runner HoldCo LLC 64.31.46.0/24 AS10796 SCRR-10796 - Road Runner HoldCo LLC 64.31.48.0/22 AS11060 NEO-RR-COM - Road Runner HoldCo LLC 64.31.53.0/24 AS10796 SCRR-10796 - Road Runner HoldCo LLC 64.31.55.0/24 AS10796 SCRR-10796 - Road Runner HoldCo LLC 64.31.59.0/24 AS7017 SCRR-7015 - Road Runner HoldCo LLC 64.31.60.0/24 AS7017 SCRR-7015 - Road Runner HoldCo LLC 64.64.159.0/24 AS32004 BIG-ASN - Business Information Group, Inc. 64.73.192.0/19 AS11247 IBSINC - Internet Business Services, Inc. 64.79.88.0/24 AS26096 LODDEN - Lodden Services 64.79.89.0/24 AS26096 LODDEN - Lodden Services 64.147.64.0/19 AS40156 THEOPT-HOU - The Optimal Link Corporation 66.11.32.0/20 AS6261 VISINET - Visionary Systems, Inc. 66.11.40.0/21 AS6261 VISINET - Visionary Systems, Inc. 66.54.91.0/24 AS30506 BLACKSUN-1 - Blacksun Technologies LLC 66.55.160.0/19 AS29994 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.206.32.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.33.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.34.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.35.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.40.0/22 AS174 COGENT Cogent/PSI 66.206.44.0/23 AS174 COGENT Cogent/PSI 66.206.47.0/24 AS17557 PKTELECOM-AS-AP Pakistan Telecom 66.207.32.0/20 AS23011 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 69.71.192.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 69.80.0.0/17 AS3043 AMPHIB-AS - Amphibian Media Corporation 80.88.0.0/21 AS33774 DJAWEB 80.88.8.0/22 AS33774 DJAWEB 80.88.10.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 81.25.128.0/20 AS41589 VICUS-AS VICUS S.A. 95.130.160.0/21 AS12611 RKOM R-KOM Regensburger Telekommunikations GmbH & Co. KG 95.130.168.0/21 AS43260 DGN DGN Teknoloji 98.96.0.0/13 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 109.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 109.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 109.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 121.50.168.0/21 AS9931 CAT-AP The Communication Authoity of Thailand, CAT 122.128.120.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. 137.0.0.0/13 AS27064 DDN-ASNBLK1 - DoD Network Information Center 163.142.0.0/16 AS2500 WIDE-BB WIDE Project 172.7.0.0/24 AS28175 172.10.1.0/30 AS18305 POSNET POSDATA Co.,Ltd 178.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 178.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 178.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc 192.9.200.0/24 AS3602 AS3602-RTI - Rogers Telecom Inc. 192.64.85.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.107.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.108.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.177.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.70.164.0/24 AS25689 NRCNET-AS - National Research Council of Canada 192.96.36.0/24 AS5713 SAIX-NET 192.96.37.0/24 AS10474 NETACTIVE 192.96.135.0/24 AS2018 TENET-1 192.96.136.0/23 AS2018 TENET-1 192.96.141.0/24 AS2018 TENET-1 192.96.143.0/24 AS2018 TENET-1 192.96.145.0/24 AS2018 TENET-1 192.96.177.0/24 AS6083 POSIX-AFRICA 192.101.45.0/24 AS2905 TICSA-ASN 192.101.46.0/24 AS6503 Avantel, S.A. 192.101.64.0/21 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.72.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.74.0/24 AS1239 SPRINTLINK - Sprint 192.124.248.0/23 AS680 DFN-IP service G-WiN 192.124.252.0/22 AS680 DFN-IP service G-WiN 192.131.233.0/24 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 192.133.6.0/24 AS10282 ORANGE-BUSINESS-SERVICES-CEEUR Orange Business Services (formerly Equant) AS for CEEUR 192.153.144.0/21 AS27064 DDN-ASNBLK1 - DoD Network Information Center 192.154.32.0/19 AS81 NCREN - MCNC 192.188.208.0/20 AS27064 DDN-ASNBLK1 - DoD Network Information Center 196.6.108.0/24 AS5713 SAIX-NET 196.10.119.0/24 AS2018 TENET-1 196.10.122.0/23 AS2018 TENET-1 196.10.251.0/24 AS2018 TENET-1 196.10.252.0/23 AS2018 TENET-1 196.10.254.0/24 AS2018 TENET-1 196.13.101.0/24 AS2018 TENET-1 196.13.102.0/23 AS2018 TENET-1 196.13.104.0/24 AS2018 TENET-1 196.13.121.0/24 AS2018 TENET-1 196.13.125.0/24 AS2018 TENET-1 196.13.126.0/24 AS2018 TENET-1 196.13.169.0/24 AS2018 TENET-1 196.13.174.0/23 AS2018 TENET-1 196.13.176.0/21 AS2018 TENET-1 196.13.192.0/22 AS2018 TENET-1 196.13.196.0/24 AS2018 TENET-1 196.32.96.0/20 AS6453 GLOBEINTERNET TATA Communications 196.202.224.0/21 AS8818 TELE Greenland Autonomous System 198.1.2.0/24 AS4761 INDOSAT-INP-AP INDOSAT Internet Network Provider 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc. 198.54.82.0/24 AS2018 TENET-1 198.54.92.0/24 AS2018 TENET-1 198.54.222.0/24 AS2018 TENET-1 198.97.72.0/21 AS27064 DDN-ASNBLK1 - DoD Network Information Center 198.97.96.0/19 AS27064 DDN-ASNBLK1 - DoD Network Information Center 198.97.240.0/20 AS27064 DDN-ASNBLK1 - DoD Network Information Center 198.161.87.0/24 AS6539 GT-BELL - Bell Canada 198.167.0.0/16 AS7456 INTERHOP - Interhop Network SERVICES Inc. 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 198.169.0.0/16 AS803 SASKTEL - Saskatchewan Telecommunications 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services 199.10.0.0/16 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.103.2.0/24 AS22663 PROMINIC-NET-INC - Prominic.NET, Inc. 199.103.3.0/24 AS22663 PROMINIC-NET-INC - Prominic.NET, Inc. 199.103.4.0/24 AS22663 PROMINIC-NET-INC - Prominic.NET, Inc. 199.103.5.0/24 AS22663 PROMINIC-NET-INC - Prominic.NET, Inc. 199.103.6.0/23 AS22663 PROMINIC-NET-INC - Prominic.NET, Inc. 199.114.0.0/21 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.114.128.0/18 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.114.130.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.131.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.132.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.134.0/24 AS3541 ITSDN-U4 - DoD Network Information Center 199.114.136.0/24 AS27044 DDN-ASNBLK1 - DoD Network Information Center 199.114.138.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.140.0/24 AS3544 ITSDN-U7 - DoD Network Information Center 199.114.142.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.144.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.148.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.150.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.152.0/24 AS27033 DDN-ASNBLK1 - DoD Network Information Center 199.114.153.0/24 AS27034 DDN-ASNBLK1 - DoD Network Information Center 199.114.154.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.114.156.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.114.160.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.121.0.0/16 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.123.0.0/18 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.123.16.0/20 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.123.80.0/21 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.189.32.0/19 AS7332 IQUEST-AS - IQuest Internet 199.202.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.202.216.0/21 AS577 BACOM - Bell Canada 199.246.116.0/24 AS813 UUNET-CANADA - MCI Communications Services, Inc. d/b/a Verizon Business 202.6.176.0/20 AS24316 202.58.113.0/24 AS19161 INNOCOM-TELECOM - INNOCOM TELECOM 202.72.40.0/24 AS38205 202.72.41.0/24 AS38205 202.72.46.0/24 AS38205 202.72.47.0/24 AS38205 202.73.144.0/20 AS4788 TMNET-AS-AP TM Net, Internet Service Provider 202.80.192.0/20 AS2706 HKSUPER-HK-AP Pacific Internet (Hong Kong) Limited 202.86.252.0/22 AS4748 RESOLINK-AS-AP Resources Link Network Limited 202.86.252.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.253.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.254.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.255.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.94.70.0/24 AS9837 POWERTEL-AP Powertel Ltd 202.122.120.0/21 AS17494 BTTB-AS-AP Telecom Operator & Internet Service Provider as well 202.124.195.0/24 AS17557 PKTELECOM-AS-AP Pakistan Telecom 202.133.70.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.133.73.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.136.254.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.136.255.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.140.160.0/24 AS4841 202.140.161.0/24 AS4841 202.140.162.0/24 AS4841 202.140.163.0/24 AS4841 202.140.164.0/24 AS4841 202.140.165.0/24 AS4841 202.140.166.0/24 AS4841 202.140.167.0/24 AS4841 202.140.168.0/24 AS4841 202.140.169.0/24 AS4841 202.140.170.0/24 AS4841 202.140.171.0/24 AS4841 202.140.172.0/24 AS4841 202.140.173.0/24 AS4841 202.140.174.0/24 AS4841 202.140.175.0/24 AS4841 202.140.180.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.140.181.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.140.182.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.150.227.0/24 AS17727 NAPINFO-AS-AP PT. NAP Info Lintas Nusa 202.181.32.0/24 AS4645 ASN-HKNET-AP HKNet Co. Ltd 203.12.45.0/24 AS4854 NETSPACE-AS-AP Netspace Online Systems 203.62.0.0/17 AS7575 AARNET-AS-AP Australian Academic and Reasearch Network (AARNet) 203.78.48.0/20 AS9299 IPG-AS-AP Philippine Long Distance Telephone Company 203.89.139.0/24 AS17911 BRAINPK-AS-AP Brain Telecommunication Ltd. 203.111.192.0/20 AS7473 SINGTEL-AS-AP Singapore Telecommunications Ltd 203.112.111.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.113.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.114.0/24 AS4802 ASN-IINET iiNet Limited 203.112.116.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.117.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.118.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.119.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.120.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.121.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.127.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.128.128.0/19 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 203.128.128.0/24 AS23849 CNNIC-NET263-AP Beijing Capital-online science development Co.,Ltd. 203.152.154.0/23 AS9583 SIFY-AS-IN Sify Limited 204.9.216.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.9.217.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.9.218.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.13.140.0/22 AS7270 NET2PHONE - Net2Phone Corp. 204.16.120.0/23 AS12077 204.16.122.0/23 AS12077 204.19.14.0/23 AS577 BACOM - Bell Canada 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.189.134.0/24 AS11814 CYBERSURF - Cybersurf Inc. 205.210.145.0/24 AS11814 CYBERSURF - Cybersurf Inc. 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 207.174.0.0/16 AS13790 INTERNAP-BLK3 - Internap Network Services Corporation 207.174.130.0/24 AS13345 ROCKYNET-COM - Rockynet.com, Inc 207.174.131.0/24 AS30715 NETRACK - Netrack, Inc. 207.174.132.0/23 AS30715 NETRACK - Netrack, Inc. 207.174.137.0/24 AS13345 ROCKYNET-COM - Rockynet.com, Inc 207.174.138.0/23 AS13345 ROCKYNET-COM - Rockynet.com, Inc 207.174.140.0/22 AS13345 ROCKYNET-COM - Rockynet.com, Inc 207.174.151.0/24 AS11500 PEAKPEAK - Peak to Peak Internet 207.174.152.0/22 AS30715 NETRACK - Netrack, Inc. 207.174.157.0/24 AS13345 ROCKYNET-COM - Rockynet.com, Inc 207.174.158.0/24 AS11500 PEAKPEAK - Peak to Peak Internet 207.174.173.0/24 AS16618 AS-HFS-CAVION - Harland Financial Solutions, Inc. 207.174.175.0/24 AS13345 ROCKYNET-COM - Rockynet.com, Inc 207.174.177.0/24 AS11500 PEAKPEAK - Peak to Peak Internet 207.174.178.0/24 AS11500 PEAKPEAK - Peak to Peak Internet 207.174.182.0/24 AS29831 FONENET - FONE NET, LLC 207.174.188.0/22 AS30715 NETRACK - Netrack, Inc. 207.174.192.0/24 AS29831 FONENET - FONE NET, LLC 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.174.201.0/24 AS13345 ROCKYNET-COM - Rockynet.com, Inc 207.174.202.0/24 AS13345 ROCKYNET-COM - Rockynet.com, Inc 207.174.210.0/23 AS16618 AS-HFS-CAVION - Harland Financial Solutions, Inc. 207.174.211.0/24 AS16618 AS-HFS-CAVION - Harland Financial Solutions, Inc. 207.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 207.204.168.0/24 AS15150 BELLTECH-AS - BELLWETHER TECHNOLOGY CORPORATION 207.204.222.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 209.54.93.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 209.54.111.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 209.54.123.0/24 AS6062 NETPLEX - NETPLEX 209.54.240.0/21 AS10887 BPSI-AS - BPSI Internet Services 209.74.96.0/19 AS10912 INTERNAP-BLK - Internap Network Services Corporation 209.140.90.0/24 AS14461 NTSL - NET SOLUTIONS 209.140.224.0/21 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.234.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.235.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.236.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.237.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.238.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.239.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.141.16.0/21 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.141.48.0/22 AS14461 NTSL - NET SOLUTIONS 209.145.192.0/18 AS3043 AMPHIB-AS - Amphibian Media Corporation 209.222.5.0/24 AS26699 PSI-CT - Printing For Systems Inc 209.222.6.0/24 AS26699 PSI-CT - Printing For Systems Inc 209.236.64.0/19 AS7911 LVLT-7911 - Level 3 Communications, Inc. 209.236.96.0/19 AS7911 LVLT-7911 - Level 3 Communications, Inc. 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 216.37.114.0/23 AS3549 GBLX Global Crossing Ltd. 216.37.120.0/23 AS13377 216.99.16.0/24 AS6395 LVLT-6395 - Level 3 Communications, Inc. 216.99.20.0/24 AS6395 LVLT-6395 - Level 3 Communications, Inc. 216.172.198.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.172.199.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.210.86.0/24 AS577 BACOM - Bell Canada 216.240.240.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.240.241.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.240.242.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.251.207.0/24 AS1239 SPRINTLINK - Sprint 217.78.71.0/24 AS12491 IPPLANET-AS IPPlanet 217.78.72.0/24 AS12491 IPPLANET-AS IPPlanet 217.78.73.0/24 AS12491 IPPLANET-AS IPPlanet Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From nick at switchtower.org Fri Mar 13 07:19:32 2009 From: nick at switchtower.org (Nicholas R. Cappelletti) Date: Fri, 13 Mar 2009 08:19:32 -0400 (EDT) Subject: Multi-home with same provider, BGP convergence issues In-Reply-To: <14573579.271236946728340.JavaMail.root@mail.switchtower.org> Message-ID: <12444741.291236946772053.JavaMail.root@mail.switchtower.org> Hello, I have sort of an interesting problem, that probably has an easy fix. I've ran into a continuous BGP convergence problem on the cores of the network I administer every time I bring up both of our Savvis connections (we have a single OC-12 and 2 1GigE connections in a multi-hop configuration). The connections are on separate border devices separated again by a set of cores routers. There is a set of core routers per building and each building has its own Savvis connection along with other connections from other providers. All the equipment is Cisco gear. We've been running with multiple connections from Savvis for some time, but recently reconfigured the GigE lines to multi-hop to help with balancing, only then, did we experience this BGP convergence issue. >From what my colleagues and I have read so far is that turning on "bgp deterministic-med" on all the BGP speaking devices should help in this situation, but I don't see how using MEDS is going to help us. I can provide a .png of our current setup for reference or any further information needed. Any help anyone can provide will be greatly appreciated. --- Nick Cappelletti nick at switchtower.org From jgreco at ns.sol.net Fri Mar 13 08:53:35 2009 From: jgreco at ns.sol.net (Joe Greco) Date: Fri, 13 Mar 2009 07:53:35 -0600 (CST) Subject: Dynamic IP log retention = 0? In-Reply-To: from "Martin Hannigan" at Mar 13, 2009 12:23:02 AM Message-ID: <200903131353.n2DDrZLD084617@aurora.sol.net> > On Thu, Mar 12, 2009 at 8:52 PM, Joe Greco wrote: > > > Well most port scanning is from compromised boxes. Once a > > > box is compromised it can be used for *any* sort of attack. > > > If you really care about security you take reports of ports > > > scans seriously. > > > > Yeahbut, the real problem is that port scanning is typically used as > > part of a process to infect _other_ boxes. If you allow this sort of > > illness to spread, the patient (that is, the Internet) doesn't get > > better. > > Port scanning is the Internet equivelant of the common cold. They're a dime > a dozen. > > I recommend taking some Vitamin B and D. Block, and Drop. No, it's more comparable to the jerk who not only doesn't stay at home with his cold, but actively walks around the workplace coughing and sneezing without covering his mouth/nose with a kleenex, spraying people. The reality is that it fails the "if everybody did this, would it be a good thing" test. While some "B&D" is common sense on the receiving end, this does not make it any more correct for the originating site to let it keep happening. If every PC on the Internet (conservatively, let's assume a billion devices that are sufficiently sophisticated that they could be infected) were to send you a single packet per day, you'd be seeing over 10,000pps. That should suggest that the behaviour is not something to be encouraged. My locking my doors does not mean it's okay for you to check if my door is locked. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From aduitsis at gmail.com Fri Mar 13 09:34:57 2009 From: aduitsis at gmail.com (Athanasios Douitsis) Date: Fri, 13 Mar 2009 16:34:57 +0200 Subject: Network SLA In-Reply-To: <997BC128AE961E4A8B880CD7442D94800A1EC529@NJCHLEXCMB01.cable.comcast.com> References: <262b67200902190750m556cf72ve2ae25e4b64378e7@mail.gmail.com> <499DBE2A.6020907@gmail.com> <4fff97de0902230019tce5e53q2ddb501171436dc@mail.gmail.com> <262b67200903070312j55bded5dq26c978feb0b66441@mail.gmail.com> <997BC128AE961E4A8B880CD7442D94800A1EC529@NJCHLEXCMB01.cable.comcast.com> Message-ID: <317578510903130734t5a89e6d2td104889a20aadd06@mail.gmail.com> Anyone interested in setting up his own IP SLA probes by hand and then collect the measurements into a database, can use a Perl tool we developed at 2005: http://sourceforge.net/projects/saa-collector It's rather old (SAA got renamed into IPSLA in the meantime) and, in retrospect, the code is a little rough around the edges, but it's nevertheless usable. Regards, Athanasios On Wed, Mar 11, 2009 at 10:20 PM, Andreas, Rich < Rich_Andreas at cable.comcast.com> wrote: > I have found that Cisco IPSLA is heavily used in the MSO/Service > Provider Space. Juniper has equivalent functionality via RPM. > > Rich > > > -----Original Message----- > From: Saqib Ilyas [mailto:msaqib at gmail.com] > Sent: Saturday, March 07, 2009 6:12 AM > To: nanog at nanog.org > Subject: Re: Network SLA > > I must thank everyone who has answered my queries. Just a couple more > short questions. > For instance, if one is using MRTG, and wants to check if we can meet > a 1 Mbps end-to-end throughput between a couple of customer sites, I > believe you would need to use some traffic generator tools, because > MRTG merely imports counters from routers and plots them. Is that > correct? > We've heard of the BRIX active measurement tool in replies to my > earlier email. Also, I've found Cisco IP SLA that also sends traffic > into the service provider network and measures performance. How many > people really use IP SLA feature? > Thanks and best regards > > On Mon, Feb 23, 2009 at 1:19 PM, Zartash Uzmi wrote: > > As I gather, there is a mix of answers, ranging from "building the > resources > > according to requirements and HOPE for the best" to "use of arguably > > sophisticated tools and perhaps sharing the results with the legal > > department". > > > > I would be particularly interested in hearing the service providers' > > viewpoint on the following situation. > > > > Consider a service provider with MPLS deployed within its own network. > > > > (A) When the SP enters into a relation with the customer, does the SP > > establish new MPLS paths based on customer demands (this is perhaps > similar > > to "building" based on requirements as pointed out by David)? If yes, > > between what sites/POPs? I assume the answer may be different > depending upon > > a single-site customer or a customer with multiple sites. > > > > (B) For entering into the relationship for providing X units of > bandwidth > > (to another site of same customer or to the Tier-1 backbone), does the > SP > > use any wisdom (in addition to MRTG and the likes)? If so, what > scientific > > parameters are kept in mind? > > > > (C) How does the customer figure out that a promise for X units of > bandwidth > > is maintained by the SP? I believe customers may install some > measuring > > tools but is that really the case in practice? > > > > Thanks, > > Zartash > > > > On Fri, Feb 20, 2009 at 1:16 AM, Stefan wrote: > > > >> Saqib Ilyas wrote: > >> > >>> Greetings > >>> I am curious to know about any tools/techniques that a service > provider > >>> uses > >>> to assess an SLA before signing it. That is to say, how does an > >>> administrator know if he/she can meet what he is promising. Is it > based on > >>> experience? Are there commonly used tools for this? > >>> Thanks and best regards > >>> > >>> > >> Not necessarily as a direct answer (I am pretty sure there'll be > others on > >> this list giving details in the area of specific tools and > standards), but I > >> think this may be a question (especially considering your end result > >> concern: *signing the SLA!) equally applicable to your legal > department. In > >> the environment we live, nowadays, the SLA could (should?!? ... > >> unfortunately) be "refined" and (at the other end - i.e. receiving) > >> "interpreted" by the lawyers, with possibly equal effects (mostly > financial > >> and as overall impact on the business) as the tools we (the technical > >> people) would be using to measure latency, uptime, bandwidth, jitter, > etc... > >> > >> Stefan > >> > >> > > > > > > -- > Muhammad Saqib Ilyas > PhD Student, Computer Science and Engineering > Lahore University of Management Sciences > > > > From ddunkin at netos.net Fri Mar 13 12:19:45 2009 From: ddunkin at netos.net (Darryl Dunkin) Date: Fri, 13 Mar 2009 10:19:45 -0700 Subject: Comcast postmaster contact Message-ID: <56F5BC5F404CF84896C447397A1AAF20DEE3DD@MAIL.nosi.netos.com> Does anyone have a valid postmaster contact for Comcast? They are currently blocking one of my mailservers, yet using the forms on their site to request removal, they report that it is not blocked by them. They are ignoring the actual content of my reports (such as the actual error returned by their servers) and sending the same canned answer back to every request. From nenolod at systeminplace.net Fri Mar 13 12:20:51 2009 From: nenolod at systeminplace.net (William Pitcock) Date: Fri, 13 Mar 2009 12:20:51 -0500 Subject: SBC NOC contact Message-ID: <1236964851.29982.19.camel@petrie> Hello, Does anyone here have an SBC/AT&T NOC contact that goes to an actual human being? Their NOC handle email, support at swbell.net bounces with the following message: | Dear SBC Yahoo! Member, | | Our Support Request site has recently changed. | Please submit your question or comment via our new online form available at | http://help.sbcglobal.net/techquestions.php. | | Thank you for contacting SBC Yahoo! Technical Support. Which is especially funny because I don't do business with SBC at all. Also, their website leads us to a "we don't take emails anymore" message. But I digress, their nameservers are out of sync, causing problems with reverse DNS suddenly going away for some SBC IPs in our logs. Appears to be an issue with ns1.pbi.net... So yeah, if someone knows somebody who could fix that, that would be fantastic. -- William Pitcock SystemInPlace - Simple Hosting Solutions 1-866-519-6149 From rmacharia at gmail.com Fri Mar 13 13:02:21 2009 From: rmacharia at gmail.com (Raymond Macharia) Date: Fri, 13 Mar 2009 21:02:21 +0300 Subject: Multi-home with same provider, BGP convergence issues In-Reply-To: <12444741.291236946772053.JavaMail.root@mail.switchtower.org> References: <14573579.271236946728340.JavaMail.root@mail.switchtower.org> <12444741.291236946772053.JavaMail.root@mail.switchtower.org> Message-ID: Hi Nicholas,a simple schematic would help together with configs of how you are announcing your IP blocks. But with what you have indicated, you may need to manipulate your announcements (for example using prepend) and make sure that you don't have the same IP blocks being advertised from the two links at the same time. Again with more info I may provide you with a more accurate response Regards Raymond Macharia On Fri, Mar 13, 2009 at 3:19 PM, Nicholas R. Cappelletti < nick at switchtower.org> wrote: > Hello, > > I have sort of an interesting problem, that probably has an easy fix. I've > ran into a continuous BGP convergence problem on the cores of the network I > administer every time I bring up both of our Savvis connections (we have a > single OC-12 and 2 1GigE connections in a multi-hop configuration). > > The connections are on separate border devices separated again by a set of > cores routers. There is a set of core routers per building and each > building has its own Savvis connection along with other connections from > other providers. All the equipment is Cisco gear. We've been running with > multiple connections from Savvis for some time, but recently reconfigured > the GigE lines to multi-hop to help with balancing, only then, did we > experience this BGP convergence issue. > > >From what my colleagues and I have read so far is that turning on "bgp > deterministic-med" on all the BGP speaking devices should help in this > situation, but I don't see how using MEDS is going to help us. > > I can provide a .png of our current setup for reference or any further > information needed. Any help anyone can provide will be greatly > appreciated. > > --- > > Nick Cappelletti > nick at switchtower.org > > -- Raymond Macharia From cscora at apnic.net Fri Mar 13 13:12:24 2009 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 14 Mar 2009 04:12:24 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <200903131812.n2DICOMe014229@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 14 Mar, 2009 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 282891 Prefixes after maximum aggregation: 134061 Deaggregation factor: 2.11 Unique aggregates announced to Internet: 138798 Total ASes present in the Internet Routing Table: 30808 Prefixes per ASN: 9.18 Origin-only ASes present in the Internet Routing Table: 26818 Origin ASes announcing only one prefix: 13049 Transit ASes present in the Internet Routing Table: 3990 Transit-only ASes present in the Internet Routing Table: 89 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 25 Max AS path prepend of ASN (18678) 21 Prefixes from unregistered ASNs in the Routing Table: 500 Unregistered ASNs in the Routing Table: 168 Number of 32-bit ASNs allocated by the RIRs: 128 Prefixes from 32-bit ASNs in the Routing Table: 19 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 237 Number of addresses announced to Internet: 2015333504 Equivalent to 120 /8s, 31 /16s and 140 /24s Percentage of available address space announced: 54.4 Percentage of allocated address space announced: 63.6 Percentage of available address space allocated: 85.5 Percentage of address space in use by end-sites: 76.0 Total number of prefixes smaller than registry allocations: 139285 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 65455 Total APNIC prefixes after maximum aggregation: 23364 APNIC Deaggregation factor: 2.80 Prefixes being announced from the APNIC address blocks: 62237 Unique aggregates announced from the APNIC address blocks: 28362 APNIC Region origin ASes present in the Internet Routing Table: 3567 APNIC Prefixes per ASN: 17.45 APNIC Region origin ASes announcing only one prefix: 966 APNIC Region transit ASes present in the Internet Routing Table: 545 Average APNIC Region AS path length visible: 3.5 Max APNIC Region AS path length visible: 19 Number of APNIC addresses announced to Internet: 404953248 Equivalent to 24 /8s, 35 /16s and 24 /24s Percentage of available APNIC address space announced: 80.5 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 APNIC Address Blocks 58/8, 59/8, 60/8, 61/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 124056 Total ARIN prefixes after maximum aggregation: 65410 ARIN Deaggregation factor: 1.90 Prefixes being announced from the ARIN address blocks: 93499 Unique aggregates announced from the ARIN address blocks: 36106 ARIN Region origin ASes present in the Internet Routing Table: 12836 ARIN Prefixes per ASN: 7.28 ARIN Region origin ASes announcing only one prefix: 4935 ARIN Region transit ASes present in the Internet Routing Table: 1235 Average ARIN Region AS path length visible: 3.3 Max ARIN Region AS path length visible: 20 Number of ARIN addresses announced to Internet: 419494464 Equivalent to 25 /8s, 0 /16s and 250 /24s Percentage of available ARIN address space announced: 80.7 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 ARIN Address Blocks 24/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 108/8, 173/8, 174/8, 184/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 64709 Total RIPE prefixes after maximum aggregation: 37715 RIPE Deaggregation factor: 1.72 Prefixes being announced from the RIPE address blocks: 59322 Unique aggregates announced from the RIPE address blocks: 39468 RIPE Region origin ASes present in the Internet Routing Table: 12799 RIPE Prefixes per ASN: 4.63 RIPE Region origin ASes announcing only one prefix: 6723 RIPE Region transit ASes present in the Internet Routing Table: 1937 Average RIPE Region AS path length visible: 4.0 Max RIPE Region AS path length visible: 25 Number of RIPE addresses announced to Internet: 390950176 Equivalent to 23 /8s, 77 /16s and 109 /24s Percentage of available RIPE address space announced: 83.2 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223 RIPE Address Blocks 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 178/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 23426 Total LACNIC prefixes after maximum aggregation: 5806 LACNIC Deaggregation factor: 4.03 Prefixes being announced from the LACNIC address blocks: 21599 Unique aggregates announced from the LACNIC address blocks: 11767 LACNIC Region origin ASes present in the Internet Routing Table: 1076 LACNIC Prefixes per ASN: 20.07 LACNIC Region origin ASes announcing only one prefix: 339 LACNIC Region transit ASes present in the Internet Routing Table: 176 Average LACNIC Region AS path length visible: 4.0 Max LACNIC Region AS path length visible: 25 Number of LACNIC addresses announced to Internet: 61343488 Equivalent to 3 /8s, 168 /16s and 7 /24s Percentage of available LACNIC address space announced: 60.9 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247 plus ERX transfers LACNIC Address Blocks 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 4777 Total AfriNIC prefixes after maximum aggregation: 1383 AfriNIC Deaggregation factor: 3.45 Prefixes being announced from the AfriNIC address blocks: 4481 Unique aggregates announced from the AfriNIC address blocks: 1338 AfriNIC Region origin ASes present in the Internet Routing Table: 285 AfriNIC Prefixes per ASN: 15.72 AfriNIC Region origin ASes announcing only one prefix: 86 AfriNIC Region transit ASes present in the Internet Routing Table: 55 Average AfriNIC Region AS path length visible: 3.9 Max AfriNIC Region AS path length visible: 15 Number of AfriNIC addresses announced to Internet: 10136064 Equivalent to 0 /8s, 154 /16s and 170 /24s Percentage of available AfriNIC address space announced: 30.2 AfriNIC AS Blocks 36864-37887 & ERX transfers AfriNIC Address Blocks 41/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 1690 6929 396 Korea Telecom (KIX) 17488 1529 119 97 Hathway IP Over Cable Interne 4755 1216 431 179 TATA Communications formerly 9583 1092 86 528 Sify Limited 4134 927 16271 367 CHINANET-BACKBONE 18101 753 198 30 Reliance Infocom Ltd Internet 7545 744 159 104 TPG Internet Pty Ltd 9498 689 297 49 BHARTI BT INTERNET LTD. 24560 675 228 175 Bharti Airtel Ltd. 9829 637 490 21 BSNL National Internet Backbo Complete listing at http://thyme.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 4322 3670 338 bellsouth.net, inc. 209 2846 4149 624 Qwest 4323 1795 1065 374 Time Warner Telecom 1785 1733 717 139 PaeTec Communications, Inc. 20115 1587 1430 719 Charter Communications 7018 1451 5880 1013 AT&T WorldNet Services 6478 1287 296 514 AT&T Worldnet Services 2386 1265 682 899 AT&T Data Communications Serv 11492 1194 192 12 Cable One 3356 1172 10976 443 Level 3 Communications, LLC Complete listing at http://thyme.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8452 1238 188 7 TEDATA 30890 447 87 201 SC Kappa Invexim SRL 3292 443 1762 389 TDC Tele Danmark 12479 403 578 6 Uni2 Autonomous System 3320 352 7081 295 Deutsche Telekom AG 3301 343 1685 308 TeliaNet Sweden 8866 337 109 22 Bulgarian Telecommunication C 3215 335 2985 109 France Telecom Transpac 29049 322 26 3 AzerSat LLC. 8551 313 288 40 Bezeq International Complete listing at http://thyme.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 1444 2831 233 UniNet S.A. de C.V. 10620 826 187 99 TVCABLE BOGOTA 22047 600 302 14 VTR PUNTO NET S.A. 11830 520 294 51 Instituto Costarricense de El 7303 518 260 80 Telecom Argentina Stet-France 16814 491 31 10 NSS, S.A. 6471 440 95 32 ENTEL CHILE S.A. 11172 408 102 73 Servicios Alestra S.A de C.V 7738 397 794 28 Telecomunicacoes da Bahia S.A 28573 384 514 24 NET Servicos de Comunicao S.A Complete listing at http://thyme.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 808 75 27 LINKdotNET AS number 20858 292 34 3 This AS will be used to conne 3741 271 842 231 The Internet Solution 2018 241 215 141 Tertiary Education Network 6713 159 150 15 Itissalat Al-MAGHRIB 33783 150 10 8 EEPAD TISP TELECOM & INTERNET 29571 131 15 8 Ci Telecom Autonomous system 5536 123 8 9 Internet Egypt Network 33776 118 6 3 Starcomms Nigeria Limited 5713 116 507 66 Telkom SA Ltd Complete listing at http://thyme.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 4322 3670 338 bellsouth.net, inc. 209 2846 4149 624 Qwest 4323 1795 1065 374 Time Warner Telecom 1785 1733 717 139 PaeTec Communications, Inc. 4766 1690 6929 396 Korea Telecom (KIX) 20115 1587 1430 719 Charter Communications 17488 1529 119 97 Hathway IP Over Cable Interne 7018 1451 5880 1013 AT&T WorldNet Services 8151 1444 2831 233 UniNet S.A. de C.V. 6478 1287 296 514 AT&T Worldnet Services Complete listing at http://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 209 2846 2222 Qwest 1785 1733 1594 PaeTec Communications, Inc. 17488 1529 1432 Hathway IP Over Cable Interne 4323 1795 1421 Time Warner Telecom 4766 1690 1294 Korea Telecom (KIX) 8452 1238 1231 TEDATA 8151 1444 1211 UniNet S.A. de C.V. 11492 1194 1182 Cable One 18566 1061 1051 Covad Communications 4755 1216 1037 TATA Communications formerly Complete listing at http://thyme.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 16927 UNALLOCATED 12.0.252.0/23 7018 AT&T WorldNet Servic 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 7018 AT&T WorldNet Servic 13746 UNALLOCATED 12.24.56.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.25.107.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.152.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.154.0/23 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.159.0/24 7018 AT&T WorldNet Servic 32326 UNALLOCATED 12.40.49.0/24 7018 AT&T WorldNet Servic 25639 UNALLOCATED 12.41.169.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 24.75.116.0/22 10796 ServiceCo LLC - Road Runner 24.75.160.0/19 7843 Adelphia Corp. 24.246.0.0/17 7018 AT&T WorldNet Services 24.246.128.0/18 7018 AT&T WorldNet Services 41.220.16.0/20 8668 TelOne Zimbabwe P/L 41.223.112.0/22 5713 Telkom SA Ltd 41.223.188.0/24 22351 Intelsat 41.223.189.0/24 26452 Local Communications Networks 62.61.220.0/24 24974 Tachyon Europe BV - Wireless 62.61.221.0/24 24974 Tachyon Europe BV - Wireless Complete listing at http://thyme.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:19 /9:10 /10:20 /11:55 /12:163 /13:320 /14:576 /15:1132 /16:10354 /17:4622 /18:7971 /19:17011 /20:20057 /21:19757 /22:25245 /23:25252 /24:148046 /25:698 /26:867 /27:545 /28:118 /29:37 /30:9 /31:0 /32:7 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2804 4322 bellsouth.net, inc. 209 1574 2846 Qwest 4766 1394 1690 Korea Telecom (KIX) 17488 1300 1529 Hathway IP Over Cable Interne 8452 1217 1238 TEDATA 11492 1149 1194 Cable One 1785 1139 1733 PaeTec Communications, Inc. 18566 1042 1061 Covad Communications 2386 960 1265 AT&T Data Communications Serv 9583 944 1092 Sify Limited Complete listing at http://thyme.apnic.net/current/data/sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 4:13 8:171 12:2199 13:2 15:19 16:3 17:4 20:36 24:1123 32:51 38:547 40:97 41:1969 43:1 44:2 47:21 52:3 55:2 56:3 57:25 58:534 59:623 60:460 61:1103 62:1113 63:2012 64:3554 65:2421 66:3554 67:1494 68:672 69:2506 70:508 71:163 72:1665 73:2 74:1431 75:204 76:312 77:825 78:566 79:299 80:963 81:819 82:558 83:420 84:591 85:1015 86:395 87:634 88:351 89:1494 90:44 91:2049 92:273 93:1092 94:1189 95:766 96:98 97:177 98:228 99:16 109:1 110:8 112:81 113:88 114:213 115:232 116:1130 117:496 118:285 119:644 120:133 121:704 122:969 123:558 124:955 125:1285 128:220 129:225 130:135 131:410 132:74 133:9 134:183 135:39 136:236 137:144 138:146 139:78 140:415 141:105 142:390 143:329 144:331 145:41 146:373 147:148 148:512 149:237 150:142 151:201 152:151 153:135 154:11 155:267 156:167 157:295 158:131 159:234 160:281 161:137 162:270 163:145 164:518 165:517 166:274 167:357 168:666 169:162 170:478 171:39 172:10 173:241 174:145 178:1 186:10 187:46 188:7 189:314 190:2697 192:5813 193:4217 194:3321 195:2696 196:1057 198:3722 199:3306 200:5485 201:1356 202:7854 203:8069 204:3776 205:2157 206:2356 207:2807 208:3876 209:3455 210:2629 211:1116 212:1514 213:1703 214:69 215:25 216:4554 217:1264 218:365 219:408 220:1207 221:460 222:314 End of report From bobbyjim at gmail.com Fri Mar 13 13:57:56 2009 From: bobbyjim at gmail.com (Bobby Mac) Date: Fri, 13 Mar 2009 13:57:56 -0500 Subject: Dynamic IP log retention = 0? In-Reply-To: <200903131353.n2DDrZLD084617@aurora.sol.net> References: <200903131353.n2DDrZLD084617@aurora.sol.net> Message-ID: Just wondering but the knowledge I have of DHCP is that an IP address is assigned to the same computer (or host) and will continue to do so until the pool of IP's is exhausted. Once that occurs, a new request is parsed by the DHCP server and the oldest non-renewed lease address is checked to see if it is live. If no response occurs then the DHCP server assigns that IP to the requesting host. It's much more efficient to write once and check that then it is to write everytime.This is done to save resources on the DHCP server not much unlike the cache on a DNS server. Every look up does not travers the root servers and the auth server, only those that have expired cached entries. Wouldn't it create a DOS against the DHCP server if every host constantly required the server go through the aformentioned process? It does whit in DNS. Change the expire to 2 and the ttl to 2 and see what happens. This did happen for boxsports dot com (what rhymes with box? not sure of the legalities around saying the name). An SA, while trouble shooting, did just that and about 1 month later BOOM! crap hit the fan. It appearedd as though our DNS auth servers were being DOS'd but all requests were legit. The entry was not cached. That said, unless Covad is constantly exhausting it's pool or they mandate that after the lease expires to give a different IP a reverse lookup would give you the hostname of the offender which should remain accurate for some amount of time. No action on Covads part constitutes legal action on yoru part... -Bobbyjim On Fri, Mar 13, 2009 at 8:53 AM, Joe Greco wrote: > > On Thu, Mar 12, 2009 at 8:52 PM, Joe Greco wrote: > > > > Well most port scanning is from compromised boxes. Once a > > > > box is compromised it can be used for *any* sort of attack. > > > > If you really care about security you take reports of ports > > > > scans seriously. > > > > > > Yeahbut, the real problem is that port scanning is typically used as > > > part of a process to infect _other_ boxes. If you allow this sort of > > > illness to spread, the patient (that is, the Internet) doesn't get > > > better. > > > > Port scanning is the Internet equivelant of the common cold. They're a > dime > > a dozen. > > > > I recommend taking some Vitamin B and D. Block, and Drop. > > No, it's more comparable to the jerk who not only doesn't stay at home > with his cold, but actively walks around the workplace coughing and > sneezing without covering his mouth/nose with a kleenex, spraying people. > > The reality is that it fails the "if everybody did this, would it be a > good thing" test. While some "B&D" is common sense on the receiving end, > this does not make it any more correct for the originating site to let it > keep happening. If every PC on the Internet (conservatively, let's > assume a billion devices that are sufficiently sophisticated that they > could be infected) were to send you a single packet per day, you'd be > seeing over 10,000pps. That should suggest that the behaviour is not > something to be encouraged. > > My locking my doors does not mean it's okay for you to check if my door > is locked. > > ... JG > -- > Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net > "We call it the 'one bite at the apple' rule. Give me one chance [and] then > I > won't contact you again." - Direct Marketing Ass'n position on e-mail > spam(CNN) > With 24 million small businesses in the US alone, that's way too many > apples. > > From surfer at mauigateway.com Fri Mar 13 15:59:14 2009 From: surfer at mauigateway.com (Scott Weeks) Date: Fri, 13 Mar 2009 13:59:14 -0700 Subject: Multi-home with same provider, BGP convergence issues Message-ID: <20090313135914.F79B2827@resin14.mta.everyone.net> --- nick at switchtower.org wrote: From: "Nicholas R. Cappelletti" I can provide a .png of our current setup for reference or any further information needed. Any help anyone can provide will be greatly appreciated. ----------------------------------------- The best thing to do is put the diagram and configs on a web site and give us the link. scott From Valdis.Kletnieks at vt.edu Fri Mar 13 16:15:50 2009 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 13 Mar 2009 17:15:50 -0400 Subject: Dynamic IP log retention = 0? In-Reply-To: Your message of "Fri, 13 Mar 2009 13:57:56 CDT." References: <200903131353.n2DDrZLD084617@aurora.sol.net> Message-ID: <31861.1236978950@turing-police.cc.vt.edu> On Fri, 13 Mar 2009 13:57:56 CDT, Bobby Mac said: > That said, unless Covad is constantly exhausting it's pool or they mandate > that after the lease expires to give a different IP a reverse lookup would > give you the hostname of the offender which should remain accurate for some > amount of time. No action on Covads part constitutes legal action on yoru > part... OK. So you get hit by 129.257.34.98. You look up the PTR and get back 98.34.257.129.cable-pool-slash-12.covad.net. What did you gain here? You knew it was in a Covad /12 before, and that's all you know after, and Covad *still* isn't stopping their customer's bad behavior. After all, you didn't *really* care that the IP was assigned to a computer belonging to Herman Munster, 1313 Mockingbird Lane. What you actually *wanted* was for somebody (preferably Covad) to hand Herman a clue. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From dhc2 at dcrocker.net Fri Mar 13 16:40:10 2009 From: dhc2 at dcrocker.net (Dave CROCKER) Date: Fri, 13 Mar 2009 14:40:10 -0700 Subject: DNS support for DKIM Message-ID: <49BAD2BA.9090807@dcrocker.net> Folks, Hi. I maintain DKIM's web site, which includes: DKIM Software and Services Deployment Reports and am interested in adding entries for relevant DNS services. The page lists software, services and consultants that perform DKIM functions. Recent discussions about the use of DNS for DKIM have made clear that we need the page to provide a more detailed listing of specific DKIM-related DNS functions. So the template for the page now covers: > DNS = Supports DNS administration > > _names: Creation of domain names that include underscores > TXT: Creation of DKIM parameters, under underscore name > NS: Creation, under underscore name > wizard: User interface that facilitates creating DKIM-specific > records. I'm interested in adding entries for /all/ software and services (packages, ISPs, DNS providers, etc.) that can perform the necessary DNS functions needed by DKIM. For those wishing to, please complete the template for an entry, per: and send it to me. Thanks. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From ge at linuxbox.org Fri Mar 13 20:39:07 2009 From: ge at linuxbox.org (Gadi Evron) Date: Fri, 13 Mar 2009 20:39:07 -0500 (CDT) Subject: wires mess thread Message-ID: This came across my RSS feed today from gizmodo: http://www.reddit.com/r/technology/comments/845v3/this_data_center_has_got_its_shit_together/ From Charles at thewybles.com Fri Mar 13 22:45:52 2009 From: Charles at thewybles.com (Charles at thewybles.com) Date: Sat, 14 Mar 2009 03:45:52 +0000 Subject: Dynamic IP log retention = 0? In-Reply-To: References: <200903131353.n2DDrZLD084617@aurora.sol.net> Message-ID: <740004651-1237002383-cardhu_decombobulator_blackberry.rim.net-1888426985-@bxe1296.bisx.prod.on.blackberry> Um.... Aren't dsl addresses handed out over ipcp? So perhaps a bit more static then dhcp? Sent via BlackBerry from T-Mobile -----Original Message----- From: Bobby Mac Date: Fri, 13 Mar 2009 13:57:56 To: Subject: Re: Dynamic IP log retention = 0? Just wondering but the knowledge I have of DHCP is that an IP address is assigned to the same computer (or host) and will continue to do so until the pool of IP's is exhausted. Once that occurs, a new request is parsed by the DHCP server and the oldest non-renewed lease address is checked to see if it is live. If no response occurs then the DHCP server assigns that IP to the requesting host. It's much more efficient to write once and check that then it is to write everytime.This is done to save resources on the DHCP server not much unlike the cache on a DNS server. Every look up does not travers the root servers and the auth server, only those that have expired cached entries. Wouldn't it create a DOS against the DHCP server if every host constantly required the server go through the aformentioned process? It does whit in DNS. Change the expire to 2 and the ttl to 2 and see what happens. This did happen for boxsports dot com (what rhymes with box? not sure of the legalities around saying the name). An SA, while trouble shooting, did just that and about 1 month later BOOM! crap hit the fan. It appearedd as though our DNS auth servers were being DOS'd but all requests were legit. The entry was not cached. That said, unless Covad is constantly exhausting it's pool or they mandate that after the lease expires to give a different IP a reverse lookup would give you the hostname of the offender which should remain accurate for some amount of time. No action on Covads part constitutes legal action on yoru part... -Bobbyjim On Fri, Mar 13, 2009 at 8:53 AM, Joe Greco wrote: > > On Thu, Mar 12, 2009 at 8:52 PM, Joe Greco wrote: > > > > Well most port scanning is from compromised boxes. Once a > > > > box is compromised it can be used for *any* sort of attack. > > > > If you really care about security you take reports of ports > > > > scans seriously. > > > > > > Yeahbut, the real problem is that port scanning is typically used as > > > part of a process to infect _other_ boxes. If you allow this sort of > > > illness to spread, the patient (that is, the Internet) doesn't get > > > better. > > > > Port scanning is the Internet equivelant of the common cold. They're a > dime > > a dozen. > > > > I recommend taking some Vitamin B and D. Block, and Drop. > > No, it's more comparable to the jerk who not only doesn't stay at home > with his cold, but actively walks around the workplace coughing and > sneezing without covering his mouth/nose with a kleenex, spraying people. > > The reality is that it fails the "if everybody did this, would it be a > good thing" test. While some "B&D" is common sense on the receiving end, > this does not make it any more correct for the originating site to let it > keep happening. If every PC on the Internet (conservatively, let's > assume a billion devices that are sufficiently sophisticated that they > could be infected) were to send you a single packet per day, you'd be > seeing over 10,000pps. That should suggest that the behaviour is not > something to be encouraged. > > My locking my doors does not mean it's okay for you to check if my door > is locked. > > ... JG > -- > Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net > "We call it the 'one bite at the apple' rule. Give me one chance [and] then > I > won't contact you again." - Direct Marketing Ass'n position on e-mail > spam(CNN) > With 24 million small businesses in the US alone, that's way too many > apples. > > From frnkblk at iname.com Fri Mar 13 23:49:32 2009 From: frnkblk at iname.com (Frank Bulk) Date: Fri, 13 Mar 2009 23:49:32 -0500 Subject: SBC NOC contact In-Reply-To: <1236964851.29982.19.camel@petrie> References: <1236964851.29982.19.camel@petrie> Message-ID: Try DNSCONTACT at att.com; that's what comes up when I WHOIS the domain pbi.net. Frank -----Original Message----- From: William Pitcock [mailto:nenolod at systeminplace.net] Sent: Friday, March 13, 2009 12:21 PM To: nanog at nanog.org Subject: SBC NOC contact Hello, Does anyone here have an SBC/AT&T NOC contact that goes to an actual human being? Their NOC handle email, support at swbell.net bounces with the following message: | Dear SBC Yahoo! Member, | | Our Support Request site has recently changed. | Please submit your question or comment via our new online form available at | http://help.sbcglobal.net/techquestions.php. | | Thank you for contacting SBC Yahoo! Technical Support. Which is especially funny because I don't do business with SBC at all. Also, their website leads us to a "we don't take emails anymore" message. But I digress, their nameservers are out of sync, causing problems with reverse DNS suddenly going away for some SBC IPs in our logs. Appears to be an issue with ns1.pbi.net... So yeah, if someone knows somebody who could fix that, that would be fantastic. -- William Pitcock SystemInPlace - Simple Hosting Solutions 1-866-519-6149 From nonobvious at gmail.com Sat Mar 14 00:14:51 2009 From: nonobvious at gmail.com (Bill Stewart) Date: Fri, 13 Mar 2009 22:14:51 -0700 Subject: Dynamic IP log retention = 0? In-Reply-To: <31861.1236978950@turing-police.cc.vt.edu> References: <200903131353.n2DDrZLD084617@aurora.sol.net> <31861.1236978950@turing-police.cc.vt.edu> Message-ID: <18a5e7cb0903132214x58b71becu178c238ae93a7e27@mail.gmail.com> On Fri, Mar 13, 2009 at 2:15 PM, wrote: > ?After all, you didn't *really* care that the IP was assigned to > a computer belonging to Herman Munster, 1313 Mockingbird Lane. ?What you > actually *wanted* was for somebody (preferably Covad) to hand Herman a clue. Yeah. I miss the days that you could fix Covad problems by calling Brent, or by sending the attacker a Ping of Death :-) In practice, of course, the chances are extremely high that the attacker is a zombie pc whose owner is not aware that it's infected, and they really need their ISP to quarantine them somewhere until they can get it fixed. -- ---- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it. From ross at dillio.net Sat Mar 14 00:56:24 2009 From: ross at dillio.net (Ross) Date: Sat, 14 Mar 2009 00:56:24 -0500 (CDT) Subject: Dynamic IP log retention = 0? In-Reply-To: <200903130013.n2D0D2ao011861@aurora.sol.net> References: <200903130013.n2D0D2ao011861@aurora.sol.net> Message-ID: Joe, I'll respond to you and this will be my last reply to this thread because I know I won't be able to change your mind. Saying a company's business decisions are antisocial just because they aren't doing you want is very unhelpful. I don't know how many large ISPs you have worked for but I'm not sure if you understand corporate budgets or politics. If you consider people who port scan the bad guys of the internet then obviously you and I are two different planes of reality. I had a discussion today with someone who I immensely respect where I talked about port scanning and how people compare it to trying to break in to someone's house. He disagreed and said that port scanning was like being a part of the neighborhood watch and that trying to exploit any vulnerabilities you find would be an attempted break in, I have to agree. As for your second point of comparing port scanning to the heinous crimes of rape I'll just ask, "have you lost your damn mind"? Seriously, port scanning a machine compared to the horrid act of abusing someone sexually? Seriously, what will be your next analogy, pedophiles are the same as file sharers? Port scanning can be a method to find vulnerabilities indeed but what of those of us who port scan before we use certain services? I often scan certain hosts before I use them to make sure they don't have gaping vulnerabilities, should I go to jail? The op said nothing about an attack but only a scan, so don't go there. Your idea of operations seems simple because you have the black and white barrier, there is no gray for you. Some of us actually have a larger userbase and very small budgets. Now I'll say that the company I work for goes after network abusers vigorously. To say that port scanners are miscreants and abusers is your view. I think everyone wants to stop botnets and exploits from spreading but Joe, people don't have to answer to you just because you feel that you are privileged because you have a role in the internet. Scanning and attacks are two different things and I hope you realize this. If a host on my network is attacking a host on yours I'm sure we will work to stop it quickly. If you demand that I turn over the person who scanned you last night at 12:52 am I may ignore you. I wish you the best of luck against your crusade against the evil of port scanning. -- Ross ross [at] dillio.net >> Whether Covad chooses to enforce their AUP against port scanning is a >> business decision up to them. > > Yes, it's all a business decision. That kind of antisocial thinking is > the sort of thing that has allowed all manner of bad guys to remain > attached to the Internet. > >> Again, why worry about things out of your >> control, especially when we are talking about port scanning. > > Yes, why not talk about rapists and drug dealers instead. They're much > worse. It's just that this forum ... isn't for that. > >> I would think people have more pressing issues, guess not. > > While I am all for increasing overall security on the Internet, the > reality is that there will often be devices that are attached that > are found to be vulnerable in new and intriguing ways. Port scanning > is a primary method for finding these vulnerabilities. To the extent > that an ISP might proactively port scan its own userbase, that's a good > use and probably a good idea (has tradeoffs), but bad guys finding > holes in random devices so that they can launch multiGbps attacks > against random destinations is a bad thing. > > If your idea of "operations" is to make your router work and collect > your paycheck for another day, then this discussion probably does not > make any sense to you and you probably don't understand the importance > of the issue. > > If your idea of "operations" is to ensure the reliable operation and > uphold the performance standards of an IP network, then it should not > be beyond comprehension that allowing miscreants access to the network > is one of many things that can adversely affect operations. If you > accept that the presence of miscreants on the network is a negative, > it shouldn't be hard to see that complaining about consistent and > persistent port scans from what is probably an identifiable host is > one way to make an impact. > > ... JG > -- > Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net > "We call it the 'one bite at the apple' rule. Give me one chance [and] > then I > won't contact you again." - Direct Marketing Ass'n position on e-mail > spam(CNN) > With 24 million small businesses in the US alone, that's way too many > apples. > From Valdis.Kletnieks at vt.edu Sat Mar 14 01:15:17 2009 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sat, 14 Mar 2009 02:15:17 -0400 Subject: Dynamic IP log retention = 0? In-Reply-To: Your message of "Sat, 14 Mar 2009 00:56:24 CDT." References: <200903130013.n2D0D2ao011861@aurora.sol.net> Message-ID: <88735.1237011317@turing-police.cc.vt.edu> On Sat, 14 Mar 2009 00:56:24 CDT, Ross said: > I know I won't be able to change your mind. Saying a company's business > decisions are antisocial just because they aren't doing you want is very > unhelpful. I don't know how many large ISPs you have worked for but I'm > not sure if you understand corporate budgets or politics. Ross - it doesn't help when you turn around and present another false dichotomy. It's quite possible that Joe *does* understand corporate budgets and politics, and *still* thinks that business decisions are antisocial. In fact, one can fairly easily argue that *many* of our current socio-economic issues are due to the fact that corporate decisions are in general required to be in the stockholder's interests, not society's. In other words, they are in general *by definition* anti-social. So the correct phrasing is "How do we change the anti-social behavior into something less anti-social which still pleases the stockholders?" > Seriously, what will be your next analogy, pedophiles are the same as file > sharers? Paging Jack Valenti... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From ross at dillio.net Sat Mar 14 01:39:43 2009 From: ross at dillio.net (Ross) Date: Sat, 14 Mar 2009 01:39:43 -0500 (CDT) Subject: Dynamic IP log retention = 0? In-Reply-To: <88735.1237011317@turing-police.cc.vt.edu> References: <200903130013.n2D0D2ao011861@aurora.sol.net> <88735.1237011317@turing-police.cc.vt.edu> Message-ID: <2565e2b2b87130594eabdf6efdfa84da.squirrel@www.dillio.net> Vladis, I'm not going to argue with you on a socio economic opinion that companies who have stock holders are evil because they don't spend their funds where they want you to and promote anti-social behavior by doing so. If you think society's biggest problem is to stop port scanning then I hope you succeed in your crusade. I think many of us have bigger problems than you getting port scanned but if you every truly get attacked, I'll be there to help. As a good friend of mine says "no one ever goes to work and says, how am I going to suck today." We can all improve in our operations, public shaming for not dropping ones other duties to hand over information that you aren't privileged to is a bit sad. *nite* -- Ross ross [at] dillio.net > On Sat, 14 Mar 2009 00:56:24 CDT, Ross said: >> I know I won't be able to change your mind. Saying a company's business >> decisions are antisocial just because they aren't doing you want is very >> unhelpful. I don't know how many large ISPs you have worked for but I'm >> not sure if you understand corporate budgets or politics. > > Ross - it doesn't help when you turn around and present another false > dichotomy. > > It's quite possible that Joe *does* understand corporate budgets and > politics, > and *still* thinks that business decisions are antisocial. In fact, one > can > fairly easily argue that *many* of our current socio-economic issues are > due > to the fact that corporate decisions are in general required to be in the > stockholder's interests, not society's. In other words, they are in > general > *by definition* anti-social. > > So the correct phrasing is "How do we change the anti-social behavior into > something less anti-social which still pleases the stockholders?" > >> Seriously, what will be your next analogy, pedophiles are the same as >> file >> sharers? > > Paging Jack Valenti... > From jcdill.lists at gmail.com Sat Mar 14 01:52:34 2009 From: jcdill.lists at gmail.com (JC Dill) Date: Fri, 13 Mar 2009 23:52:34 -0700 Subject: Dynamic IP log retention = 0? In-Reply-To: <2565e2b2b87130594eabdf6efdfa84da.squirrel@www.dillio.net> References: <200903130013.n2D0D2ao011861@aurora.sol.net> <88735.1237011317@turing-police.cc.vt.edu> <2565e2b2b87130594eabdf6efdfa84da.squirrel@www.dillio.net> Message-ID: <49BB5432.3060502@gmail.com> Ross wrote: > We can all improve in our operations, public shaming > for not dropping ones other duties to hand over information that you > aren't privileged to is a bit sad. No one asked anyone to "hand over information that they weren't privileged to". Trying to publicly shame someone for asking for this, when they asked for no such thing, is more than a bit sad. What was requested is that Covad deal with their problem customer. Covad tried to claim that they couldn't deal with it because supposedly they don't have any logs of which customer had the IP less than 48 hours ago, which is just not very believable. There also wasn't any indication that Covad claimed they had more important duties to attend to and that this wasn't important to address - they just claimed they "can't" address it because they don't have log data to link the IP to the customer. jc From jgreco at ns.sol.net Sat Mar 14 02:42:04 2009 From: jgreco at ns.sol.net (Joe Greco) Date: Sat, 14 Mar 2009 01:42:04 -0600 (CST) Subject: Dynamic IP log retention = 0? In-Reply-To: from "Ross" at Mar 14, 2009 12:56:24 AM Message-ID: <200903140742.n2E7g4rC022030@aurora.sol.net> > Joe, > > I'll respond to you and this will be my last reply to this thread because > I know I won't be able to change your mind. Yes, it's clear *you* won't be able to. > Saying a company's business > decisions are antisocial just because they aren't doing you want is very > unhelpful. Well, then, it's good that that's not what's happening. There are lots of things I would want a business to do that most of 'em aren't doing. We aren't talking about any of those things. We're talking about something that is commonly understood to be a bad thing, bad enough that most AUP's explicitly forbid it. > I don't know how many large ISPs you have worked for but I'm > not sure if you understand corporate budgets or politics. I have worked for large ISP's, I understand corporate budgets and politics, and I'm smart enough to understand that "corporate budgets and politics" do not define what is acceptable within the framework of the Internet. Were "corporate budgets and politics" to define that, we'd be likely to see a balkanized, spam-riddled ghost-of-what-used-to-be-the-Internet where the potential for making a buck defines what is right and what is wrong. Modern corporations are responsible to their shareholders, and many people feel this gives them a free pass. Staffing an abuse desk and reducing these sorts of emissions would seem to be more costly, and certainly there are people who cut corners on their abuse departments in order to save a buck, but the point is that this ultimately results in greater costs further out, when your network is riddled with problems, and your upstreams and peers are applying pressure to you to stop the DDoS attacks coming from your network. Regardless, many companies follow that path, in search of "better performance this quarter." We've seen it all before, and we'll see it all again. Eventually it gets bad enough that either your policies cause you to fold (AGIS, etc), or you're forced to clean up. More enlightened companies can take a longer view, and they'll realize that a well-run network is actually a valuable asset. > If you consider people who port scan the bad guys of the internet then > obviously you and I are two different planes of reality. Clearly. Because the people who port scan are the people who are breaking into boxes (whether manually or automatically), and the people who are breaking into boxes are generally people with no good intent. If you think these are "good guys," you definitely *are* on a different plane of reality. > I had a > discussion today with someone who I immensely respect where I talked about > port scanning and how people compare it to trying to break in to someone's > house. He disagreed and said that port scanning was like being a part of > the neighborhood watch and that trying to exploit any vulnerabilities you > find would be an attempted break in, I have to agree. Random port scanning is not like "the neighborhood watch." Neighborhood watches are set up by a neighbor you know, and presumably trust, and even if they have a ridiculous policy of testing doorknobs, they will respect it if you tell them you don't want to participate. Some ISP's fulfill this role by proactively scanning their own IP space for vulnerable machines. They'll tell you your box is hackable, or maybe even sandbox you. That's equivalent to a neighborhood watch. What you're defending is some guy in a ski mask who comes in and visits each house, testing all the doors and windows to see if they open, and who makes note of vulnerable houses. Maybe he then leaves, maybe he then breaks into a house. Even if he leaves, he's leaving with knowledge of insecure houses, and we know that this knowledge is not going to be put to a *positive* use. How you can possibly equate this to a "neighborhood watch" is beyond me. > As for your second point of comparing port scanning to the heinous crimes > of rape I'll just ask, "have you lost your damn mind"? No, of course I haven't, but then again I didn't make such a comparison. I did say "they're much worse." You might want to go back and re-read that little exchange, as you clearly didn't comprehend what I was saying. > Seriously, port > scanning a machine compared to the horrid act of abusing someone sexually? > Seriously, what will be your next analogy, pedophiles are the same as file > sharers? Seriously, try reading for comprehension. > Port scanning can be a method to find vulnerabilities indeed but what of > those of us who port scan before we use certain services? Scanning a machine that you're authorized to access is not at issue here. > I often scan > certain hosts before I use them to make sure they don't have gaping > vulnerabilities, should I go to jail? See above. And below. > The op said nothing about an attack but only a scan, so don't go there. Ah ha. See, you've just tried to equate your scanning of some machine that you are authorized to use, with what the original poster was complaining about, which was relentless scans by an unauthorized party, where the responsible party actually explicitly requested that such scans stopped. You're trying to make a case that the second case is acceptable because the first is? You're showing yourself as being unable to argue your way out of a paper bag. > Your idea of operations seems simple because you have the black and white > barrier, there is no gray for you. The hell you say. > Some of us actually have a larger userbase and very small budgets. Your budget is a choice. Maybe not your choice personally, but a choice by someone, regardless. Choices have consequences. Maybe not immediately, but eventually. The ability to see (and ideally, to harness) the long-term effect of your choices is generally what differentiates most of the successful companies that I've seen. > Now I'll say that the company I work for > goes after network abusers vigorously. To say that port scanners are > miscreants and abusers is your view. Hm. Well, even dodgy providers like SAVVIS recognize port scanning as a problem: http://www9.savvis.net/corp/Acceptable%20Use%20Policy Section B subsection 2: "including any activity that typically precedes attempts to breach security such as scanning, probing, or other testing or vulnerability assessment activity," So, um, who exactly is it that you work for, I'd love to check out their AUP (tfic). > I think everyone wants to stop botnets and exploits from spreading but > Joe, people don't have to answer to you just because you feel that you are > privileged because you have a role in the internet. You seem to be attributing to me something I didn't say. > Scanning and attacks > are two different things and I hope you realize this. One could reasonably say that one is a lesser form of the second. When someone is doing something that is clearly and unambiguously "casing the joint," and isn't authorized to be doing so, that could reasonably be construed as an attack. From afar, you have no way to determine whether or not your unauthorized traffic has the potential for costing my site more (maybe I'm on the far end of a really expensive circuit), or maybe interfering with normal operations (overloading syslog reporting due to heavy firewall rejections), etc. You have no idea what effect scanning has on a remote machine, and if you have no business doing it, assuming that it can't be perceived as an attack and that it won't cause problems is naive. > If a host on my > network is attacking a host on yours I'm sure we will work to stop it > quickly. If you demand that I turn over the person who scanned you last > night at 12:52 am I may ignore you. Of course, neither I nor the original poster made any such demand. The original poster simply wanted Covad to "make it stop," which would seem to be a fairly reasonable request. > I wish you the best of luck against your crusade against the evil of port > scanning. Since it's "okay" to do that, why don't you post your employer's IP ranges along with an official invitation for NANOG'ers to scan those ranges? Geez. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From fergdawgster at gmail.com Sat Mar 14 02:48:35 2009 From: fergdawgster at gmail.com (Paul Ferguson) Date: Sat, 14 Mar 2009 00:48:35 -0700 Subject: Zombie Nation [Was: Re: Dynamic IP log retention = 0?] Message-ID: <6cd462c00903140048r1dcab903hf815fd0cdf4f188b@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sat, Mar 14, 2009 at 12:42 AM, Joe Greco wrote: > > I have worked for large ISP's, I understand corporate budgets and > politics, and I'm smart enough to understand that "corporate budgets and > politics" do not define what is acceptable within the framework of the > Internet. Were "corporate budgets and politics" to define that, we'd be > likely to see a balkanized, spam-riddled > ghost-of-what-used-to-be-the-Internet where the potential for making a > buck defines what is right and what is wrong. > As opposed to the spambot-infested, zombified Internet we have now? - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.3 (Build 5003) wj8DBQFJu2FKq1pz9mNUZTMRAvxJAJ9GNeEvWPyjMVyME6t6ZZWJ0Qr5hACgscPg r5qQGjqvhx4DUv+YSQnBe5A= =DEXn -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/ From kngspook at gmail.com Sat Mar 14 03:12:53 2009 From: kngspook at gmail.com (Neil) Date: Sat, 14 Mar 2009 01:12:53 -0700 Subject: Dynamic IP log retention = 0? In-Reply-To: References: Message-ID: <77e4079b0903140112u5de4108am142a04c3884c8da@mail.gmail.com> On Wed, Mar 11, 2009 at 6:34 AM, Brett Charbeneau wrote: > I've been nudging an operator at Covad about a handful of hosts from > his DHCP pool that have been attacking - relentlessly port scanning - our > assets. I've been informed by this individual that there's "no way" to > determine which customer had that address at the times I list in my logs - > even though these logs are sent within 48 hours of the incidents. > The operator advised that I block the specific IP's that are > attacking us at my perimeter. When I mentioned the fact that blocking > individual addresses will only be as effective as the length of lease for > that DHCP pool I get the email equivalent of a shrug. > "Well, maybe you want to ban our entire /15 at your perimeter..." > I'm reluctant to ban over 65,000 hosts as my staff have colleagues > all over the continental US with whom they communicate regularly. > I realize these are tough times and that large ISP's may trim abuse > team budgets before other things, but to have NO MECHANISM to audit who has > what address at any given time kinda blows my mind. > Does one have to get to the level of a subpoena before abuse teams > pull out the tools they need to make such a determination? Or am I naive > enough to think port scans are as important to them as they are to me on the > receiving end? > > I think you are being a little naive. Port scans, while possibly used for malicious ends, can very often be benign. I've port scanned netblocks for such trivia such as the IP of the printer which I forgot to scribble down. (Naturally, this doesn't explain your situation of scanning from another ISP, but you get the idea (I hope).) As William pointed out, it's the things that follow that determine whether someone's being bad. To flag port-scans might be responsible, but I think pursuing legal action over it would be the exact opposite. Wait until someone demonstrates true maliciousness before trying to punish them, rather than bringing the heat merely because they've demonstrated the potential for maliciousness. This is almost akin to attacking someone because they're carrying a gun: sure, the gun gives them the potential to do bad things, but it often enough is innocent. (Political agendas aside...) From bogstad at pobox.com Sat Mar 14 08:24:05 2009 From: bogstad at pobox.com (Bill Bogstad) Date: Sat, 14 Mar 2009 09:24:05 -0400 Subject: Dynamic IP log retention = 0? In-Reply-To: <77e4079b0903140112u5de4108am142a04c3884c8da@mail.gmail.com> References: <77e4079b0903140112u5de4108am142a04c3884c8da@mail.gmail.com> Message-ID: <2d6a9f6f0903140624o5084e3f6v25aaa834f29af743@mail.gmail.com> On Sat, Mar 14, 2009 at 4:12 AM, Neil wrote: > On Wed, Mar 11, 2009 at 6:34 AM, Brett Charbeneau wrote: > >......... >As William pointed out, it's the things that follow that determine whether >someone's being bad. To flag port-scans might be responsible, but I think >pursuing legal action over it would be the exact opposite. Wait until >someone demonstrates true maliciousness before trying to punish them, rather >than bringing the heat merely because they've demonstrated the potential for >maliciousness. In the physical world, this is the equivalent of 'casing the joint'. In most parts of the world, you can now get stopped/interrogated for simply taking pictures of the wrong buildings. (Even ones that in the past might have been considered tourist attractions.) Whether you think this is a good/bad thing, you shouldn't be surprised that people are similarly concerned about such behavior in the virtual world. > > This is almost akin to attacking someone because they're carrying a gun: > sure, the gun gives them the potential to do bad things, but it often enough > is innocent. (Political agendas aside...) No, this is more like some unknown guy in a high-rise a mile a way pointing his laser sniper scope at people walking in the park. They don't KNOW that he has a rifle attached to that scope. Even if he does, they don't KNOW that he plans to use it. Most people will never notice that little red dot in the middle of their chest. If they do notice and report it, however, I can guarantee that a significant investigation will take place. Bill Bogstad From cmadams at hiwaay.net Sat Mar 14 15:35:19 2009 From: cmadams at hiwaay.net (Chris Adams) Date: Sat, 14 Mar 2009 15:35:19 -0500 Subject: Dynamic IP log retention = 0? In-Reply-To: <77e4079b0903140112u5de4108am142a04c3884c8da@mail.gmail.com> References: <77e4079b0903140112u5de4108am142a04c3884c8da@mail.gmail.com> Message-ID: <20090314203519.GA752337@hiwaay.net> Once upon a time, Neil said: > I think you are being a little naive. Port scans, while possibly used for > malicious ends, can very often be benign. That sounds naive to me. From what I've seen, the number of malicious scans is much greater than the number of benign scans. The vast majority of end users have no idea what a port scan is or how to run one (or how to make sense of the output if they saw one run). In any case, this isn't really about the port scan. This is about Covad claiming they cannot identify who had an IP 48 hours ago. What if it wasn't a port scan; what if it was a DoS attack, spamming bot, etc.? Do you think Covad would respond to a DMCA complaint like that? -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From jcdill.lists at gmail.com Sat Mar 14 16:08:14 2009 From: jcdill.lists at gmail.com (JC Dill) Date: Sat, 14 Mar 2009 14:08:14 -0700 Subject: Dynamic IP log retention = 0? In-Reply-To: <20090314203519.GA752337@hiwaay.net> References: <77e4079b0903140112u5de4108am142a04c3884c8da@mail.gmail.com> <20090314203519.GA752337@hiwaay.net> Message-ID: <49BC1CBE.5030201@gmail.com> Chris Adams wrote: > > Do you think Covad would respond to a DMCA complaint like that? > That's actually the one thing that would make sense of this - that they *do* purge the logs fast enough that they could reply to a DMCA complaint by saying "sorry, we don't have logs". The question is, in doing so are they also purging the logs so fast they can't deal with customers that cause problems for Covad itself? If so, then they probably aren't purging the logs this fast, they just said so to avoid having to deal with their customers that are posing problems for others, and they probably would respond quite differently if it were a legal matter (where lying equals perjury) rather than just a "complaint". jc From nanog at capequilog.com Sat Mar 14 16:13:45 2009 From: nanog at capequilog.com (Jeff Wheelhouse) Date: Sat, 14 Mar 2009 17:13:45 -0400 Subject: AT&T Security Contact Message-ID: <9E43A0E3-5949-45C7-8442-7DDFD1DF6E8B@capequilog.com> Hi All, One of our customers has forwarded us a rambling, disjointed threat from someone sending from abuse at sbcglobal.net who claims to be "the Security Manager for AT&T Internet Services Security Center, its subsidiaries and affiliates" who won't provide a name or personal contact information but who promises to (and I quote) "DNS Block" some of the customer's IP's (in our allocation) over a problem AT&T has with one of the customer's customers. After reading the message, I checked the situation myself and the problem complained about appears to have been resolved some time ago, if it ever existed at all. Also, the IP's in question are not, as far as I know, DNS servers; I am quite sure they are shared hosting IP's, so I don't know what AT&T is proposing to do, exactly, but it sounds like a threat to interfere with a bunch of innocent people's web sites for what appear to be bogus reasons. They have ignored multiple confirmed-delivery-I've-seen-the-logs attempts to respond by our customer, our customer's customer, and myself. Could I please get someone from AT&T to contact me off-list about this before it turns into a "thing?" Thanks! Jeff From globichen at gmail.com Sat Mar 14 20:55:51 2009 From: globichen at gmail.com (Andy Bierlair) Date: Sun, 15 Mar 2009 02:55:51 +0100 Subject: Netflow on SUP720-3BXL Message-ID: I?m trying to run netflow on one of our Cisco core routers (SUP720-3BXL), but I think I am hitting some limitations because of this: %EARL_NETFLOW-SP-4-TCAM_THRLD: Netflow TCAM threshold exceeded, TCAM Utilization [99%] The setup of netflow looks like this: ip flow-cache entries 524288 mls aging fast time 5 threshold 32 mls aging long 300 mls aging normal 60 mls netflow usage notify 80 300 mls flow ip full no mls flow ipv6 mls nde sender version 5 no mls verify ip checksum no mls acl tcam share-global ip flow-export source Loopback0 ip flow-export version 5 origin-as ip flow-export destination Then I have this enabled on all border interfaces/vlans (peering / transit / other core routers) that are of interest for my stats: ip route-cache flow Some more details about the problem: #sh mls netflow table-contention detailed Earl in Module 5 Detailed Netflow CAM (TCAM and ICAM) Utilization ================================================ TCAM Utilization : 100% ICAM Utilization : 13% Netflow TCAM count : 262033 Netflow ICAM count : 17 Netflow Creation Failures : 4822220 Netflow CAM aliases : 1 #sh mls netflow table-contention aggregate Earl in Module 5 Aggregate Netflow CAM Contention Information ============================================= Netflow Creation Failures : 130003616 Netflow Hash Aliases : 4 I understand that the TCAM is full, but what can I do against it? This is a busy core router: Aggregated traffic: 7-8 GBIT/s Packets per Second: 1.0 - 1.2 Million I wouldn't mind analyzing only every 10th or 100th flow, which seems to be a common practice. Any good piece of advice is welcome. Thanks! - Andy From kngspook at gmail.com Sat Mar 14 21:05:46 2009 From: kngspook at gmail.com (Neil) Date: Sat, 14 Mar 2009 19:05:46 -0700 Subject: Dynamic IP log retention = 0? In-Reply-To: <2d6a9f6f0903140624o5084e3f6v25aaa834f29af743@mail.gmail.com> References: <77e4079b0903140112u5de4108am142a04c3884c8da@mail.gmail.com> <2d6a9f6f0903140624o5084e3f6v25aaa834f29af743@mail.gmail.com> Message-ID: <77e4079b0903141905k5f0951c2v640d5a003c18d549@mail.gmail.com> On Sat, Mar 14, 2009 at 6:24 AM, Bill Bogstad wrote: > On Sat, Mar 14, 2009 at 4:12 AM, Neil wrote: > > On Wed, Mar 11, 2009 at 6:34 AM, Brett Charbeneau wrote: > > > >......... > >As William pointed out, it's the things that follow that determine whether > >someone's being bad. To flag port-scans might be responsible, but I think > >pursuing legal action over it would be the exact opposite. Wait until > >someone demonstrates true maliciousness before trying to punish them, > rather > >than bringing the heat merely because they've demonstrated the potential > for > >maliciousness. > > In the physical world, this is the equivalent of 'casing the joint'. > In most parts of the world, you can now get stopped/interrogated for > simply taking pictures of the wrong buildings. (Even ones that in the > past might have been considered tourist attractions.) Whether you > think this is a good/bad thing, you shouldn't be surprised that people > are similarly concerned about such behavior in the virtual world. > Getting stopped/interrogated for simply taking pictures of tourist-y, or other, buildings is over-reacting as well, in my opinion. (For nearly all of them, there are already existing pictures of them; and once the Bad Guys get wind that people are being stopped for taking pictures, they'll either use already existing pictures, or go up and take them, get stopped, and blend in with all the other innocent people taking pictures... Pointless, unless someone's sitting on some magical Bad-Guy-Identifier that only works in interrogations.) And there's another name for 'casing the joint', it is 'looking around'. Looking around generally isn't a crime. Neither is casing a joint, for that matter. And like I suggested with port scanning, whether someone was 'looking around' or 'casing the joint' is really only determinable after they've robbed the joint or not. Before that point, you're almost stabbing in the dark. > > > > > This is almost akin to attacking someone because they're carrying a gun: > > sure, the gun gives them the potential to do bad things, but it often > enough > > is innocent. (Political agendas aside...) > > No, this is more like some unknown guy in a high-rise a mile a way > pointing his laser sniper scope at people walking in the park. They > don't KNOW that he has a rifle attached to that scope. Even if he > does, > they don't KNOW that he plans to use it. Most people will never > notice that little red dot in the middle of their chest. If they do > notice and report it, however, I can guarantee that a significant > investigation will > take place. > That's a bit questionable as well; the intention with a port scan is hardly so well defined as you suggest. And what if that little red dot is simply a laser pointer? I think I'd assume laser pointer before laser-aiming sniper, following the "Don't attribute to malice what could be attributed to stupidity instead" maxim or Occam's Razor... From globichen at gmail.com Sat Mar 14 21:20:20 2009 From: globichen at gmail.com (Andy Bierlair) Date: Sun, 15 Mar 2009 03:20:20 +0100 Subject: Netflow on SUP720-3BXL In-Reply-To: <6069A203FD01884885C037F81DD75080CA0CA730@wsc-mail-01.intra.nwresd.k12.or.us> References: <6069A203FD01884885C037F81DD75080CA0CA730@wsc-mail-01.intra.nwresd.k12.or.us> Message-ID: yes ip cef, this is enabled: IP fast switching is enabled IP fast switching on the same interface is disabled IP Flow switching is enabled IP CEF switching is enabled IP Flow switching turbo vector IP Flow CEF switching turbo vector and so on... - Andy On Sun, Mar 15, 2009 at 3:08 AM, Bill Blackford wrote: > > just a shot in the dark. Do you have 'ip cef' in global config? > > -b > ________________________________________ > From: Andy Bierlair [globichen at gmail.com] > Sent: Saturday, March 14, 2009 6:55 PM > To: nanog at nanog.org > Subject: Netflow on SUP720-3BXL > > I?m trying to run netflow on one of our Cisco core routers (SUP720-3BXL), > but I think I am hitting some limitations because of this: > > > > %EARL_NETFLOW-SP-4-TCAM_THRLD: Netflow TCAM threshold exceeded, TCAM > Utilization [99%] > > > > The setup of netflow looks like this: > > > > ?ip flow-cache entries 524288 > > ?mls aging fast time 5 threshold 32 > > ?mls aging long 300 > > ?mls aging normal 60 > > ?mls netflow usage notify 80 300 > > ?mls flow ip full > > ?no mls flow ipv6 > > ?mls nde sender version 5 > > ?no mls verify ip checksum > > ?no mls acl tcam share-global > > > > ?ip flow-export source Loopback0 > > ?ip flow-export version 5 origin-as > > ?ip flow-export destination > > > > Then I have this enabled on all border interfaces/vlans (peering / transit / > other core routers) that are of interest for my stats: > > > > ?ip route-cache flow > > > > Some more details about the problem: > > > > #sh mls netflow table-contention detailed Earl in Module 5 Detailed Netflow > CAM (TCAM and ICAM) Utilization > ================================================ > > TCAM Utilization ? ? ? ? ? ? : ? 100% > > ICAM Utilization ? ? ? ? ? ? : ? 13% > > Netflow TCAM count ? ? ? ? ? : ? 262033 > > Netflow ICAM count ? ? ? ? ? : ? 17 > > Netflow Creation Failures ? ?: ? 4822220 > > Netflow CAM aliases ? ? ? ? ?: ? 1 > > > > > > #sh mls netflow table-contention aggregate Earl in Module 5 Aggregate > Netflow CAM Contention Information > ============================================= > > Netflow Creation Failures ? ?: ? 130003616 > > Netflow Hash Aliases ? ? ? ? : ? 4 > > > > > > I understand that the TCAM is full, but what can I do against it? This is a > busy core router: > > > > Aggregated traffic: 7-8 GBIT/s > > Packets per Second: 1.0 - 1.2 Million > > > > I wouldn't mind analyzing only every 10th or 100th flow, which seems to be a > common practice. > > > > Any good piece of advice is welcome. > > > > Thanks! > > > > - > Andy From jgreco at ns.sol.net Sat Mar 14 22:17:24 2009 From: jgreco at ns.sol.net (Joe Greco) Date: Sat, 14 Mar 2009 21:17:24 -0600 (CST) Subject: Dynamic IP log retention = 0? In-Reply-To: <77e4079b0903141905k5f0951c2v640d5a003c18d549@mail.gmail.com> from "Neil" at Mar 14, 2009 07:05:46 PM Message-ID: <200903150317.n2F3HOmj026171@aurora.sol.net> > And there's another name for 'casing the joint', it is 'looking around'. > Looking around generally isn't a crime. Neither is casing a joint, for that > matter. And like I suggested with port scanning, whether someone was > 'looking around' or 'casing the joint' is really only determinable after > they've robbed the joint or not. Before that point, you're almost stabbing > in the dark. "Looking around" Rockefeller Center generally isn't a crime. "Looking around" where you're in my back yard and peeking in the windows is, at a minimum, trespass, and if our local cops notice you doing it, you can expect that you may find yourself ... severely inconvenienced. There is no "freedom to look around" on private property, despite what you appear to think. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From jimpop at gmail.com Sat Mar 14 22:53:35 2009 From: jimpop at gmail.com (Jim Popovitch) Date: Sat, 14 Mar 2009 23:53:35 -0400 Subject: Dynamic IP log retention = 0? In-Reply-To: <200903150317.n2F3HOmj026171@aurora.sol.net> References: <77e4079b0903141905k5f0951c2v640d5a003c18d549@mail.gmail.com> <200903150317.n2F3HOmj026171@aurora.sol.net> Message-ID: On Sat, Mar 14, 2009 at 23:17, Joe Greco wrote: > "Looking around" Rockefeller Center generally isn't a crime. > > "Looking around" where you're in my back yard and peeking in the windows > is, at a minimum, trespass, and if our local cops notice you doing it, you > can expect that you may find yourself ... severely inconvenienced. > > There is no "freedom to look around" on private property, despite what you > appear to think. Isn't Rockefeller Center private property? ;-) -Jim P. From devangnp at gmail.com Sat Mar 14 22:53:45 2009 From: devangnp at gmail.com (devang patel) Date: Sat, 14 Mar 2009 21:53:45 -0600 Subject: Sprint latency Message-ID: Hello, Any one is facing any latency in network passing trough sprint network, we have remote site and having trouble with accessing application from data centers. 7 200.122.150.22 0 msec 0 msec 4 msec *8 144.224.115.113 260 msec 276 msec 284 msec* * 9 144.232.2.244 276 msec 280 msec 292 msec* *10 144.232.2.204 292 msec 304 msec 300 msec* 11 144.223.162.42 120 msec 120 msec 120 msec thanks, Devang Patel From devangnp at gmail.com Sat Mar 14 23:24:44 2009 From: devangnp at gmail.com (devang patel) Date: Sat, 14 Mar 2009 22:24:44 -0600 Subject: Sprint latency In-Reply-To: References: Message-ID: I found this in my trace route: 1 if-13-0-0-818.mcore4.pdi-paloalto.as6453.net (66.198.97.18) 4 msec if-9-0-0.mcore4.pdi-paloalto.as6453.net (216.6.33.6) 0 msec if-13-0-0-818.mcore4.pdi-paloalto.as6453.net (66.198.97.18) 0 msec 2 sl-st20-pa-15-0.sprintlink.net (144.223.243.21) [AS 1239 ] 4 msec 0 msec 0 msec 3 sl-crs1-sj-0-14-0-1.sprintlink.net (144.232.8.109) [AS 1239 ] 8 msec 8 msec 8 msec 4 sl-crs1-stk-0-0-0-2.sprintlink.net (144.232.20.98) [AS 1239 ] 8 msec 8 msec 8 msec 5 sl-crs1-kc-0-6-3-0.sprintlink.net (144.232.8.170) [AS 1239 ] 56 msec 56 msec 56 msec 6 sl-bb21-nsh-10-0-0.sprintlink.net (144.232.18.113) [AS 1239 ] 76 msec 80 msec 80 msec 7 sl-crs1-atl-0-10-0-0.sprintlink.net (144.232.20.224) [AS 1239 ] 84 msec 84 msec 84 msec 8 sl-crs1-mia-0-8-0-2.sprintlink.net (144.232.18.221) [AS 1239 ] 92 msec 92 msec 92 msec 9 sl-crs1-mia-0-0-0-1.sprintlink.net (144.232.2.189) [AS 1239 ] 92 msec 92 msec 92 msec 10 sl-gw10-mia-11-0-0.sprintlink.net (144.232.28.65) [AS 1239 ] 92 msec 92 msec 96 msec 11 sl-racsa-211948-0.sprintlink.net (144.224.115.118) [AS 1239 ] 244 msec 248 msec 248 msec 12 200.122.191.182 [AS 3790] [MPLS: Label 49 Exp 0] 260 msec 256 msec 252 msec 13 200.122.191.142 [AS 3790] 248 msec 244 msec 240 msec thanks, Devang Patel On Sat, Mar 14, 2009 at 10:00 PM, Taylor Neill wrote: > Boston -> phoenix ~25% packet loss > > > On Sat, Mar 14, 2009 at 11:53 PM, devang patel wrote: > >> Hello, >> >> Any one is facing any latency in network passing trough sprint network, we >> have remote site and having trouble with accessing application from data >> centers. >> >> 7 200.122.150.22 0 msec 0 msec 4 msec >> >> *8 144.224.115.113 260 msec 276 msec 284 msec* >> >> * 9 144.232.2.244 276 msec 280 msec 292 msec* >> >> *10 144.232.2.204 292 msec 304 msec 300 msec* >> >> 11 144.223.162.42 120 msec 120 msec 120 msec >> thanks, >> Devang Patel >> > > > > -- > Taylor > 647.287.8632 > From mike.lyon at gmail.com Sat Mar 14 23:56:26 2009 From: mike.lyon at gmail.com (Mike Lyon) Date: Sat, 14 Mar 2009 21:56:26 -0700 Subject: Anyone using any Linux SSL proxies? Message-ID: <1b5c1c150903142156w1f159cdah383c2c8a9c306942@mail.gmail.com> Howdy, I am wondering what folks are recommending/using these days for Linux SSL proxies? I need to build a linux box that basically acts as an SSL offloader would (like a BigIP / Cisco ACE / Netscaler would do). Listen on port 443, decrypt the SSL and then forward the request onto the webserver on port 80. DSR is not required. Any suggestions? Offlist replies would probably be more appropriate. Thank You in advance. Cheers, Mike From Valdis.Kletnieks at vt.edu Sun Mar 15 00:17:32 2009 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sun, 15 Mar 2009 01:17:32 -0400 Subject: Anyone using any Linux SSL proxies? In-Reply-To: Your message of "Sat, 14 Mar 2009 21:56:26 PDT." <1b5c1c150903142156w1f159cdah383c2c8a9c306942@mail.gmail.com> References: <1b5c1c150903142156w1f159cdah383c2c8a9c306942@mail.gmail.com> Message-ID: <43748.1237094252@turing-police.cc.vt.edu> On Sat, 14 Mar 2009 21:56:26 PDT, Mike Lyon said: > Howdy, > > I am wondering what folks are recommending/using these days for Linux SSL > proxies? I need to build a linux box that basically acts as an SSL offloader > would (like a BigIP / Cisco ACE / Netscaler would do). Listen on port 443, > decrypt the SSL and then forward the request onto the webserver on port 80. How much traffic? That would be a major consideration.... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From charles at thewybles.com Sun Mar 15 00:20:22 2009 From: charles at thewybles.com (Charles Wyble) Date: Sat, 14 Mar 2009 22:20:22 -0700 Subject: Anyone using any Linux SSL proxies? In-Reply-To: <43748.1237094252@turing-police.cc.vt.edu> References: <1b5c1c150903142156w1f159cdah383c2c8a9c306942@mail.gmail.com> <43748.1237094252@turing-police.cc.vt.edu> Message-ID: <49BC9016.5060303@thewybles.com> Valdis.Kletnieks at vt.edu wrote: > On Sat, 14 Mar 2009 21:56:26 PDT, Mike Lyon said: >> Howdy, >> >> I am wondering what folks are recommending/using these days for Linux SSL >> proxies? I need to build a linux box that basically acts as an SSL offloader >> would (like a BigIP / Cisco ACE / Netscaler would do). Listen on port 443, >> decrypt the SSL and then forward the request onto the webserver on port 80. > > How much traffic? That would be a major consideration.... Check out http://www.apsis.ch/pound/ It would appear the magic search term on google is linux reverse ssl proxy .... I started searching for linux ssl proxy. That turned up a lot of stuff for wrapping plain text in encryption, not the other way around. :) And yes how much traffic is a major consideration. If a lot, then you would want to utilize an accelerator card supported by openssl. From charles at thewybles.com Sun Mar 15 00:20:54 2009 From: charles at thewybles.com (Charles Wyble) Date: Sat, 14 Mar 2009 22:20:54 -0700 Subject: Dynamic IP log retention = 0? In-Reply-To: References: <77e4079b0903141905k5f0951c2v640d5a003c18d549@mail.gmail.com> <200903150317.n2F3HOmj026171@aurora.sol.net> Message-ID: <49BC9036.2000600@thewybles.com> Can we please get this thread closed or something? Jim Popovitch wrote: > On Sat, Mar 14, 2009 at 23:17, Joe Greco wrote: >> "Looking around" Rockefeller Center generally isn't a crime. >> >> "Looking around" where you're in my back yard and peeking in the windows >> is, at a minimum, trespass, and if our local cops notice you doing it, you >> can expect that you may find yourself ... severely inconvenienced. >> >> There is no "freedom to look around" on private property, despite what you >> appear to think. > > Isn't Rockefeller Center private property? ;-) > > -Jim P. > From olof.kasselstrand at gmail.com Sun Mar 15 03:13:24 2009 From: olof.kasselstrand at gmail.com (Olof Kasselstrand) Date: Sun, 15 Mar 2009 09:13:24 +0100 Subject: Netflow on SUP720-3BXL In-Reply-To: References: <6069A203FD01884885C037F81DD75080CA0CA730@wsc-mail-01.intra.nwresd.k12.or.us> Message-ID: Have a look at http://www.cisco.com/en/US/products/hw/switches/ps700/products_tech_note09186a00801b42bf.shtml#prob1a // Olof On Sun, Mar 15, 2009 at 3:20 AM, Andy Bierlair wrote: > yes ip cef, this is enabled: > > ?IP fast switching is enabled > ?IP fast switching on the same interface is disabled > ?IP Flow switching is enabled > ?IP CEF switching is enabled > ?IP Flow switching turbo vector > ?IP Flow CEF switching turbo vector > > and so on... > > - > Andy > > On Sun, Mar 15, 2009 at 3:08 AM, Bill Blackford > wrote: >> >> just a shot in the dark. Do you have 'ip cef' in global config? >> >> -b >> ________________________________________ >> From: Andy Bierlair [globichen at gmail.com] >> Sent: Saturday, March 14, 2009 6:55 PM >> To: nanog at nanog.org >> Subject: Netflow on SUP720-3BXL >> >> I?m trying to run netflow on one of our Cisco core routers (SUP720-3BXL), >> but I think I am hitting some limitations because of this: >> >> >> >> %EARL_NETFLOW-SP-4-TCAM_THRLD: Netflow TCAM threshold exceeded, TCAM >> Utilization [99%] >> >> >> >> The setup of netflow looks like this: >> >> >> >> ?ip flow-cache entries 524288 >> >> ?mls aging fast time 5 threshold 32 >> >> ?mls aging long 300 >> >> ?mls aging normal 60 >> >> ?mls netflow usage notify 80 300 >> >> ?mls flow ip full >> >> ?no mls flow ipv6 >> >> ?mls nde sender version 5 >> >> ?no mls verify ip checksum >> >> ?no mls acl tcam share-global >> >> >> >> ?ip flow-export source Loopback0 >> >> ?ip flow-export version 5 origin-as >> >> ?ip flow-export destination >> >> >> >> Then I have this enabled on all border interfaces/vlans (peering / transit / >> other core routers) that are of interest for my stats: >> >> >> >> ?ip route-cache flow >> >> >> >> Some more details about the problem: >> >> >> >> #sh mls netflow table-contention detailed Earl in Module 5 Detailed Netflow >> CAM (TCAM and ICAM) Utilization >> ================================================ >> >> TCAM Utilization ? ? ? ? ? ? : ? 100% >> >> ICAM Utilization ? ? ? ? ? ? : ? 13% >> >> Netflow TCAM count ? ? ? ? ? : ? 262033 >> >> Netflow ICAM count ? ? ? ? ? : ? 17 >> >> Netflow Creation Failures ? ?: ? 4822220 >> >> Netflow CAM aliases ? ? ? ? ?: ? 1 >> >> >> >> >> >> #sh mls netflow table-contention aggregate Earl in Module 5 Aggregate >> Netflow CAM Contention Information >> ============================================= >> >> Netflow Creation Failures ? ?: ? 130003616 >> >> Netflow Hash Aliases ? ? ? ? : ? 4 >> >> >> >> >> >> I understand that the TCAM is full, but what can I do against it? This is a >> busy core router: >> >> >> >> Aggregated traffic: 7-8 GBIT/s >> >> Packets per Second: 1.0 - 1.2 Million >> >> >> >> I wouldn't mind analyzing only every 10th or 100th flow, which seems to be a >> common practice. >> >> >> >> Any good piece of advice is welcome. >> >> >> >> Thanks! >> >> >> >> - >> Andy > > From nick at foobar.org Sun Mar 15 04:23:29 2009 From: nick at foobar.org (Nick Hilliard) Date: Sun, 15 Mar 2009 09:23:29 +0000 Subject: Netflow on SUP720-3BXL In-Reply-To: References: Message-ID: <49BCC911.8040200@foobar.org> On 15/03/2009 01:55, Andy Bierlair wrote: > I?m trying to run netflow on one of our Cisco core routers (SUP720-3BXL), > but I think I am hitting some limitations because of this: Sounds about right for the amount of traffic you're pushing through the box. The SUP720 is a very poor netflow platform. There has been extensive discussion about this problem in cisco-nsp over the past several years, and this posting is probably more appropriate to that mailing list. But basically, there is too little netflow tcam on this card to deal with anything more than a couple of gigs of traffic. You can help things by setting the aging timer to be very aggressive, and by getting DFCs (although these are a rather expensive option). Sampling won't generally help, as the sampling is done in software, after the data has been collected. More info on: > http://www.google.com/search?q=sup720+netflow+%2Bsite:puck.nether.net/pipermail/cisco-nsp Nick From jlewis at lewis.org Sun Mar 15 09:00:43 2009 From: jlewis at lewis.org (Jon Lewis) Date: Sun, 15 Mar 2009 10:00:43 -0400 (EDT) Subject: Netflow on SUP720-3BXL In-Reply-To: References: Message-ID: On Sun, 15 Mar 2009, Andy Bierlair wrote: > Im trying to run netflow on one of our Cisco core routers (SUP720-3BXL), > but I think I am hitting some limitations because of this: > > %EARL_NETFLOW-SP-4-TCAM_THRLD: Netflow TCAM threshold exceeded, TCAM > Utilization [99%] > > TCAM Utilization : 100% > > Aggregated traffic: 7-8 GBIT/s > > Packets per Second: 1.0 - 1.2 Million AFAIK, at that traffic level, you will have to do sampled netflow. Try mls sampling time-based 64 [in global] mls netflow sampling [in interface] and see if that stops your TCAM utilization issues. You may have to sample even less flow data. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From tme at multicasttech.com Sun Mar 15 11:47:23 2009 From: tme at multicasttech.com (Marshall Eubanks) Date: Sun, 15 Mar 2009 12:47:23 -0400 Subject: Dynamic IP log retention = 0? In-Reply-To: <49BC9036.2000600@thewybles.com> References: <77e4079b0903141905k5f0951c2v640d5a003c18d549@mail.gmail.com> <200903150317.n2F3HOmj026171@aurora.sol.net> <49BC9036.2000600@thewybles.com> Message-ID: On Mar 15, 2009, at 1:20 AM, Charles Wyble wrote: > Can we please get this thread closed or something? > Maybe we should start the nanog-law mailing list. > Jim Popovitch wrote: >> On Sat, Mar 14, 2009 at 23:17, Joe Greco wrote: >>> "Looking around" Rockefeller Center generally isn't a crime. >>> >>> "Looking around" where you're in my back yard and peeking in the >>> windows >>> is, at a minimum, trespass, and if our local cops notice you doing >>> it, you >>> can expect that you may find yourself ... severely inconvenienced. >>> >>> There is no "freedom to look around" on private property, despite >>> what you >>> appear to think. >> Isn't Rockefeller Center private property? ;-) >> -Jim P. > From mksmith at adhost.com Sun Mar 15 13:04:38 2009 From: mksmith at adhost.com (Michael K. Smith) Date: Sun, 15 Mar 2009 11:04:38 -0700 Subject: Anyone using any Linux SSL proxies? In-Reply-To: <1b5c1c150903142156w1f159cdah383c2c8a9c306942@mail.gmail.com> Message-ID: Hello Mike: On 3/14/09 9:56 PM, "Mike Lyon" wrote: > Howdy, > > I am wondering what folks are recommending/using these days for Linux SSL > proxies? I need to build a linux box that basically acts as an SSL offloader > would (like a BigIP / Cisco ACE / Netscaler would do). Listen on port 443, > decrypt the SSL and then forward the request onto the webserver on port 80. > DSR is not required. > > Any suggestions? > > Offlist replies would probably be more appropriate. > > Thank You in advance. > > Cheers, > Mike We use Apache with mod_security and mod_proxy to do this, although the application is more as an application layer firewall than an SSL offloader. It works well for lower traffic applications; I haven't tested it under the loads that are advertised by the hardware vendors you mentioned. Regards, Mike From adrian at creative.net.au Sun Mar 15 13:11:29 2009 From: adrian at creative.net.au (Adrian Chadd) Date: Mon, 16 Mar 2009 03:11:29 +0900 Subject: Anyone using any Linux SSL proxies? In-Reply-To: References: <1b5c1c150903142156w1f159cdah383c2c8a9c306942@mail.gmail.com> Message-ID: <20090315181129.GE8753@skywalker.creative.net.au> On Sun, Mar 15, 2009, Michael K. Smith wrote: > We use Apache with mod_security and mod_proxy to do this, although the > application is more as an application layer firewall than an SSL offloader. > It works well for lower traffic applications; I haven't tested it under the > loads that are advertised by the hardware vendors you mentioned. Don't forget Squid and its various project forks. Adrian From william.allen.simpson at gmail.com Sun Mar 15 14:13:16 2009 From: william.allen.simpson at gmail.com (William Allen Simpson) Date: Sun, 15 Mar 2009 15:13:16 -0400 Subject: Dynamic IP log retention = 0? In-Reply-To: References: <77e4079b0903141905k5f0951c2v640d5a003c18d549@mail.gmail.com> <200903150317.n2F3HOmj026171@aurora.sol.net> <49BC9036.2000600@thewybles.com> Message-ID: <49BD534C.6020503@gmail.com> Marshall Eubanks wrote: > > Maybe we should start the nanog-law mailing list. > Maybe we should stick to the operational "Subject" at hand: log retention? Is there any disagreement that everybody SHOULD keep dynamic assignment logs for at least 36 hours as a Best Current Practice? Is there any evidence that Covad *keeps* logs, and responds to abuse notice? (I've seen no evidence that Covad has become such a bad actor that everybody should de-peer, but that might be incentive to keep better logs.) From stu at spacehopper.org Sun Mar 15 17:53:14 2009 From: stu at spacehopper.org (Stuart Henderson) Date: Sun, 15 Mar 2009 22:53:14 +0000 (UTC) Subject: Anyone using any Linux SSL proxies? References: <1b5c1c150903142156w1f159cdah383c2c8a9c306942@mail.gmail.com> Message-ID: On 2009-03-15, Mike Lyon wrote: > Howdy, > > I am wondering what folks are recommending/using these days for Linux SSL > proxies? I need to build a linux box that basically acts as an SSL offloader > would (like a BigIP / Cisco ACE / Netscaler would do). Listen on port 443, > decrypt the SSL and then forward the request onto the webserver on port 80. Pound works ok for this. OpenBSD's relayd also supports this, and if it's on a machine in the network path in front of the backend server/s, there's a transparent mode that maintain the source IP address from the original connection. > DSR is not required. Just as well, if you think about it... :-) From hannigan at gmail.com Sun Mar 15 23:07:52 2009 From: hannigan at gmail.com (Martin Hannigan) Date: Mon, 16 Mar 2009 00:07:52 -0400 Subject: Dynamic IP log retention = 0? In-Reply-To: References: <77e4079b0903141905k5f0951c2v640d5a003c18d549@mail.gmail.com> <200903150317.n2F3HOmj026171@aurora.sol.net> <49BC9036.2000600@thewybles.com> Message-ID: <2d106eb50903152107k744eaba7rf03c5fb1c29c5682@mail.gmail.com> A finely tuned killfile that remains mostly static once defined works wonders across all threads and fairly well. Best, Marty On 3/15/09, Marshall Eubanks wrote: > > On Mar 15, 2009, at 1:20 AM, Charles Wyble wrote: > >> Can we please get this thread closed or something? >> > > Maybe we should start the nanog-law mailing list. > >> Jim Popovitch wrote: >>> On Sat, Mar 14, 2009 at 23:17, Joe Greco wrote: >>>> "Looking around" Rockefeller Center generally isn't a crime. >>>> >>>> "Looking around" where you're in my back yard and peeking in the >>>> windows >>>> is, at a minimum, trespass, and if our local cops notice you doing >>>> it, you >>>> can expect that you may find yourself ... severely inconvenienced. >>>> >>>> There is no "freedom to look around" on private property, despite >>>> what you >>>> appear to think. >>> Isn't Rockefeller Center private property? ;-) >>> -Jim P. >> > > > From md at bts.sk Mon Mar 16 04:15:37 2009 From: md at bts.sk (Marian =?utf-8?B?xI51cmtvdmnEjQ==?=) Date: Mon, 16 Mar 2009 10:15:37 +0100 Subject: Shady areas of TCP window autotuning? Message-ID: <20090316091537.GA25118@bts.sk> Hi all, TCP window autotuning is part of several OSs today. However, the actual implementations behind this buzzword differ significantly and might impose negative side-effects to our networks - which I'd like to discuss here. There seem to be two basic approaches which differ in the main principle: #1: autotuning tries to set rx window to a sensible value for a given RTT #2: autotuning just ensures, that rx window is always bigger than congestion window of the sender, i.e. it never limits the flow While both approaches succeed to achieve high throughput on high-RTT paths, their behaviour on low-RTT paths is very different - mainly because the fact, that #2 suffers from "spiraling death" syndrome. I.e. when RTT increases due to queueing at the bottleneck point, autotuning reacts by increasing the advertised window, which again increases RTT... So the net effect of #2 is, that after very short TCP connection lifetime it might advertise extermely huge RX window compared to BDP of the path: RTT when idle Max advertised window #1 Max advertised window #2 ---------------------------------------------------------------------- < 1 msec 66560 byte 3 Mbyte 3 msec 66560 byte 3 Mbyte 12 msec 243200 byte 3 Mbyte 24 msec 482048 byte 3 Mbyte (The above data were taken from the same host connected by 100 Mpbs ethernet to the network while running two OSs with different approaches and transferring 1 GByte of data) It's obvious, that #2 has significant impact on the network. Since it advertises really huge window, it will fill up all buffers at the bottleneck point, it might increase latency to >100 msec levels even at LAN context and prevent classic TCP implementations with fixed window size from getting a fair share of bandwidth. This however doesn't seem to be of any concern for TCP maintainers of #2, who claim that receiver is not supposed to anyhow assist in congestion control. Instead, they advise everyone to use advanced queue management, RED or other congestion-control mechanisms at the sender and at every network device to avoid this behaviour. My personal opinion is that this looks more like passing the problem to someone else, not mentioning the fact, that absolutely trusting the sender to perform everything right and removing all safety-belts at the receiver could be very dangerous. What do people here think about this topic? Thanks & kind regards, M. -------------------------------------------------------------------------- ---- ---- ---- Marian ?urkovi? network manager ---- ---- ---- ---- Slovak Technical University Tel: +421 2 571 041 81 ---- ---- Computer Centre, N?m. Slobody 17 Fax: +421 2 524 94 351 ---- ---- 812 43 Bratislava, Slovak Republic E-mail/sip: md at bts.sk ---- ---- ---- -------------------------------------------------------------------------- From neil at domino.org Mon Mar 16 06:38:31 2009 From: neil at domino.org (Neil J. McRae) Date: Mon, 16 Mar 2009 11:38:31 -0000 (GMT) Subject: Netflow on SUP720-3BXL In-Reply-To: References: Message-ID: <61175.195.66.241.40.1237203511.squirrel@webmail2.domino.org> This is, believe it or not, a feature of the device you are using. On Sun, March 15, 2009 01:55, Andy Bierlair wrote: > I?m trying to run netflow on one of our Cisco core routers (SUP720 3BXL), > but I think I am hitting some limitations because of this: > %EARL_NETFLOW-SP-4-TCAM_THRLD: Netflow TCAM threshold exceeded, TCAM > Utilization [99%] -- Neil J. McRae -- Alive and Kicking. neil at DOMINO.ORG From dga at cs.cmu.edu Mon Mar 16 08:05:18 2009 From: dga at cs.cmu.edu (David Andersen) Date: Mon, 16 Mar 2009 09:05:18 -0400 Subject: Shady areas of TCP window autotuning? In-Reply-To: <20090316091537.GA25118@bts.sk> References: <20090316091537.GA25118@bts.sk> Message-ID: <1E3C22EB-6327-40EB-B45A-1592E95507A9@cs.cmu.edu> Briefly? They're correct - the rx advertised window has nothing to do with congestion control and everything to do with flow control. The problem you've described *is* a problem, but not because of its effects on congestion control -- the problem it causes is one we call a lack of agility: it takes longer for control signals to take effect if you're doing things like fast-forwarding a YouTube movie that's being delivered over TCP. If you want patches for Linux that properly decrease the window size, I can send you them out-of-band. But in general, TCP's proper behavior is to try to fill up the bottleneck buffer. This isn't a huge problem *in general*, but can be fairly annoying on, e.g., cable modems with oversized buffers, which are fairly common. But that's pretty fundamental with the way TCP is designed. Otherwise, you WILL sacrifice throughput at other times. -Dave On Mar 16, 2009, at 5:15 AM, Marian ?urkovi? wrote: > Hi all, > > TCP window autotuning is part of several OSs today. However, the > actual > implementations behind this buzzword differ significantly and might > impose > negative side-effects to our networks - which I'd like to discuss > here. > There seem to be two basic approaches which differ in the main > principle: > > #1: autotuning tries to set rx window to a sensible value for a > given RTT > #2: autotuning just ensures, that rx window is always bigger than > congestion window of the sender, i.e. it never limits the flow > > While both approaches succeed to achieve high throughput on high-RTT > paths, > their behaviour on low-RTT paths is very different - mainly because > the > fact, that #2 suffers from "spiraling death" syndrome. I.e. when RTT > increases due to queueing at the bottleneck point, autotuning reacts > by > increasing the advertised window, which again increases RTT... > So the net effect of #2 is, that after very short TCP connection > lifetime > it might advertise extermely huge RX window compared to BDP of the > path: > > RTT when idle Max advertised window #1 Max advertised window #2 > ---------------------------------------------------------------------- > < 1 msec 66560 byte 3 Mbyte > 3 msec 66560 byte 3 Mbyte > 12 msec 243200 byte 3 Mbyte > 24 msec 482048 byte 3 Mbyte > > (The above data were taken from the same host connected by 100 Mpbs > ethernet > to the network while running two OSs with different approaches and > transferring 1 GByte of data) > > It's obvious, that #2 has significant impact on the network. Since > it advertises really huge window, it will fill up all buffers at the > bottleneck point, it might increase latency to >100 msec levels even > at LAN context and prevent classic TCP implementations with fixed > window size from getting a fair share of bandwidth. > > This however doesn't seem to be of any concern for TCP maintainers > of #2, > who claim that receiver is not supposed to anyhow assist in congestion > control. Instead, they advise everyone to use advanced queue > management, > RED or other congestion-control mechanisms at the sender and at every > network device to avoid this behaviour. > > My personal opinion is that this looks more like passing the problem > to > someone else, not mentioning the fact, that absolutely trusting the > sender > to perform everything right and removing all safety-belts at the > receiver > could be very dangerous. > > What do people here think about this topic? > > > Thanks & kind regards, > > M. > > -------------------------------------------------------------------------- > ---- ---- > ---- Marian ?urkovi? network > manager ---- > ---- ---- > ---- Slovak Technical University Tel: +421 2 571 041 > 81 ---- > ---- Computer Centre, N?m. Slobody 17 Fax: +421 2 524 94 > 351 ---- > ---- 812 43 Bratislava, Slovak Republic E-mail/sip: > md at bts.sk ---- > ---- ---- > -------------------------------------------------------------------------- > > -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part URL: From bicknell at ufp.org Mon Mar 16 09:09:35 2009 From: bicknell at ufp.org (Leo Bicknell) Date: Mon, 16 Mar 2009 09:09:35 -0500 Subject: Shady areas of TCP window autotuning? In-Reply-To: <20090316091537.GA25118@bts.sk> References: <20090316091537.GA25118@bts.sk> Message-ID: <20090316140935.GA21789@ussenterprise.ufp.org> In a message written on Mon, Mar 16, 2009 at 10:15:37AM +0100, Marian ??urkovi?? wrote: > This however doesn't seem to be of any concern for TCP maintainers of #2, > who claim that receiver is not supposed to anyhow assist in congestion > control. Instead, they advise everyone to use advanced queue management, > RED or other congestion-control mechanisms at the sender and at every > network device to avoid this behaviour. I think the advice here is good, but it actually overlooks the larger problem. Many edge devices have queues that are way too large. What appears to happen is vendors don't auto-size queues. Something like a cable or DSL modem may be designed for a maximum speed of 10Mbps, and the vendor sizes the queue appropriately. The service provider then deploys the device at 2.5Mbps, which means roughly (as it can be more complex) the queue should be 1/4th the size. However the software doesn't auto-size the buffer to the link speed, and the operator doesn't adjust the buffer size in their config. The result is that if the vendor targeted 100ms of buffer you now have 400ms of buffer, and really bad lag. As network operators we have to get out of the mind set that "packet drops are bad". While that may be true in planning the backbone to have sufficient bandwidth, it's the exact opposite of true when managing congestion at the edge. Reducing the buffer to be ~50ms of bandwidth makes the users a lot happier, and allows TCP to work. TCP needs drops to manage to the right speed. My wish is for the vendors to step up. I would love to be able to configure my router/cable modem/dsl box with "queue-size 50ms" and have it compute, for the current link speed, 50ms of buffer. Sure, I can do that by hand and turn it into "queue 20 packets", but that is very manual and must be done for every different link speed (at least, at slower speeds). Operators don't adjust because it is too much work. If network operators could get the queue sizes fixed then it might be worrying about the behavior you describe; however I suspect 90% of the problem you describe would also go away. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From steve at ibctech.ca Mon Mar 16 11:14:08 2009 From: steve at ibctech.ca (Steve Bertrand) Date: Mon, 16 Mar 2009 12:14:08 -0400 Subject: Pro-actively publishing IRR data Message-ID: <49BE7AD0.30205@ibctech.ca> I'm still working on trying to get my primary provider to BGP peer with us, but in the meantime, I'd like to pro-actively publish our objects and route policy to the IRR. My primary provider is currently advertising our IPv4 routes for us from their AS. Are there any potential dangers of publishing our information before we use it that I may be overlooking? Steve From phil at mindfury.net Mon Mar 16 11:20:08 2009 From: phil at mindfury.net (phil at mindfury.net) Date: Mon, 16 Mar 2009 12:20:08 -0400 Subject: BGP nexthop-self vs. EIGRP redistribution Message-ID: <058c1d303220336a06f94c4e8b837847@mindfury.net> ...which is better? We recently ran into what looks like an implementation flaw in our network design. After moving two GbE connections with Savvis (same edge device on both ends) into EBGP-multihop, we were encountering problems with iBGP churn. The network design is two buildings in the same AS, each building has two core switches, which are in a full iBGP mesh, and acting as route-reflectors for four border switches. Two border switches are in one building, the other two in the other building. The layout is shown here: http://img17.imageshack.us/img17/6562/bgplayout.jpg EIGRP is being used as the IGP, now border4 is the the newest switch to have been installed, and in it's EIGRP configuration, static and connected routes were being redistributed. The other border switches, however were not redistributing. They were using next-hop-self in their iBGP announcements to the cores. We ended the iBGP churn issue by changing border4 to use next-hop-self to cores 3 and 4. My question is, which is the correct method of implementing this? Should we be redistributing static and connected routes on our borders into IGP, and not using next-hop-self? Or should we not redistribute and use next-hop-self? -- Philip L. From mtinka at globaltransit.net Mon Mar 16 11:28:42 2009 From: mtinka at globaltransit.net (Mark Tinka) Date: Tue, 17 Mar 2009 00:28:42 +0800 Subject: BGP nexthop-self vs. EIGRP redistribution In-Reply-To: <058c1d303220336a06f94c4e8b837847@mindfury.net> References: <058c1d303220336a06f94c4e8b837847@mindfury.net> Message-ID: <200903170028.47227.mtinka@globaltransit.net> On Tuesday 17 March 2009 12:20:08 am phil at mindfury.net wrote: > My question is, which is the correct method of > implementing this? Should we be redistributing static > and connected routes on our borders into IGP, and not > using next-hop-self? Or should we not redistribute and > use next-hop-self? I always recommend setting the NEXT_HOP attribute to 'self' for all iBGP sessions at the (peering) edge, and using your IGP to provide reachability to all Loopback addresses in the network. This scales quite well. And while IGP/BGP redistribution may be possible, we tend to avoid it as much as possible. Cheers, Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. URL: From petelists at templin.org Mon Mar 16 11:33:30 2009 From: petelists at templin.org (Pete Templin) Date: Mon, 16 Mar 2009 11:33:30 -0500 Subject: BGP nexthop-self vs. EIGRP redistribution In-Reply-To: <200903170028.47227.mtinka@globaltransit.net> References: <058c1d303220336a06f94c4e8b837847@mindfury.net> <200903170028.47227.mtinka@globaltransit.net> Message-ID: <49BE7F5A.8000201@templin.org> Mark Tinka wrote: > On Tuesday 17 March 2009 12:20:08 am phil at mindfury.net > wrote: > >> My question is, which is the correct method of >> implementing this? Should we be redistributing static >> and connected routes on our borders into IGP, and not >> using next-hop-self? Or should we not redistribute and >> use next-hop-self? > > I always recommend setting the NEXT_HOP attribute to 'self' > for all iBGP sessions at the (peering) edge, and using your > IGP to provide reachability to all Loopback addresses in the > network. This scales quite well. Any NANOGers running an MPLS network and choosing instead to redistribute the relevant connected routes from the peering edge into their network (either via IGP or BGP), thereby allowing label switching all the way to the PE (and therefore out a particular interface)? Next-hop-self seems to trigger penultimate hop popping, resulting in an IP lookup on the PE. pt From mtinka at globaltransit.net Mon Mar 16 12:01:08 2009 From: mtinka at globaltransit.net (Mark Tinka) Date: Tue, 17 Mar 2009 01:01:08 +0800 Subject: BGP nexthop-self vs. EIGRP redistribution In-Reply-To: <49BE7F5A.8000201@templin.org> References: <058c1d303220336a06f94c4e8b837847@mindfury.net> <200903170028.47227.mtinka@globaltransit.net> <49BE7F5A.8000201@templin.org> Message-ID: <200903170101.13079.mtinka@globaltransit.net> On Tuesday 17 March 2009 12:33:30 am Pete Templin wrote: > Any NANOGers running an MPLS network and choosing instead > to redistribute the relevant connected routes from the > peering edge into their network (either via IGP or BGP), > thereby allowing label switching all the way to the PE > (and therefore out a particular interface)? Next-hop-self > seems to trigger penultimate hop popping, resulting in an > IP lookup on the PE. Have you considered an explicit-null label value advertised by the LER? Is your goal preservation of QoS information? Cheers, Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. URL: From jbates at brightok.net Mon Mar 16 12:06:06 2009 From: jbates at brightok.net (Jack Bates) Date: Mon, 16 Mar 2009 12:06:06 -0500 Subject: BGP nexthop-self vs. EIGRP redistribution In-Reply-To: <058c1d303220336a06f94c4e8b837847@mindfury.net> References: <058c1d303220336a06f94c4e8b837847@mindfury.net> Message-ID: <49BE86FE.9080200@brightok.net> phil at mindfury.net wrote: > ...which is better? Neither (both) is better, depending on the scenario. This is especially true when mixing in MPLS and other features. > > My question is, which is the correct method of implementing this? Should > we be redistributing static and connected routes on our borders into IGP, > and not using next-hop-self? Or should we not redistribute and use > next-hop-self? next-hop-self seems to remain more stable overall. In some scenarios I believe it is even required (just as not using it is required in other scenarios). For your deployment, I'd say you are open to choose either, and next-hop-self would be the more stable of the two. The largest issue with NOT using next-hop-self that I have seen is the effect it has when that IGP route for the next hop disappears. BGP tends to be more graceful about removing routes via iBGP then handling routes locally when they are suddenly unreachable via IGP. Another benefit of next-hop-self is the fact that the IGP doesn't have to be overly enlarged when you have a large network (injecting hundreds or thousands of links into IGP). With OSPF/ISIS in a flat (single area) topology utilizing MPLS across the core, you would prefer stability in the link state database. Each edge network you place in IGP increases the chances of a database change, and in critical outages, they increase the number of changes that must be made. -Jack From robert at ufl.edu Mon Mar 16 12:12:52 2009 From: robert at ufl.edu (Robert D. Scott) Date: Mon, 16 Mar 2009 13:12:52 -0400 Subject: Seeking Connectivity in IRAQ Message-ID: <023b01c9a65a$70cd9b00$5268d100$@edu> A unit within the University has need to get reliable network connectivity to Iraq, more specifically Baghdad. I was wondering if any nanogers have any recommendations and/or contacts with providers in the area. Wired or Wireless. Off-list is fine. TIA Robert D. Scott Robert at ufl.edu Senior Network Engineer 352-273-0113 Phone CNS - Network Services 352-392-2061 CNS Phone Tree University of Florida 352-392-9440 FAX Florida Lambda Rail 352-294-3571 FLR NOC Gainesville, FL 32611 321-663-0421 Cell From nanog-post at rsuc.gweep.net Mon Mar 16 12:20:04 2009 From: nanog-post at rsuc.gweep.net (Joe Provo) Date: Mon, 16 Mar 2009 13:20:04 -0400 Subject: Pro-actively publishing IRR data In-Reply-To: <49BE7AD0.30205@ibctech.ca> References: <49BE7AD0.30205@ibctech.ca> Message-ID: <20090316172004.GA81232@gweep.net> On Mon, Mar 16, 2009 at 12:14:08PM -0400, Steve Bertrand wrote: [snip] > Are there any potential dangers of publishing our information before we > use it that I may be overlooking? In case you are worried about folks who filter, recall that the IRR uniqueeness is based upon the Prefix/length, originAS, and sourceDB tuple. There is nothing wrong with registering the origin as it is parallel to the origin-as-it-will be. If *you* do it, instead of your provider, you will not have to co-ordinate with anyone to yank the old one. Purposeful overlapping for the purposes of transition is one of the features. Cheers, Joe -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE From james+nanog at jribar.com Mon Mar 16 12:57:43 2009 From: james+nanog at jribar.com (James Ribar) Date: Mon, 16 Mar 2009 13:57:43 -0400 Subject: AT&T Wireless Data Contact Message-ID: Hi, Our half or dozen or so iPhone users are experiencing issues with accessing our corporate website and email services. I spoke to AT&T's support who after a few minutes told me it wasn't an ATT problem and forwarded me to Apple who said it was an issue with the website and were unable to help. I have verified that the website and email in question work just fine when connecting from other networks, ruling out in my book an issue on our end. As far as I can tell the issue seems to be with AT&T's DNS servers which are not resolving our domains properly. Accessing services by IP address works fine. In an effort to avoid being bounced back and forth on the phone all day between AT&T and Apple, is there anyone that can contact me off list who is able to help with this issue or point me in the right direction? Thanks, James From jeffrey.lyon at blacklotus.net Mon Mar 16 13:03:39 2009 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Mon, 16 Mar 2009 14:03:39 -0400 Subject: Seeking Connectivity in IRAQ In-Reply-To: <023b01c9a65a$70cd9b00$5268d100$@edu> References: <023b01c9a65a$70cd9b00$5268d100$@edu> Message-ID: <16720fe00903161103p7e462cb3p244e672ab2d05c45@mail.gmail.com> Robert, Check out Wataniya and Zain, the two are the regional wireless providers and in my experience, at least in Kuwait, they offer aircard service. The catch is that you have to have a local ID card (this was the rule in Kuwait, not sure of Iraq). You can get around this by buying the service from a shop who may agree to buy the card in his own name and resell to you. Best regards, Jeff On Mon, Mar 16, 2009 at 1:12 PM, Robert D. Scott wrote: > A unit within the University has need to get reliable network connectivity > to Iraq, more specifically Baghdad. I was wondering if any nanogers have any > recommendations and/or contacts with providers in the area. Wired or > Wireless. Off-list is fine. > > TIA > > Robert D. Scott ? ? ? ? ? ? ? ? Robert at ufl.edu > Senior Network Engineer ? ? ? ? 352-273-0113 Phone > CNS - Network Services ? ? ? ? ?352-392-2061 CNS Phone Tree > University of Florida ? ? ? ? ? 352-392-9440 FAX > Florida Lambda Rail ? ? ? ? ? ? 352-294-3571 FLR NOC > Gainesville, FL ?32611 ? ? ? ? ?321-663-0421 Cell > > > > > -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications of The IRC Company, Inc. Look for us at HostingCon 2009 in Washington, DC on August 10th - 12th at Booth #401. From steve at ibctech.ca Mon Mar 16 13:06:54 2009 From: steve at ibctech.ca (Steve Bertrand) Date: Mon, 16 Mar 2009 14:06:54 -0400 Subject: Pro-actively publishing IRR data In-Reply-To: <20090316172004.GA81232@gweep.net> References: <49BE7AD0.30205@ibctech.ca> <20090316172004.GA81232@gweep.net> Message-ID: <49BE953E.6060902@ibctech.ca> Joe Provo wrote: > On Mon, Mar 16, 2009 at 12:14:08PM -0400, Steve Bertrand wrote: > [snip] >> Are there any potential dangers of publishing our information before we >> use it that I may be overlooking? > > In case you are worried about folks who filter, recall that the IRR > uniqueeness is based upon the Prefix/length, originAS, and sourceDB > tuple. There is nothing wrong with registering the origin as it is > parallel to the origin-as-it-will be. If *you* do it, instead of > your provider, you will not have to co-ordinate with anyone to yank > the old one. Purposeful overlapping for the purposes of transition > is one of the features. Thanks Joe, This is exactly what I was looking to find out. Cheers, Steve From web at typo.org Mon Mar 16 13:37:31 2009 From: web at typo.org (Wayne E. Bouchard) Date: Mon, 16 Mar 2009 11:37:31 -0700 Subject: Shady areas of TCP window autotuning? In-Reply-To: <20090316140935.GA21789@ussenterprise.ufp.org> References: <20090316091537.GA25118@bts.sk> <20090316140935.GA21789@ussenterprise.ufp.org> Message-ID: <20090316183731.GA96569@typo.org> On Mon, Mar 16, 2009 at 09:09:35AM -0500, Leo Bicknell wrote: > The result is that if the vendor targeted 100ms of buffer you now > have 400ms of buffer, and really bad lag. Well, this is one of the reasons why I hate the fact that we're effectively stuck in a 1500 MTU world. My customers are vastly concerned with the quantity of data they can transmit per unit of latency. You may be more familiar with this termed as "through-put". Customers beat us operators and engineers up over it every day. TCP window tuning does help that if you can manage the side effects. A larger default layer 2 MTU (why we didn't change this when GE came out, I will never understand) would help even more by reducing the total number of frames necessary to transmit a packet across a give wire. > As network operators we have to get out of the mind set that "packet > drops are bad" Well, thats easier said than done and arguably not realistic. I got started in this business when 1-3% packet loss was normal and expected. As the network has grown, the expectation for 0% loss in all cases has grown with it. You have to remember that in the early days, the network itself was expected to guarentee data delivery. (ie X.25) Then the network improved and that burdon was cast on the host devices. Well, technology has continued to improve to the point where you litterally can expect 0% packet loss in relatively confined areas. (Say, Provider X in Los Angeles to user Y in San Jose.) But as you go further afield, such as from LAX to Israel, expectations have to change. Today, that mindset is not always there. As you illude to, this has also bred applications that are almost entirely intollerant of packet loss and extremely sensitive to jitter. (VOIP people, are you listening?) Real time gaming is a great example. Back in the days when 99% of us were on modems, any loss or varying delay between the client and the user made the difference between an enjoyable session and nothing but frustration and it was often hit and miss. A congested or dirty link in the middle of the path destroyed the user's experience. This is further compounded by the ever increasingly international participation in some of these services which means that 24x7 requirements render the customers and their users more and more sensitive to maintenance activities. (There can be areas where there is no "after hours" in which to do this stuff.) Add to this that as media companies expand their use of the network that customers have forced providers to write into their SLAs performance based metrics that, rather than simple uptime, now require often arbitrary guarentees of latency and data loss and you've got a real problem for operations and engineering. Techniques that can help improve network integrity are worth exploring. The difficulty is in proving these techniques under a wide array of circumstances, getting them properly adopted, and not having vendors or customers arbitrarily break them because of improper understanding, poor implementations, or bad configs (PMTUD, anyone?) Going forward, this sort of thing is going to be more and more important and harder and harder to get right. I'm actually glad to see this particular thread appear and will be quite interested in what people have to say on the matter. -Wayne --- Wayne Bouchard web at typo.org Network Dude http://www.typo.org/~web/ From lars.eggert at nokia.com Mon Mar 16 18:13:59 2009 From: lars.eggert at nokia.com (Lars Eggert) Date: Mon, 16 Mar 2009 16:13:59 -0700 Subject: Shady areas of TCP window autotuning? In-Reply-To: <20090316140935.GA21789@ussenterprise.ufp.org> References: <20090316091537.GA25118@bts.sk> <20090316140935.GA21789@ussenterprise.ufp.org> Message-ID: <68BD5B5E-457C-4F16-B990-CC36D4F6A071@nokia.com> Hi, On 2009-3-16, at 7:09, Leo Bicknell wrote: > My wish is for the vendors to step up. I would love to be able to > configure my router/cable modem/dsl box with "queue-size 50ms" and > have it compute, for the current link speed, 50ms of buffer. if the vendors got active and deployed better queueing schemes, that'd be great. In the meantime, we've also started some work that will allow bulk transfer applications to transmit in a way that is designed to minimize queue lengths: http://www.ietf.org/html.charters/ledbat-charter.html Lars -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2446 bytes Desc: not available URL: From frnkblk at iname.com Mon Mar 16 22:48:42 2009 From: frnkblk at iname.com (Frank Bulk - iName.com) Date: Mon, 16 Mar 2009 22:48:42 -0500 Subject: Shady areas of TCP window autotuning? In-Reply-To: <20090316140935.GA21789@ussenterprise.ufp.org> References: <20090316091537.GA25118@bts.sk> <20090316140935.GA21789@ussenterprise.ufp.org> Message-ID: It was my understanding that (most) cable modems are L2 devices -- how it is that they have a buffer, other than what the network processor needs to switch it? Frank -----Original Message----- From: Leo Bicknell [mailto:bicknell at ufp.org] Sent: Monday, March 16, 2009 9:10 AM To: nanog at nanog.org Subject: Re: Shady areas of TCP window autotuning? What appears to happen is vendors don't auto-size queues. Something like a cable or DSL modem may be designed for a maximum speed of 10Mbps, and the vendor sizes the queue appropriately. The service provider then deploys the device at 2.5Mbps, which means roughly (as it can be more complex) the queue should be 1/4th the size. However the software doesn't auto-size the buffer to the link speed, and the operator doesn't adjust the buffer size in their config. My wish is for the vendors to step up. I would love to be able to configure my router/cable modem/dsl box with "queue-size 50ms" and have it compute, for the current link speed, 50ms of buffer. Sure, I can do that by hand and turn it into "queue 20 packets", but that is very manual and must be done for every different link speed (at least, at slower speeds). Operators don't adjust because it is too much work. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ From ask at develooper.com Tue Mar 17 01:07:42 2009 From: ask at develooper.com (=?ISO-8859-1?Q?Ask_Bj=F8rn_Hansen?=) Date: Mon, 16 Mar 2009 23:07:42 -0700 Subject: Leap second tonight In-Reply-To: <20081231232816.C3D7045020@ptavv.es.net> References: <20081231232816.C3D7045020@ptavv.es.net> Message-ID: <483867A7-F5DD-462C-BBB0-DA254221AD5D@develooper.com> On Dec 31, 2008, at 15:28, Kevin Oberman wrote: > We use CDMA clocks and last leap second it took weeks for all of the > cell sites to adjust the last one. As a result, I have set all of our > clocks for manual leap second and set them to adjust tonight at > midnight > (UTC).I'll take a look in about 35 minutes and see how it worked. Chiming in a little late here ... Over at the NTP Pool we had about 9% of the servers not handle the leap second accurately; starting at midnight UTC. After an hour (so between 01:00 and 02:00) it was down to about 3%; a couple hours later down to about 1% of our servers (a few dozen)[1]. Most of those got in order within 24-48 hours. Interestingly the few who didn't get corrected within a few days were, tada: CDMA clocks. To stay vaguely NANOG on-topic: I believe at least some of our ~1700 NTP servers are routers; so I'm guessing they handled the leap second alright. Sounds like a "RISKS" lesson: Don't use side-effects of a tool for something critical. (If I understand it right then CDMA uses accurate time because it needs accurate frequency; not because it cares what time it is). Also: Who came up with having the leap second on New Year!? Clearly not someone with any operational experience. - ask [1] http://fortytwo.ch/mailman/pipermail/timekeepers/2009/004619.html and http://fortytwo.ch/mailman/pipermail/timekeepers/2009/004623.html -- http://develooper.com/ - http://askask.com/ From swmike at swm.pp.se Tue Mar 17 02:46:50 2009 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Tue, 17 Mar 2009 08:46:50 +0100 (CET) Subject: Shady areas of TCP window autotuning? In-Reply-To: <20090316140935.GA21789@ussenterprise.ufp.org> References: <20090316091537.GA25118@bts.sk> <20090316140935.GA21789@ussenterprise.ufp.org> Message-ID: On Mon, 16 Mar 2009, Leo Bicknell wrote: > What appears to happen is vendors don't auto-size queues. Something In my mind, the problem is that they tend to use FIFO, not that the queues are too large. This is most likely due to the enormous price competition in the market, where you might lose a DSL CPE deal because you charged $1 per unit more than the competition. What we need is ~100ms of buffer and fair-queue or equivalent, at both ends of the end-user link (unless it's 100 meg or more, where 5ms buffers and FIFO tail-drop seems to work just fine), because 1 meg uplink (ADSL) and 200ms buffer is just bad for the customer experience, and if they can't figure out how to do fair-queue properly, they might as well just to WRED 30 ms 50 ms (100% drop probability at 50ms) or even taildrop at 50ms. It's very rare today that an end user is helped by anything buffering their packet more than 50ms. I've done some testing with fairly fast links with big buffers (T3/OC3 and real routers) and doing FIFO and tuned TCP windows (single session) it's easy to get 100ms buffering, which is just pointless. So either smaller buffers and FIFO, or large buffers and some kind of intelligent queue handling. -- Mikael Abrahamsson email: swmike at swm.pp.se From fw at deneb.enyo.de Tue Mar 17 02:57:47 2009 From: fw at deneb.enyo.de (Florian Weimer) Date: Tue, 17 Mar 2009 08:57:47 +0100 Subject: Shady areas of TCP window autotuning? In-Reply-To: <20090316091537.GA25118@bts.sk> ("Marian =?utf-8?B?xI51cmtv?= =?utf-8?B?dmnEjSIncw==?= message of "Mon, 16 Mar 2009 10:15:37 +0100") References: <20090316091537.GA25118@bts.sk> Message-ID: <87bps07f9g.fsf@mid.deneb.enyo.de> * Marian ?urkovi?: > TCP window autotuning is part of several OSs today. However, the actual > implementations behind this buzzword differ significantly and might impose > negative side-effects to our networks - which I'd like to discuss here. > There seem to be two basic approaches which differ in the main principle: This has bene discussed previously on the netdev list: You may want to review the dicussion over there before replying on NANOG. From md at bts.sk Tue Mar 17 03:47:39 2009 From: md at bts.sk (Marian =?utf-8?B?xI51cmtvdmnEjQ==?=) Date: Tue, 17 Mar 2009 09:47:39 +0100 Subject: Shady areas of TCP window autotuning? In-Reply-To: <20090316140935.GA21789@ussenterprise.ufp.org> References: <20090316091537.GA25118@bts.sk> <20090316140935.GA21789@ussenterprise.ufp.org> Message-ID: <20090317084739.GB68010@bts.sk> On Mon, Mar 16, 2009 at 09:09:35AM -0500, Leo Bicknell wrote: > Many edge devices have queues that are way too large. > > What appears to happen is vendors don't auto-size queues. Something > like a cable or DSL modem may be designed for a maximum speed of > 10Mbps, and the vendor sizes the queue appropriately. The service > provider then deploys the device at 2.5Mbps, which means roughly > (as it can be more complex) the queue should be 1/4th the size. > However the software doesn't auto-size the buffer to the link speed, > and the operator doesn't adjust the buffer size in their config. > > The result is that if the vendor targeted 100ms of buffer you now > have 400ms of buffer, and really bad lag. This is a very good point. Let me add, that it happens also for every autosensing 10/100/1000Base-T ethernet port, which typically does not auto-reduce buffers when the actual negotiated speed is not 1 Gbps. > As network operators we have to get out of the mind set that "packet > drops are bad". While that may be true in planning the backbone > to have sufficient bandwidth, it's the exact opposite of true when > managing congestion at the edge. Reducing the buffer to be ~50ms > of bandwidth makes the users a lot happier, and allows TCP to work. > TCP needs drops to manage to the right speed. > > My wish is for the vendors to step up. I would love to be able to > configure my router/cable modem/dsl box with "queue-size 50ms" and > have it compute, for the current link speed, 50ms of buffer. Reducing buffers to 50 msec clearly avoids excessive queueing delays, but let's look at this from the wider perspective: 1) initially we had a system where hosts were using fixed 64 kB buffers This was unable to achieve good performance over high BDP paths 2) OS maintainers have fixed this by means of buffer autotuning, where the host buffer size is no longer the problem. 3) the above fix introduces unacceptable delays into networks and users are complaining, especially if autotuning approach #2 is used 4) network operators will fix the problem by reducing buffers to e.g. 50 msec So at the end of the day, we'll again have a system which is unable to achieve good performance over high BDP paths, since with reduced buffers we'll have an underbuffered bottleneck in the path which will prevent full link untilization if RTT>50 msec. Thus all the above exercises will end up in having almost the same situation as before (of course YMMV). Something is seriously wrong, isn't it? And yes, I opened this topic last week on Linux netdev mailinglist and tried hard to persuade those people that some less aggresive approach is probably necessary to achieve good balance between the requirements for fastest possible throughput and fairness in the network. But the maintainers simply didn't want to listen :-( M. From j at arpa.com Tue Mar 17 04:11:45 2009 From: j at arpa.com (jamie rishaw) Date: Tue, 17 Mar 2009 04:11:45 -0500 Subject: Leap second tonight In-Reply-To: <483867A7-F5DD-462C-BBB0-DA254221AD5D@develooper.com> References: <20081231232816.C3D7045020@ptavv.es.net> <483867A7-F5DD-462C-BBB0-DA254221AD5D@develooper.com> Message-ID: On Tue, Mar 17, 2009 at 1:07 AM, Ask Bj?rn Hansen wrote: > > On Dec 31, 2008, at 15:28, Kevin Oberman wrote: > > We use CDMA clocks and last leap second it took weeks for all of the >> cell sites to adjust the last one. As a result, I have set all of our >> clocks for manual leap second and set them to adjust tonight at midnight >> (UTC).I'll take a look in about 35 minutes and see how it worked. >> > > Chiming in a little late here ... > Oh, quiet. After all, what's 6.5 million seconds or so between friends? -j -- Jamie Rishaw // .com.arpa at j <- reverse it. ish. [Impressive C-level Title Here], arpa / arpa labs From rbf+nanog at panix.com Tue Mar 17 08:21:01 2009 From: rbf+nanog at panix.com (Brett Frankenberger) Date: Tue, 17 Mar 2009 08:21:01 -0500 Subject: Shady areas of TCP window autotuning? In-Reply-To: References: <20090316091537.GA25118@bts.sk> <20090316140935.GA21789@ussenterprise.ufp.org> Message-ID: <20090317132101.GA24436@panix.com> On Mon, Mar 16, 2009 at 10:48:42PM -0500, Frank Bulk - iName.com wrote: > It was my understanding that (most) cable modems are L2 devices -- how it is > that they have a buffer, other than what the network processor needs to > switch it? The Ethernet is typically faster than the upstream cable channel. So it needs some place to put the data that arrives from the Ethernet port until it gets sent upstream. This has nothing to do with layer 2 / layer 3. Any device connecting between media of different speeds (or connecting more than two ports -- creating the possibility of contention) would need some amount of buffering. -- Brett From oberman at es.net Tue Mar 17 10:06:51 2009 From: oberman at es.net (Kevin Oberman) Date: Tue, 17 Mar 2009 08:06:51 -0700 Subject: Leap second tonight In-Reply-To: Your message of "Mon, 16 Mar 2009 23:07:42 PDT." <483867A7-F5DD-462C-BBB0-DA254221AD5D@develooper.com> Message-ID: <20090317150651.83A731CC0B@ptavv.es.net> > From: =?ISO-8859-1?Q?Ask_Bj=F8rn_Hansen?= > Date: Mon, 16 Mar 2009 23:07:42 -0700 > > > On Dec 31, 2008, at 15:28, Kevin Oberman wrote: > > > We use CDMA clocks and last leap second it took weeks for all of the > > cell sites to adjust the last one. As a result, I have set all of our > > clocks for manual leap second and set them to adjust tonight at > > midnight > > (UTC).I'll take a look in about 35 minutes and see how it worked. > > Chiming in a little late here ... > > Over at the NTP Pool we had about 9% of the servers not handle the > leap second accurately; starting at midnight UTC. After an hour (so > between 01:00 and 02:00) it was down to about 3%; a couple hours later > down to about 1% of our servers (a few dozen)[1]. Most of those got > in order within 24-48 hours. Interestingly the few who didn't get > corrected within a few days were, tada: CDMA clocks. > > To stay vaguely NANOG on-topic: I believe at least some of our ~1700 > NTP servers are routers; so I'm guessing they handled the leap second > alright. Routers as ntp servers. Yuck! Routers route well, but they treat time as a low priority job and jitter on Cisco routers is simply terrible. Junipers do better, but are still a poor time server. > Sounds like a "RISKS" lesson: Don't use side-effects of a tool for > something critical. (If I understand it right then CDMA uses accurate > time because it needs accurate frequency; not because it cares what > time it is). As I understand it, they need both time and frequency to do cell hand-offs cleanly, but, as long as all towers in a carrier's market are showing the same time, it really does not matter if they do the leap second. Endrun Technologies, who make our clocks, ship them configured for manual leap seconds because so many cell operators are pretty casual about the leap second thing, but that means that the people using the clocks need to be aware that they need to be told when a leap second is coming and that, in turn, means the they must know a bit about leap seconds and must have read the manual. No surprise that a lot of CDMA clocks missed the leap second. From bicknell at ufp.org Tue Mar 17 10:39:13 2009 From: bicknell at ufp.org (Leo Bicknell) Date: Tue, 17 Mar 2009 10:39:13 -0500 Subject: Shady areas of TCP window autotuning? In-Reply-To: <20090317084739.GB68010@bts.sk> References: <20090316091537.GA25118@bts.sk> <20090316140935.GA21789@ussenterprise.ufp.org> <20090317084739.GB68010@bts.sk> <20090316091537.GA25118@bts.sk> <20090316140935.GA21789@ussenterprise.ufp.org> Message-ID: <20090317153913.GB75748@ussenterprise.ufp.org> In a message written on Tue, Mar 17, 2009 at 08:46:50AM +0100, Mikael Abrahamsson wrote: > In my mind, the problem is that they tend to use FIFO, not that the queues > are too large. We could quickly get lost in queuing science, but at a high level you are most correct that both are a problem. > What we need is ~100ms of buffer and fair-queue or equivalent, at both > ends of the end-user link (unless it's 100 meg or more, where 5ms buffers > and FIFO tail-drop seems to work just fine), because 1 meg uplink (ADSL) > and 200ms buffer is just bad for the customer experience, and if they > can't figure out how to do fair-queue properly, they might as well just to > WRED 30 ms 50 ms (100% drop probability at 50ms) or even taildrop at 50ms. > It's very rare today that an end user is helped by anything buffering > their packet more than 50ms. Some of this technology exists, just not where it can do a lot of good. Some fancier CPE devices know how to queue VOIP in a priority queue, and elevate some games. This works great when the cable modem or DSL modem are integrated, but when you buy a "router" and hook it to your provider supplied DSL or Cable Modem it's doing no good. I hate to suggest such a thing, but perhaps a protocol for a modem to communicate a comitted rate to a router would be a good thing... I'd also like to point out, where this technology exists today it's almost never used. How many 2600's and 3600's have you seen terminating T1's or DS-3's that don't have anything changed from the default FIFO queue? I am particularly fond of the DS-3 frame circuits with 100 PVC's, each with 40 packets of buffer. 4000 packets of buffer on a DS-3. No wonder performance is horrid. In a message written on Tue, Mar 17, 2009 at 09:47:39AM +0100, Marian ??urkovi?? wrote: > Reducing buffers to 50 msec clearly avoids excessive queueing delays, > but let's look at this from the wider perspective: > > 1) initially we had a system where hosts were using fixed 64 kB buffers > This was unable to achieve good performance over high BDP paths Note that the host buffer, which generally should be 2 * Bandwidth * Delay is, well, basically unrelated to the hop by hop network buffers. > 2) OS maintainers have fixed this by means of buffer autotuning, where > the host buffer size is no longer the problem. > > 3) the above fix introduces unacceptable delays into networks and users > are complaining, especially if autotuning approach #2 is used > > 4) network operators will fix the problem by reducing buffers to e.g. 50 msec > > So at the end of the day, we'll again have a system which is unable to > achieve good performance over high BDP paths, since with reduced buffers > we'll have an underbuffered bottleneck in the path which will prevent full > link untilization if RTT>50 msec. Thus all the above exercises will end up > in having almost the same situation as before (of course YMMV). This is an incorrect conclusion. The host buffer has to wait for an RTT for an ack to return, so it has to buffer a full RTT of data and then some. Hop by hop buffers only have to buffer until an output port on the same device is free. This is why a router with 20 10GE interfaces can have a 75 packet deep queue on each interface and work fine, the packet only sits there until a 10GE output interface is available (a few microseconds). The problems are related, as TCP goes faster there is an increased probability it will fill the buffer at any particular hop; but that means a link is full and TCP is hitting the maximum speed for that path anyway. Reducing the buffer size (to a point) /does not slow/ TCP, it reduces the feedback loop time. It provides less jitter to the user, which is good for VoIP and ssh and the like. However, if the hop-by-hop buffers are filling and there is lag and jitter, that's a sign the hop-by-hop buffers were always too large. 99.99% of devices ship with buffers that are too large. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From sbrilus at blueyonder.co.uk Tue Mar 17 10:47:56 2009 From: sbrilus at blueyonder.co.uk (Simon Brilus) Date: Tue, 17 Mar 2009 15:47:56 -0000 Subject: Redundant AS's Message-ID: Out of interest, is there a report that details the number of unused older AS's in the Internet and what is being done to recover them to recycle, as we approach the 53k mark and the 32 bit numbering scheme, it strikes me that we probably have a lot of stagnant AS's out there due to takeovers etc.. Any thoughts? Simon From tvest at eyeconomics.com Tue Mar 17 10:57:12 2009 From: tvest at eyeconomics.com (tvest at eyeconomics.com) Date: Tue, 17 Mar 2009 11:57:12 -0400 Subject: Redundant AS's In-Reply-To: References: Message-ID: <5021774B-6774-4DF9-8864-DC45A184BCAA@eyeconomics.com> On Mar 17, 2009, at 11:47 AM, Simon Brilus wrote: > Out of interest, is there a report that details the number of unused > older AS's in the Internet and what is being done to recover them to > recycle, as we approach the 53k mark and the 32 bit numbering > scheme, it strikes me that we probably have a lot of stagnant AS's > out there due to takeovers etc.. > > Any thoughts? > > Simon It's a bit dated now, but the RIPE report, ASN MIA, sounds like what you're looking for... www.apnic.net/meetings/21/docs/sigs/routing/routing-pres-uijterwaal-asn-mia.ppt TV From jmaimon at ttec.com Tue Mar 17 11:47:16 2009 From: jmaimon at ttec.com (Joe Maimon) Date: Tue, 17 Mar 2009 11:47:16 -0500 Subject: Shady areas of TCP window autotuning? In-Reply-To: <20090316140935.GA21789@ussenterprise.ufp.org> References: <20090316091537.GA25118@bts.sk> <20090316140935.GA21789@ussenterprise.ufp.org> Message-ID: <49BFD414.3030209@ttec.com> Leo Bicknell wrote: > As network operators we have to get out of the mind set that "packet > drops are bad". They are bad. > TCP needs drops to manage to the right speed. This is whats bad. TCP should be slightly more intelligent and start considering rtt jitter as its primary source of congestion information. Designing L2 network performance to optimize a l3 protocol is backwards. From schnizlein at isoc.org Tue Mar 17 11:54:29 2009 From: schnizlein at isoc.org (John Schnizlein) Date: Tue, 17 Mar 2009 12:54:29 -0400 Subject: Shady areas of TCP window autotuning? In-Reply-To: <49BFD414.3030209@ttec.com> References: <20090316091537.GA25118@bts.sk> <20090316140935.GA21789@ussenterprise.ufp.org> <49BFD414.3030209@ttec.com> Message-ID: <8C20B304-B1EE-448A-8458-E794C33A071D@isoc.org> Or use a transmission-layer protocol that optimizes delay end-to-end. http://tools.ietf.org/html/draft-shalunov-ledbat-congestion-00 On 2009Mar17, at 12:47 PM, Joe Maimon wrote: > > Leo Bicknell wrote: > >> TCP needs drops to manage to the right speed. > > This is whats bad. TCP should be slightly more intelligent and start > considering rtt jitter as its primary source of congestion > information. > > Designing L2 network performance to optimize a l3 protocol is > backwards. > From Valdis.Kletnieks at vt.edu Tue Mar 17 12:21:40 2009 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 17 Mar 2009 13:21:40 -0400 Subject: Leap second tonight In-Reply-To: Your message of "Tue, 17 Mar 2009 08:06:51 PDT." <20090317150651.83A731CC0B@ptavv.es.net> References: <20090317150651.83A731CC0B@ptavv.es.net> Message-ID: <24598.1237310500@turing-police.cc.vt.edu> On Tue, 17 Mar 2009 08:06:51 PDT, Kevin Oberman said: > Routers as ntp servers. Yuck! Routers route well, but they treat time as > a low priority job and jitter on Cisco routers is simply terrible. > Junipers do better, but are still a poor time server. They may suck for being a Stratum-1/2 server, but even the most jittery Cisco is still far and away good enough to serve up a ntpdate so that an end-user PC-class machine is in the right minute. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From beckman at angryox.com Tue Mar 17 12:30:15 2009 From: beckman at angryox.com (Peter Beckman) Date: Tue, 17 Mar 2009 13:30:15 -0400 Subject: Leap second tonight In-Reply-To: <24598.1237310500@turing-police.cc.vt.edu> References: <20090317150651.83A731CC0B@ptavv.es.net> <24598.1237310500@turing-police.cc.vt.edu> Message-ID: On Tue, 17 Mar 2009, Valdis.Kletnieks at vt.edu wrote: > They may suck for being a Stratum-1/2 server, but even the most jittery > Cisco is still far and away good enough to serve up a ntpdate so that an > end-user PC-class machine is in the right minute. As long as the end-user is made aware that the accuracy of said NTP clock is +/- 30.000 seconds (or whatever jitter might exist). Seems kind of ridiculous to use an NTP source that is, for many purposes, wildly inaccurate. For my purposes, wildly is more than +/- 0.1 seconds. Trying to troubleshoot a problem, network or server, where the timestamps on each server/router/device vary inconsistently, is like walking on broken fluorescent bulbs -- painful and dangerous to one's health. --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ --------------------------------------------------------------------------- From dot at dotat.at Tue Mar 17 14:10:11 2009 From: dot at dotat.at (Tony Finch) Date: Tue, 17 Mar 2009 19:10:11 +0000 Subject: Shady areas of TCP window autotuning? In-Reply-To: <49BFD414.3030209@ttec.com> References: <20090316091537.GA25118@bts.sk> <20090316140935.GA21789@ussenterprise.ufp.org> <49BFD414.3030209@ttec.com> Message-ID: On Tue, 17 Mar 2009, Joe Maimon wrote: > > > TCP needs drops to manage to the right speed. > > This is whats bad. TCP should be slightly more intelligent and start > considering rtt jitter as its primary source of congestion information. TCP Vegas did this but sadly it never became popular. (It doesn't compete well with Reno.) Tony. -- f.anthony.n.finch http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD. From deepak at ai.net Tue Mar 17 14:54:28 2009 From: deepak at ai.net (Deepak Jain) Date: Tue, 17 Mar 2009 15:54:28 -0400 Subject: Leap second tonight In-Reply-To: References: <20090317150651.83A731CC0B@ptavv.es.net> <24598.1237310500@turing-police.cc.vt.edu> Message-ID: > > As long as the end-user is made aware that the accuracy of said NTP > clock > is +/- 30.000 seconds (or whatever jitter might exist). Seems kind > of > ridiculous to use an NTP source that is, for many purposes, wildly > inaccurate. For my purposes, wildly is more than +/- 0.1 seconds. > Trying > to troubleshoot a problem, network or server, where the timestamps on > each > server/router/device vary inconsistently, is like walking on broken > fluorescent bulbs -- painful and dangerous to one's health. > Not being a time geek, since Cisco's were called out for being wild jitter-mongers... how much jitter are we talking about? Clock is synchronized, stratum 2, xxxxxxxxxxxxxxxxxxxxxxxx nominal freq is 250.0000 Hz, actual freq is 249.9989 Hz, precision is 2**18 reference time is CD6A7CD4.45A9BB00 (19:47:32.272 UTC Tue Mar 17 2009) clock offset is 2.0581 msec, root delay is 29.62 msec root dispersion is 6.81 msec, peer dispersion is 3.30 msec Are we talking about +/- 30 seconds, or a problem bounded by +/- 30 msec? Deepak Jain AiNET From simon at darkmere.gen.nz Tue Mar 17 15:10:01 2009 From: simon at darkmere.gen.nz (NANOG Mail List Committee) Date: Wed, 18 Mar 2009 09:10:01 +1300 Subject: ADMIN: List FAQ/Monthly Post. Message-ID: This 100-line document contains 62% of what you need to know to avoid annoying 10,000 people in your email to the NANOG list. It also contains pointers to another 23%. Please take 5 minutes to read it before you post [again]. General Information =================== About NANOG: http://www.nanog.org/about/ NANOG News: http://www.nanog.org/ NANOG lists and AUP: http://www.nanog.org/mailinglist/ NANOG List FAQ: http://www.nanog.org/mailinglist/listfaqs/ To Subscribe or Unsubscribe from the list: http://mailman.nanog.org/mailman/listinfo/nanog To contact the list's admins: admins at nanog.org Posting Policy ============== The NANOG list has over 10,000 subscribers so it is very easy for a thread to have scores of posts while being off-topic and only of interest to only a small proportion of subscribers. Please consider before each post if your email will be of interest to the majority of members or might alternatively be emailed directly the people of interest or posted to another forum. Please read the FAQ and AUP policy before posting for more details. Especially the following are discouraged: * Is a certain site down? Other Outages not affecting half the Internet. Please use http://downforeveryoneorjustme.com/ or a similar site. Please post to the Outages mailing list: http://wiki.outages.org * Spam Please use SPAM-L - http://www.claws-and-paws.com/spam-l * Contacting People * http://puck.nether.net/netops/ * Please try other methods of contacting sites before you post to NANOG. Saying something like "I tried calling 213-555-3333 but no answer" shows you _have_ tried alternative methods first. * Political Issues * Topics such as ICANN policy, Government Policy or Law changes that do not have short term Operational impact should be avoided. * Operation topics with more specific lists * DNS - http://lists.oarci.net/mailman/listinfo/dns-operations * Email - http://www.mailop.org/ * NANOG Mailing list policy Please use the nanog-futures list or contact admins at nanog.org Please also avoid ================= * Sending posts to the list relevant to only one or two people on this list, such as tests or traceroutes in response to another post for comparison to those originally posted. * Jokes, Puns, amusing observations, spelling corrections. Other NANOG related lists ========================= * NANOG-futures - for discussion of the evolution of NANOG, including organizational structure, policies and procedures, and agendas for NANOG meetings. Such topics aren't appropriate for the main NANOG mailing list. http://mailman.nanog.org/mailman/listinfo/nanog-futures * nanog-attendee - For discussion of venue-specific issues relevant to attendees of the current NANOG physical meeting. http://mailman.nanog.org/mailman/listinfo/nanog-attendee * nanog-announce - For announcements of NANOG meetings an other Important NANOG related announcements. Low traffic and all posts are also sent to main list. http://mailman.nanog.org/mailman/listinfo/nanog-announce Other Mailing Lists =================== Information about related lists: http://www.nanog.org/mailinglist/listfaqs/otherlists.php From leslie at craigslist.org Tue Mar 17 17:05:44 2009 From: leslie at craigslist.org (Leslie) Date: Tue, 17 Mar 2009 15:05:44 -0700 Subject: Myspace NOC contact me please Message-ID: <49C01EB8.20204@craigslist.org> I have already tried calling +1-310-215-1001 which is not in service as well as emailing peering at myspace.com and noc at myspace.com and checking peeringdb.com for any other contact info. Thanks Leslie Carr Craigslist also at 415/566-6394 x140 From oberman at es.net Tue Mar 17 17:24:49 2009 From: oberman at es.net (Kevin Oberman) Date: Tue, 17 Mar 2009 15:24:49 -0700 Subject: Leap second tonight In-Reply-To: Your message of "Tue, 17 Mar 2009 15:54:28 EDT." Message-ID: <20090317222449.A9D0F1CC0B@ptavv.es.net> > From: Deepak Jain > Date: Tue, 17 Mar 2009 15:54:28 -0400 > > > > > As long as the end-user is made aware that the accuracy of said NTP > > clock > > is +/- 30.000 seconds (or whatever jitter might exist). Seems kind > > of > > ridiculous to use an NTP source that is, for many purposes, wildly > > inaccurate. For my purposes, wildly is more than +/- 0.1 seconds. > > Trying > > to troubleshoot a problem, network or server, where the timestamps on > > each > > server/router/device vary inconsistently, is like walking on broken > > fluorescent bulbs -- painful and dangerous to one's health. > > > > Not being a time geek, since Cisco's were called out for being wild > jitter-mongers... how much jitter are we talking about? > > Clock is synchronized, stratum 2, xxxxxxxxxxxxxxxxxxxxxxxx > nominal freq is 250.0000 Hz, actual freq is 249.9989 Hz, precision is 2**18 > reference time is CD6A7CD4.45A9BB00 (19:47:32.272 UTC Tue Mar 17 2009) > clock offset is 2.0581 msec, root delay is 29.62 msec > root dispersion is 6.81 msec, peer dispersion is 3.30 msec > > Are we talking about +/- 30 seconds, or a problem bounded by +/- 30 msec? In my testing about 2 years ago (when we deployed dedicated NTP servers to our POPs), the jitter was highly variable. On a lightly loaded router we were seeing a reasonable 1 ms., but, if the router was fairly well loaded it increased to the 20-30 ms. range and we considered that unacceptable. Now days we use NTP for latency measurements and we really want better than 10 usec. and usually get better than 2 usec. on servers with attached reference clocks and about 150 usec. on systems syncing over the network. Since NTP and ICMP are treated about the same, try running a long term set or pings from a host to the router and see what you get. The PLL in ntpd will keep the local time much better than what you see, but it does not make for a very good time source. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman at es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From lars.eggert at nokia.com Tue Mar 17 18:46:28 2009 From: lars.eggert at nokia.com (Lars Eggert) Date: Tue, 17 Mar 2009 16:46:28 -0700 Subject: Shady areas of TCP window autotuning? In-Reply-To: References: <20090316091537.GA25118@bts.sk> <20090316140935.GA21789@ussenterprise.ufp.org> <49BFD414.3030209@ttec.com> Message-ID: On 2009-3-17, at 12:10, Tony Finch wrote: > On Tue, 17 Mar 2009, Joe Maimon wrote: >> >>> TCP needs drops to manage to the right speed. >> >> This is whats bad. TCP should be slightly more intelligent and start >> considering rtt jitter as its primary source of congestion >> information. > > TCP Vegas did this but sadly it never became popular. > (It doesn't compete well with Reno.) FWIW, Compound TCP does this (shipping with Vista, but disabled by default.) There are other delay-based or delay-sensitive TCP flavors, too. Lars -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2446 bytes Desc: not available URL: From eddy+public+spam at noc.everquick.net Tue Mar 17 19:13:48 2009 From: eddy+public+spam at noc.everquick.net (Edward B. DREGER) Date: Wed, 18 Mar 2009 00:13:48 +0000 (GMT) Subject: help with connectivity check? Message-ID: Please keep responses off-list to minimize clutter. Can anyone try ping/traceroute 204.10.190.1? DNS queries against same? Please let me know off-list if this FAILS, and what path you follow / how far you get. Many TIA, Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita LinkedIn: http://www.linkedin.com/in/0xebd ________________________________________________________________________ DO NOT send mail to the following addresses: davidc at brics.com -*- jfconmaapaq at intc.net -*- sam at everquick.net Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter. From eddy+public+spam at noc.everquick.net Tue Mar 17 19:38:55 2009 From: eddy+public+spam at noc.everquick.net (Edward B. DREGER) Date: Wed, 18 Mar 2009 00:38:55 +0000 (GMT) Subject: help with connectivity check? In-Reply-To: References: Message-ID: EBD> Date: Wed, 18 Mar 2009 00:13:48 +0000 (GMT) EBD> From: Edward B. DREGER Many thanks to all who have responded. I think/hope I have enough information now! Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita LinkedIn: http://www.linkedin.com/in/0xebd ________________________________________________________________________ DO NOT send mail to the following addresses: davidc at brics.com -*- jfconmaapaq at intc.net -*- sam at everquick.net Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter. From jlewis at packetnexus.com Tue Mar 17 19:49:37 2009 From: jlewis at packetnexus.com (Jason Lewis) Date: Tue, 17 Mar 2009 20:49:37 -0400 Subject: help with connectivity check? In-Reply-To: References: Message-ID: <49C04521.2020405@packetnexus.com> This brings up something I've been thinking about. Are there any free services that let you submit an IP and get traces back from multiple geographic locations? There are plenty of internet measurement projects, but none of them seem to let you do a live trace and get the data back in a parseable format. jas Edward B. DREGER wrote: > EBD> Date: Wed, 18 Mar 2009 00:13:48 +0000 (GMT) > EBD> From: Edward B. DREGER > > Many thanks to all who have responded. I think/hope I have enough > information now! > > From jeremy at evilrouters.net Tue Mar 17 20:00:09 2009 From: jeremy at evilrouters.net (Jeremy L. Gaddis) Date: Tue, 17 Mar 2009 21:00:09 -0400 Subject: help with connectivity check? In-Reply-To: <49C04521.2020405@packetnexus.com> References: <49C04521.2020405@packetnexus.com> Message-ID: <8623d07f0903171800y25ce3bbeh26ca2eaf601ed474@mail.gmail.com> On Tue, Mar 17, 2009 at 8:49 PM, Jason Lewis wrote: > This brings up something I've been thinking about. ?Are there any free > services that let you submit an IP and get traces back from multiple > geographic locations? > > There are plenty of internet measurement projects, but none of them seem > to let you do a live trace and get the data back in a parseable format. http://www.traceroute.org/ ? -- Jeremy L. Gaddis http://evilrouters.net/ From azher at hep.caltech.edu Tue Mar 17 20:29:52 2009 From: azher at hep.caltech.edu (Azher Mughal) Date: Tue, 17 Mar 2009 18:29:52 -0700 Subject: help with connectivity check? In-Reply-To: <49C04521.2020405@packetnexus.com> References: <49C04521.2020405@packetnexus.com> Message-ID: <49C04E90.3060505@hep.caltech.edu> https://mgmt.hep.caltech.edu/routeproxy Jason Lewis wrote: > This brings up something I've been thinking about. Are there any free > services that let you submit an IP and get traces back from multiple > geographic locations? > > There are plenty of internet measurement projects, but none of them seem > to let you do a live trace and get the data back in a parseable format. > > jas > > Edward B. DREGER wrote: >> EBD> Date: Wed, 18 Mar 2009 00:13:48 +0000 (GMT) >> EBD> From: Edward B. DREGER >> >> Many thanks to all who have responded. I think/hope I have enough >> information now! >> >> > From jmartinez at zero11.com Tue Mar 17 20:38:34 2009 From: jmartinez at zero11.com (John Martinez) Date: Tue, 17 Mar 2009 18:38:34 -0700 Subject: speakeasy connectivity In-Reply-To: <49C04E90.3060505@hep.caltech.edu> References: <49C04521.2020405@packetnexus.com> <49C04E90.3060505@hep.caltech.edu> Message-ID: <49C0509A.4030005@zero11.com> Anyone having issues with speakeasy dsl connectivity? From patrick at ianai.net Tue Mar 17 20:41:05 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Tue, 17 Mar 2009 21:41:05 -0400 Subject: speakeasy connectivity In-Reply-To: <49C0509A.4030005@zero11.com> References: <49C04521.2020405@packetnexus.com> <49C04E90.3060505@hep.caltech.edu> <49C0509A.4030005@zero11.com> Message-ID: On Mar 17, 2009, at 9:38 PM, John Martinez wrote: > Anyone having issues with speakeasy dsl connectivity? Supposedly they're having a national outage. -- TTFN, patrick From sliplever at gmail.com Tue Mar 17 20:43:52 2009 From: sliplever at gmail.com (Dan Snyder) Date: Tue, 17 Mar 2009 21:43:52 -0400 Subject: speakeasy connectivity In-Reply-To: <49C0509A.4030005@zero11.com> References: <49C04521.2020405@packetnexus.com> <49C04E90.3060505@hep.caltech.edu> <49C0509A.4030005@zero11.com> Message-ID: <76D1BFB7-0AA3-4306-BA29-FD3E02402565@gmail.com> I currently have partial connectivity to the Internet through speakeasy. Sent from my iPhone On Mar 17, 2009, at 9:38 PM, John Martinez wrote: > Anyone having issues with speakeasy dsl connectivity? > From info at spokompton.net Tue Mar 17 20:53:29 2009 From: info at spokompton.net (A MacLeod) Date: Tue, 17 Mar 2009 18:53:29 -0700 Subject: speakeasy connectivity In-Reply-To: <76D1BFB7-0AA3-4306-BA29-FD3E02402565@gmail.com> References: <49C04521.2020405@packetnexus.com> <49C04E90.3060505@hep.caltech.edu> <49C0509A.4030005@zero11.com> <76D1BFB7-0AA3-4306-BA29-FD3E02402565@gmail.com> Message-ID: <46E43A5E-FBFE-4D17-9ABF-54088DCD7950@spokompton.net> Our speakeasy t1 in palo alto was out for approx. 40 minutes. Service is back as of now. Andrew MacLeod Network Operations Manager Etheric Networks 877.541.3905 Sent from my iPhone On Mar 17, 2009, at 18:43, Dan Snyder wrote: > I currently have partial connectivity to the Internet through > speakeasy. > > Sent from my iPhone > > On Mar 17, 2009, at 9:38 PM, John Martinez > wrote: > >> Anyone having issues with speakeasy dsl connectivity? >> > From henk at ripe.net Wed Mar 18 02:18:59 2009 From: henk at ripe.net (Henk Uijterwaal) Date: Wed, 18 Mar 2009 08:18:59 +0100 Subject: Redundant AS's In-Reply-To: <5021774B-6774-4DF9-8864-DC45A184BCAA@eyeconomics.com> References: <5021774B-6774-4DF9-8864-DC45A184BCAA@eyeconomics.com> Message-ID: <49C0A063.8080607@ripe.net> tvest at eyeconomics.com wrote: > > On Mar 17, 2009, at 11:47 AM, Simon Brilus wrote: > >> Out of interest, is there a report that details the number of unused >> older AS's in the Internet and what is being done to recover them to >> recycle, as we approach the 53k mark and the 32 bit numbering scheme, >> it strikes me that we probably have a lot of stagnant AS's out there >> due to takeovers etc.. >> >> Any thoughts? >> >> Simon > > It's a bit dated now, but the RIPE report, ASN MIA, sounds like what > you're looking for... > www.apnic.net/meetings/21/docs/sigs/routing/routing-pres-uijterwaal-asn-mia.ppt When I look at this more recently, the conclusion still seems to be valid: we'll run out of 16 bit ASN's somewhere in 2011 to 2013. There are a lot of unused ASN's out there. Recovering them will postpone the problem by a few years but it won't solve it. The basic problem with recovery is how to decide if an ASN is really no longer used/needed. There is (still) no mechanism to do this. Henk -- ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.amsterdamned.org/~henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ Belgium: an unsolvable problem, discussed in endless meetings, with no hope for a solution, where everybody still lives happily. From md at bts.sk Wed Mar 18 03:04:42 2009 From: md at bts.sk (=?UTF-8?Q?Marian_=C4=8Eurkovi=C4=8D?=) Date: Wed, 18 Mar 2009 09:04:42 +0100 Subject: Shady areas of TCP window autotuning? In-Reply-To: <20090317153913.GB75748@ussenterprise.ufp.org> References: <20090316091537.GA25118@bts.sk> <20090316140935.GA21789@ussenterprise.ufp.org> <20090317084739.GB68010@bts.sk> <20090316091537.GA25118@bts.sk> <20090316140935.GA21789@ussenterprise.ufp.org> <20090317153913.GB75748@ussenterprise.ufp.org> Message-ID: <20090318072725.M9898@bts.sk> On Tue, 17 Mar 2009 10:39:13 -0500, Leo Bicknell wrote > > So at the end of the day, we'll again have a system which is unable to > > achieve good performance over high BDP paths, since with reduced buffers > > we'll have an underbuffered bottleneck in the path which will prevent full > > link untilization if RTT>50 msec. Thus all the above exercises will end up > > in having almost the same situation as before (of course YMMV). > > This is an incorrect conclusion. The host buffer has to wait for > an RTT for an ack to return, so it has to buffer a full RTT of data > and then some. Hop by hop buffers only have to buffer until an > output port on the same device is free. [snip] > However, if the hop-by-hop buffers are filling and there is lag and > jitter, that's a sign the hop-by-hop buffers were always too large. > 99.99% of devices ship with buffers that are too large. Vendors size the buffers according to principles outlined e.g. here: http://tiny-tera.stanford.edu/~nickm/papers/sigcomm2004.pdf It's fine to have smaller buffers in the high-speed core, but at the edge you still need to buffer for full RTT if you want to fully utilize the link with TCP Reno. Thus my conclusion holds - if we reduce buffers at the bottleneck point to 50 msec, flows with RTT>50 msec would suffer from reduced throughput. Anyway we probably have no other chance in situations when the only available queueing is FIFO. And if this gets implemented on larger scale, it could even have a positive side-effect - it might finally motivate OS maintainers to seriously consider deploying some delay-sensitive variant of TCP since Reno will no longer give them the best results. M. From hank at efes.iucc.ac.il Wed Mar 18 03:07:20 2009 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Wed, 18 Mar 2009 10:07:20 +0200 Subject: Redundant AS's In-Reply-To: <49C0A063.8080607@ripe.net> References: <5021774B-6774-4DF9-8864-DC45A184BCAA@eyeconomics.com> <5021774B-6774-4DF9-8864-DC45A184BCAA@eyeconomics.com> Message-ID: <5.1.0.14.2.20090318095944.04fdb070@efes.iucc.ac.il> At 08:18 AM 18-03-09 +0100, Henk Uijterwaal wrote: >>It's a bit dated now, but the RIPE report, ASN MIA, sounds like what >>you're looking for... >>www.apnic.net/meetings/21/docs/sigs/routing/routing-pres-uijterwaal-asn-mia.ppt >> > >When I look at this more recently, the conclusion still seems to be >valid: we'll run out of 16 bit ASN's somewhere in 2011 to 2013. There >are a lot of unused ASN's out there. Recovering them will postpone the >problem by a few years but it won't solve it. The basic problem with >recovery is how to decide if an ASN is really no longer used/needed. >There is (still) no mechanism to do this. > >Henk Why not go after low lying fruit first? If an ASN was assigned years ago and hasn't appeared in the RIB for the past year that ASN should be reclaimed. Send warning emails to the registered contacts as well as to the assigning LIR and after 3 months - just reclaim it. -Hank From Tero.Toikkanen at nebula.fi Wed Mar 18 03:11:22 2009 From: Tero.Toikkanen at nebula.fi (Tero Toikkanen) Date: Wed, 18 Mar 2009 10:11:22 +0200 Subject: Leap second tonight In-Reply-To: References: <20090317150651.83A731CC0B@ptavv.es.net> <24598.1237310500@turing-police.cc.vt.edu> Message-ID: <938AC6786A9CE64EA17214D592E906050A5D116784@exc01.office.nbl.fi> > Not being a time geek, since Cisco's were called out for being wild > jitter-mongers... how much jitter are we talking about? > > Clock is synchronized, stratum 2, xxxxxxxxxxxxxxxxxxxxxxxx > nominal freq is 250.0000 Hz, actual freq is 249.9989 Hz, precision is 2**18 > reference time is CD6A7CD4.45A9BB00 (19:47:32.272 UTC Tue Mar 17 2009) > clock offset is 2.0581 msec, root delay is 29.62 msec > root dispersion is 6.81 msec, peer dispersion is 3.30 msec > > Are we talking about +/- 30 seconds, or a problem bounded by +/- 30 msec? I've actually been gathering some statistics on this using Munin (http://munin.projects.linpro.no/) on my linux server. There's currently 10 ntp servers being monitored and one of them is a 7600-series Cisco, which is handling quite a bit of traffic (CPU load around 20%). Here are the Munin graphs for it http://dx.fi/alt/ntp/7600.png (times in Finnish time, UTC+2). In comparison, here are the same graphs for time1.mikes.fi (a stratum-2 clock provided by the Finnish Centre for metrology and accreditation) http://dx.fi/alt/ntp/time1.mikes.fi.png and for Netnods stratum-1 clock in Stockholm http://dx.fi/alt/ntp/ntp1.sth.netnod.se.png Best regards, -- Tero Toikkanen Nebula Oy From andy at nosignal.org Wed Mar 18 03:41:54 2009 From: andy at nosignal.org (Andy Davidson) Date: Wed, 18 Mar 2009 08:41:54 +0000 Subject: Anyone using any Linux SSL proxies? In-Reply-To: References: Message-ID: <76EA507B-F81A-42D3-840B-56BD65EB8911@nosignal.org> On 15 Mar 2009, at 18:04, Michael K. Smith wrote: > We use Apache with mod_security and mod_proxy to do this, although the > application is more as an application layer firewall than an SSL > offloader. > It works well for lower traffic applications; I haven't tested it > under the > loads that are advertised by the hardware vendors you mentioned. hi If you have multiple back end worker web services, then you should investigate the mod_proxy_balancer module, as it gives you an extended feature set that helps in this regard. Best wishes Andy Davidson From pekkas at netcore.fi Wed Mar 18 04:48:18 2009 From: pekkas at netcore.fi (Pekka Savola) Date: Wed, 18 Mar 2009 11:48:18 +0200 (EET) Subject: BGP nexthop-self vs. EIGRP redistribution In-Reply-To: <49BE86FE.9080200@brightok.net> References: <058c1d303220336a06f94c4e8b837847@mindfury.net> <49BE86FE.9080200@brightok.net> Message-ID: On Mon, 16 Mar 2009, Jack Bates wrote: >> My question is, which is the correct method of implementing this? Should >> we be redistributing static and connected routes on our borders into IGP, >> and not using next-hop-self? Or should we not redistribute and use >> next-hop-self? > > next-hop-self seems to remain more stable overall. In some scenarios I > believe it is even required (just as not using it is required in other > scenarios). For your deployment, I'd say you are open to choose either, and > next-hop-self would be the more stable of the two. The largest issue with NOT > using next-hop-self that I have seen is the effect it has when that IGP route > for the next hop disappears. BGP tends to be more graceful about removing > routes via iBGP then handling routes locally when they are suddenly > unreachable via IGP. On smaller networks (where IGP size is not an issue), I could see some benefit for redistributing connected to IGP and preserving the next-hop for those interfaces which have a backup route through some other interface. I.E: if the connected interface goes down, everyone knows immediately that the nexthop is unusable, and you can start using better working routes immediately, rather than waiting for the routes being BGP WITHDRAWn. Loopback and n-h-s seems to always make sense for those interfaces which are singlehomed to that router (no redundancy) -- otherwise you may want to consider which one is best. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From msaqib at gmail.com Wed Mar 18 06:20:29 2009 From: msaqib at gmail.com (Saqib Ilyas) Date: Wed, 18 Mar 2009 16:20:29 +0500 Subject: Network SLA In-Reply-To: <317578510903130734t5a89e6d2td104889a20aadd06@mail.gmail.com> References: <262b67200902190750m556cf72ve2ae25e4b64378e7@mail.gmail.com> <499DBE2A.6020907@gmail.com> <4fff97de0902230019tce5e53q2ddb501171436dc@mail.gmail.com> <262b67200903070312j55bded5dq26c978feb0b66441@mail.gmail.com> <997BC128AE961E4A8B880CD7442D94800A1EC529@NJCHLEXCMB01.cable.comcast.com> <317578510903130734t5a89e6d2td104889a20aadd06@mail.gmail.com> Message-ID: <262b67200903180420y3af34437r83176b03a931b71@mail.gmail.com> I'm back! Thanks again to all those who replied. I am wondering how a service provider might assess availability or reliability figures using active measurements. Granted that one could set up traffic generators between the two PoPs which will be connected to a customer's sites, and then after a day of test traffic, I can look for downtimes and restoration times. But a one day estimate is not a good estimate for what the service provider is promising, which is usually "maximum of 10 hours downtime in an year", is it not? Thanks and best regards On Fri, Mar 13, 2009 at 7:34 PM, Athanasios Douitsis wrote: > Anyone interested in setting up his own IP SLA probes by hand and then > collect the measurements into a database, can use a Perl tool we developed > at 2005: > > http://sourceforge.net/projects/saa-collector > > It's rather old (SAA got renamed into IPSLA in the meantime) and, in > retrospect, the code is a little rough around the edges, but it's > nevertheless usable. > > Regards, > Athanasios > > > > > On Wed, Mar 11, 2009 at 10:20 PM, Andreas, Rich < > Rich_Andreas at cable.comcast.com> wrote: > >> I have found that Cisco IPSLA is heavily used in the MSO/Service >> Provider Space. Juniper has equivalent functionality via RPM. >> >> Rich >> >> >> -----Original Message----- >> From: Saqib Ilyas [mailto:msaqib at gmail.com] >> Sent: Saturday, March 07, 2009 6:12 AM >> To: nanog at nanog.org >> Subject: Re: Network SLA >> >> I must thank everyone who has answered my queries. Just a couple more >> short questions. >> For instance, if one is using MRTG, and wants to check if we can meet >> a 1 Mbps end-to-end throughput between a couple of customer sites, I >> believe you would need to use some traffic generator tools, because >> MRTG merely imports counters from routers and plots them. Is that >> correct? >> We've heard of the BRIX active measurement tool in replies to my >> earlier email. Also, I've found Cisco IP SLA that also sends traffic >> into the service provider network and measures performance. How many >> people really use IP SLA feature? >> Thanks and best regards >> >> On Mon, Feb 23, 2009 at 1:19 PM, Zartash Uzmi wrote: >> > As I gather, there is a mix of answers, ranging from "building the >> resources >> > according to requirements and HOPE for the best" to "use of arguably >> > sophisticated tools and perhaps sharing the results with the legal >> > department". >> > >> > I would be particularly interested in hearing the service providers' >> > viewpoint on the following situation. >> > >> > Consider a service provider with MPLS deployed within its own network. >> > >> > (A) When the SP enters into a relation with the customer, does the SP >> > establish new MPLS paths based on customer demands (this is perhaps >> similar >> > to "building" based on requirements as pointed out by David)? If yes, >> > between what sites/POPs? I assume the answer may be different >> depending upon >> > a single-site customer or a customer with multiple sites. >> > >> > (B) For entering into the relationship for providing X units of >> bandwidth >> > (to another site of same customer or to the Tier-1 backbone), does the >> SP >> > use any wisdom (in addition to MRTG and the likes)? If so, what >> scientific >> > parameters are kept in mind? >> > >> > (C) How does the customer figure out that a promise for X units of >> bandwidth >> > is maintained by the SP? I believe customers may install some >> measuring >> > tools but is that really the case in practice? >> > >> > Thanks, >> > Zartash >> > >> > On Fri, Feb 20, 2009 at 1:16 AM, Stefan wrote: >> > >> >> Saqib Ilyas wrote: >> >> >> >>> Greetings >> >>> I am curious to know about any tools/techniques that a service >> provider >> >>> uses >> >>> to assess an SLA before signing it. That is to say, how does an >> >>> administrator know if he/she can meet what he is promising. Is it >> based on >> >>> experience? Are there commonly used tools for this? >> >>> Thanks and best regards >> >>> >> >>> >> >> Not necessarily as a direct answer (I am pretty sure there'll be >> others on >> >> this list giving details in the area of specific tools and >> standards), but I >> >> think this may be a question (especially considering your end result >> >> concern: *signing the SLA!) equally applicable to your legal >> department. In >> >> the environment we live, nowadays, the SLA could (should?!? ... >> >> unfortunately) be "refined" and (at the other end - i.e. receiving) >> >> "interpreted" by the lawyers, with possibly equal effects (mostly >> financial >> >> and as overall impact on the business) as the tools we (the technical >> >> people) would be using to measure latency, uptime, bandwidth, jitter, >> etc... >> >> >> >> Stefan >> >> >> >> >> > >> >> >> >> -- >> Muhammad Saqib Ilyas >> PhD Student, Computer Science and Engineering >> Lahore University of Management Sciences >> >> >> >> > -- Muhammad Saqib Ilyas PhD Student, Computer Science and Engineering Lahore University of Management Sciences From cmeidinger at sendmail.com Wed Mar 18 07:24:38 2009 From: cmeidinger at sendmail.com (Chris Meidinger) Date: Wed, 18 Mar 2009 13:24:38 +0100 Subject: Network SLA In-Reply-To: <262b67200903180420y3af34437r83176b03a931b71@mail.gmail.com> References: <262b67200902190750m556cf72ve2ae25e4b64378e7@mail.gmail.com> <499DBE2A.6020907@gmail.com> <4fff97de0902230019tce5e53q2ddb501171436dc@mail.gmail.com> <262b67200903070312j55bded5dq26c978feb0b66441@mail.gmail.com> <997BC128AE961E4A8B880CD7442D94800A1EC529@NJCHLEXCMB01.cable.comcast.com> <317578510903130734t5a89e6d2td104889a20aadd06@mail.gmail.com> <262b67200903180420y3af34437r83176b03a931b71@mail.gmail.com> Message-ID: <2DDA0F19-7A3F-480A-81A3-1E053B9F7F67@sendmail.com> On 18.03.2009, at 12:20, Saqib Ilyas wrote: > I'm back! Thanks again to all those who replied. I am wondering how a > service provider might assess availability or reliability figures > using > active measurements. Granted that one could set up traffic generators > between the two PoPs which will be connected to a customer's sites, > and then > after a day of test traffic, I can look for downtimes and > restoration times. This is an exact description of IPSLA. Of course you don't know whether a maximum bandwidth was in fact available, because you don't want to saturate the link. > But a one day estimate is not a good estimate for what the service > provider > is promising, which is usually "maximum of 10 hours downtime in an > year", is > it not? You need a year of measurement. > Thanks and best regards > > On Fri, Mar 13, 2009 at 7:34 PM, Athanasios Douitsis >wrote: > >> Anyone interested in setting up his own IP SLA probes by hand and >> then >> collect the measurements into a database, can use a Perl tool we >> developed >> at 2005: >> >> http://sourceforge.net/projects/saa-collector >> >> It's rather old (SAA got renamed into IPSLA in the meantime) and, in >> retrospect, the code is a little rough around the edges, but it's >> nevertheless usable. >> >> Regards, >> Athanasios >> >> >> >> >> On Wed, Mar 11, 2009 at 10:20 PM, Andreas, Rich < >> Rich_Andreas at cable.comcast.com> wrote: >> >>> I have found that Cisco IPSLA is heavily used in the MSO/Service >>> Provider Space. Juniper has equivalent functionality via RPM. >>> >>> Rich >>> >>> >>> -----Original Message----- >>> From: Saqib Ilyas [mailto:msaqib at gmail.com] >>> Sent: Saturday, March 07, 2009 6:12 AM >>> To: nanog at nanog.org >>> Subject: Re: Network SLA >>> >>> I must thank everyone who has answered my queries. Just a couple >>> more >>> short questions. >>> For instance, if one is using MRTG, and wants to check if we can >>> meet >>> a 1 Mbps end-to-end throughput between a couple of customer sites, I >>> believe you would need to use some traffic generator tools, because >>> MRTG merely imports counters from routers and plots them. Is that >>> correct? >>> We've heard of the BRIX active measurement tool in replies to my >>> earlier email. Also, I've found Cisco IP SLA that also sends traffic >>> into the service provider network and measures performance. How many >>> people really use IP SLA feature? >>> Thanks and best regards >>> >>> On Mon, Feb 23, 2009 at 1:19 PM, Zartash Uzmi >>> wrote: >>>> As I gather, there is a mix of answers, ranging from "building the >>> resources >>>> according to requirements and HOPE for the best" to "use of >>>> arguably >>>> sophisticated tools and perhaps sharing the results with the legal >>>> department". >>>> >>>> I would be particularly interested in hearing the service >>>> providers' >>>> viewpoint on the following situation. >>>> >>>> Consider a service provider with MPLS deployed within its own >>>> network. >>>> >>>> (A) When the SP enters into a relation with the customer, does >>>> the SP >>>> establish new MPLS paths based on customer demands (this is perhaps >>> similar >>>> to "building" based on requirements as pointed out by David)? If >>>> yes, >>>> between what sites/POPs? I assume the answer may be different >>> depending upon >>>> a single-site customer or a customer with multiple sites. >>>> >>>> (B) For entering into the relationship for providing X units of >>> bandwidth >>>> (to another site of same customer or to the Tier-1 backbone), >>>> does the >>> SP >>>> use any wisdom (in addition to MRTG and the likes)? If so, what >>> scientific >>>> parameters are kept in mind? >>>> >>>> (C) How does the customer figure out that a promise for X units of >>> bandwidth >>>> is maintained by the SP? I believe customers may install some >>> measuring >>>> tools but is that really the case in practice? >>>> >>>> Thanks, >>>> Zartash >>>> >>>> On Fri, Feb 20, 2009 at 1:16 AM, Stefan >>>> wrote: >>>> >>>>> Saqib Ilyas wrote: >>>>> >>>>>> Greetings >>>>>> I am curious to know about any tools/techniques that a service >>> provider >>>>>> uses >>>>>> to assess an SLA before signing it. That is to say, how does an >>>>>> administrator know if he/she can meet what he is promising. Is it >>> based on >>>>>> experience? Are there commonly used tools for this? >>>>>> Thanks and best regards >>>>>> >>>>>> >>>>> Not necessarily as a direct answer (I am pretty sure there'll be >>> others on >>>>> this list giving details in the area of specific tools and >>> standards), but I >>>>> think this may be a question (especially considering your end >>>>> result >>>>> concern: *signing the SLA!) equally applicable to your legal >>> department. In >>>>> the environment we live, nowadays, the SLA could (should?!? ... >>>>> unfortunately) be "refined" and (at the other end - i.e. >>>>> receiving) >>>>> "interpreted" by the lawyers, with possibly equal effects (mostly >>> financial >>>>> and as overall impact on the business) as the tools we (the >>>>> technical >>>>> people) would be using to measure latency, uptime, bandwidth, >>>>> jitter, >>> etc... >>>>> >>>>> Stefan >>>>> >>>>> >>>> >>> >>> >>> >>> -- >>> Muhammad Saqib Ilyas >>> PhD Student, Computer Science and Engineering >>> Lahore University of Management Sciences >>> >>> >>> >>> >> > > > -- > Muhammad Saqib Ilyas > PhD Student, Computer Science and Engineering > Lahore University of Management Sciences From Justin.Dixon at BBandT.com Wed Mar 18 08:11:53 2009 From: Justin.Dixon at BBandT.com (Dixon, Justin) Date: Wed, 18 Mar 2009 09:11:53 -0400 Subject: help with connectivity check? In-Reply-To: <49C04E90.3060505@hep.caltech.edu> References: <49C04521.2020405@packetnexus.com> <49C04E90.3060505@hep.caltech.edu> Message-ID: <91864382B2433640BA2A447041B3DBC309FD3AA1@wil-exmb01.bbtnet.com> http://centralops.net/co/ http://geektools.com/traceroute.php http://www.simplelogic.com/net_utils/Default.asp https://www.sprint.net/lg/ Just to name a few... Justin Dixon -----Original Message----- From: Azher Mughal [mailto:azher at hep.caltech.edu] Sent: Tuesday, March 17, 2009 21:30 To: Jason Lewis Cc: nanog at merit.edu Subject: Re: help with connectivity check? https://mgmt.hep.caltech.edu/routeproxy Jason Lewis wrote: > This brings up something I've been thinking about. Are there any free > services that let you submit an IP and get traces back from multiple > geographic locations? > > There are plenty of internet measurement projects, but none of them seem > to let you do a live trace and get the data back in a parseable format. > > jas > > Edward B. DREGER wrote: >> EBD> Date: Wed, 18 Mar 2009 00:13:48 +0000 (GMT) >> EBD> From: Edward B. DREGER >> >> Many thanks to all who have responded. I think/hope I have enough >> information now! >> >> > From bicknell at ufp.org Wed Mar 18 08:25:35 2009 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 18 Mar 2009 08:25:35 -0500 Subject: Shady areas of TCP window autotuning? In-Reply-To: <20090318072725.M9898@bts.sk> References: <20090316091537.GA25118@bts.sk> <20090316140935.GA21789@ussenterprise.ufp.org> <20090317084739.GB68010@bts.sk> <20090316091537.GA25118@bts.sk> <20090316140935.GA21789@ussenterprise.ufp.org> <20090317153913.GB75748@ussenterprise.ufp.org> <20090318072725.M9898@bts.sk> Message-ID: <20090318132535.GB22329@ussenterprise.ufp.org> In a message written on Wed, Mar 18, 2009 at 09:04:42AM +0100, Marian ??urkovi?? wrote: > It's fine to have smaller buffers in the high-speed core, but at the edge you > still need to buffer for full RTT if you want to fully utilize the link with > TCP Reno. Thus my conclusion holds - if we reduce buffers at the bottleneck > point to 50 msec, flows with RTT>50 msec would suffer from reduced throughput. Ah, I understand your point now. There is a balance to be had at the edge; the tuning to support a single TCP stream at full bandwidth and the tuning to reduce latency and jitter are on some level incompatable; so one must strike a balance between the two. Of course... > Anyway we probably have no other chance in situations when the only available > queueing is FIFO. And if this gets implemented on larger scale, it could even > have a positive side-effect - it might finally motivate OS maintainers to > seriously consider deploying some delay-sensitive variant of TCP since Reno > will no longer give them the best results. Many of the problems can be mitigated with well known queueing strategies. WRED, priority queues, and other options have been around long enough I refuse to believe they add significant cost. Rather, I think the problem is of awareness, far too few network engineers seem to really understand what effect the queuing options have on traffic. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From randy at psg.com Wed Mar 18 08:44:50 2009 From: randy at psg.com (Randy Bush) Date: Wed, 18 Mar 2009 06:44:50 -0700 Subject: Redundant AS's In-Reply-To: <49C0A063.8080607@ripe.net> References: <5021774B-6774-4DF9-8864-DC45A184BCAA@eyeconomics.com> <49C0A063.8080607@ripe.net> Message-ID: > When I look at this more recently, the conclusion still seems to be > valid: we'll run out of 16 bit ASN's somewhere in 2011 to 2013. There > are a lot of unused ASN's out there. Recovering them will postpone the > problem by a few years but it won't solve it. The basic problem with > recovery is how to decide if an ASN is really no longer used/needed. > There is (still) no mechanism to do this. sounds a lot like IPv4 space, eh? > Why not go after low lying fruit first? If an ASN was assigned years > ago and hasn't appeared in the RIB for the past year that ASN should > be reclaimed. Send warning emails to the registered contacts as well > as to the assigning LIR and after 3 months - just reclaim it. because property is unused publicly does not affect the rights of its owner(s). otherwise old car collector wannabes could have a heyday. perhaps the world would be a better place if we spent less energy on net vigilanteism and more on moving to IPv6 and 4-byte AS numbers. randy From ksriram at nist.gov Wed Mar 18 10:16:17 2009 From: ksriram at nist.gov (K. Sriram) Date: Wed, 18 Mar 2009 11:16:17 -0400 Subject: Origin ASN seen vs Origin ASN in Whois Records Report? Message-ID: <49C11041.9090908@nist.gov> Heather: This prior question from you (November 2008) was recently brought to our attention. Sorry about this delayed response, but we thought it would still be worthwhile to share pointers to some work that we are doing at NIST which relates closely to your question. Earlier Bill Woodcock provided you with a link where the actual discrepancies are listed. Our work at NIST focuses on the statistics of such anomalies, with the intention of: (A) generating score cards for accuracy/consistency of various registries, and (B) to glean the "good" data from what is available so that BGP robustness algorithms that rely on the data can work more effectively. We have done an analysis of registry information (RIRs, IRRs, RADB) and compared it with that from trace data (RIBs, update history) from RIPE-RIS and routeviews. We generate a variety of statistics on a per RIR basis (ARIN, RIPE, etc.) regarding whether announced {prefix, origin AS} pairs in updates correspond with those in the registries. We also report on whether the registered objects (NetHandle and AShandle in SWIP format and inetnum, aut-num, and route in RPSL format) appear self-consistent or not. We also looked at the NetHandles in ARIN that contain origin AS information, and have performed comparisons of those with what was historically seen in BGP updates for prefixes belonging to the ARIN region. A variety of results and discussion related to all this are presented in this set of slides: http://www.antd.nist.gov/bgp_security/publications/ARIN_NetHandle_OriginAS_Analysis.pdf You may also look into a presentation we made in January at NANOG-45. There the focus was on BGP robustness algorithms that make combined use of filtered "good" data from registries as well as long-term trace data. http://www.nanog.org/meetings/nanog45/abstracts.php?pt=MTE5NSZuYW5vZzQ1&nm=nanog45 Here is a link for a detailed published paper related our NANOG-45 presentation: http://www.antd.nist.gov/pubs/NIST_BGP_Robustness.pdf (This paper was published in the Proceedings of DHS S&T CATCH 2009 conference.) Please let me know if you have any specific questions concerning the above. We are very interested in receiving feedback on how this work can be made more useful from the perspective of what ISP needs are. Sriram K. Sriram +1 301 975 3973 http://www.antd.nist.gov/~ksriram/ ----------------------------------------------------- >From nanog-bounces at nanog.org Wed Nov 19 19:14:58 2008 Date: Wed, 19 Nov 2008 19:16:43 -0500 From: Heather Schiller Subject: Origin ASN seen vs Origin ASN in Whois Records Report? To: gih at apnic.net, nanog , info at BGPmon.net I don't know if a report like this already exists, but I haven't been able to find one. Can someone (CIDR Report? BGPMon? PCH?) offer a report that shows the discrepencies in Origin ASN according to the whois records, and routes in the [global/public] routing table? Publishing it on some regular interval would be even better. ARIN makes available a list of prefixes with OriginAS. I don't know if other RIR's do. ftp://ftp.arin.net/pub/originAS/ To be clear. I want a list of the prefixes where the actual origin ASN seen does not match the one in the whois record. Inconsistent Origin is fair game here. As a transit provider I'm interested in seeing what prefixes I am transiting for my customers that have this discrepancy, so something that shows the full path as part of the results would be most helpful. Thanks, --Heather From heather.schiller at verizonbusiness.com Wed Mar 18 11:22:59 2009 From: heather.schiller at verizonbusiness.com (Heather Schiller) Date: Wed, 18 Mar 2009 12:22:59 -0400 Subject: Redundant AS's In-Reply-To: <5.1.0.14.2.20090318095944.04fdb070@efes.iucc.ac.il> References: <5021774B-6774-4DF9-8864-DC45A184BCAA@eyeconomics.com> <5021774B-6774-4DF9-8864-DC45A184BCAA@eyeconomics.com> <5.1.0.14.2.20090318095944.04fdb070@efes.iucc.ac.il> Message-ID: <49C11FE3.4040601@verizonbusiness.com> Hank Nussbacher wrote: > At 08:18 AM 18-03-09 +0100, Henk Uijterwaal wrote: > >>> It's a bit dated now, but the RIPE report, ASN MIA, sounds like what >>> you're looking for... >>> www.apnic.net/meetings/21/docs/sigs/routing/routing-pres-uijterwaal-asn-mia.ppt >>> >> >> When I look at this more recently, the conclusion still seems to be >> valid: we'll run out of 16 bit ASN's somewhere in 2011 to 2013. There >> are a lot of unused ASN's out there. Recovering them will postpone the >> problem by a few years but it won't solve it. The basic problem with >> recovery is how to decide if an ASN is really no longer used/needed. >> There is (still) no mechanism to do this. >> >> Henk > > Why not go after low lying fruit first? If an ASN was assigned years > ago and hasn't appeared in the RIB for the past year that ASN should be > reclaimed. Send warning emails to the registered contacts as well as to > the assigning LIR and after 3 months - just reclaim it. > > -Hank > > > Your making an assumption that globally unique ASN's must show up in the public internet routing table. The only requirement, at least in the ARIN region, for obtaining a globally unique ASN is a unique routing policy or multihoming - therefor your method could lead to a lot of false positives. I won't even get into issues around bad contact data in whois. However, if enough folks believe this a worthwhile effort, at least in the ARIN region, you will have to ask ARIN to pursue this either through the ARIN policy development process or the ARIN consultation and suggestion process...my guess would be suggestion process. Suggestion submission: https://www.arin.net/app/suggestion/ Policy Proposal process: https://www.arin.net/policy/pdp_appendix_b.html for reference... requirements for obtaining an ASN in the ARIN region: Multi-homed NRPM 5 * provide the exterior gateway protocol to be used * provide the IP addresses currently in use on your network * provide the AS number and name of each of your upstream providers/peers * provide verification (reassigned address block, a copy of your signed contract) your organization has contractually agreed to service with at least two of the upstream providers/peers listed on your request * if requesting an additional AS number, provide documentation detailing how the network for the requested ASN is autonomous from all existing ASes in your network Unique Routing Policy NRPM 5 * demonstrate the AS's routing policy will differ from the routing policies of its border peers * if requesting an additional AS number, provide documentation detailing how the network for the requested ASN is autonomous from all existing ASes in your network --Heather -- ==================================================== Heather Schiller Verizon Business Customer Security 1.800.900.0241 IP Address Management help4u at verizonbusiness.com ===================================================== From David.Norrie at thus.net Wed Mar 18 11:47:46 2009 From: David.Norrie at thus.net (Norrie, David) Date: Wed, 18 Mar 2009 16:47:46 -0000 Subject: SUP720 vs. SUP32 In-Reply-To: <20090311193412.GC12934@skywalker.creative.net.au> References: <6069A203FD01884885C037F81DD75080CA064DA9@wsc-mail-01.intra.nwresd.k12.or.us><6069A203FD01884885C037F81DD75080CA064DD9@wsc-mail-01.intra.nwresd.k12.or.us> <20090311193412.GC12934@skywalker.creative.net.au> Message-ID: Hi, I have been searching cisco-nsp archive but not been able to find the article discussed below. I would appreciate it if someone does find the article if they can provide a copy/link to this : > Check the cisco-nsp archive, specifically from Rodney; he has talked about what the > CPU load versus throughput implications are on the G1 and G2. It might surprise you a > little. Thanks, David From adrian at creative.net.au Wed Mar 18 11:57:25 2009 From: adrian at creative.net.au (Adrian Chadd) Date: Thu, 19 Mar 2009 01:57:25 +0900 Subject: SUP720 vs. SUP32 In-Reply-To: References: <20090311193412.GC12934@skywalker.creative.net.au> Message-ID: <20090318165725.GC19630@skywalker.creative.net.au> On Wed, Mar 18, 2009, Norrie, David wrote: > article discussed below. I would appreciate it if someone does find the > article if they can provide a copy/link to this : http://markmail.org/message/hzwfh27bgtitadpq (First hit from googling "c-nsp rodney dunn NPE-G2 CPU") Make sure you read all the posts in the thread, the figures Rodney gives need some further explanation. Adrian From dholmes at mwdh2o.com Wed Mar 18 12:01:41 2009 From: dholmes at mwdh2o.com (Holmes,David A) Date: Wed, 18 Mar 2009 10:01:41 -0700 Subject: SUP720 vs. SUP32 In-Reply-To: References: <6069A203FD01884885C037F81DD75080CA064DA9@wsc-mail-01.intra.nwresd.k12.or.us><6069A203FD01884885C037F81DD75080CA064DD9@wsc-mail-01.intra.nwresd.k12.or.us><20090311193412.GC12934@skywalker.creative.net.au> Message-ID: <485ED9BA02629E4BBBA53AC892EDA50E08902F13@usmsxt104.mwd.h2o> Important network design parameters to take into consideration when planning SUP720 vs SUP32: 1. SUP720 has 720 Gb backplane (switchfabric) on supervisor card, and 32 Gb shared bus backplane. 2. SUP32 only has 32 Gb shared bus backplane 3. New Cisco line cards with dual 20 Gb connections to 720 Gb backplane only work in the SUP720, and some only in IOS version (such as the 16 port 10 GiGE line cards) 4. Older line cards that work with SUP32 have relatively small shared hardware buffers for every 8 ports, such that it is possible to run line rate through one port and cause drops on the other 7 ports 5. Cisco recommends SUP32 for the wiring closet, as a desktop aggregation device -----Original Message----- From: Norrie, David [mailto:David.Norrie at thus.net] Sent: Wednesday, March 18, 2009 9:48 AM To: Adrian Chadd; Bill Blackford Cc: nanog at nanog.org Subject: RE: SUP720 vs. SUP32 Hi, I have been searching cisco-nsp archive but not been able to find the article discussed below. I would appreciate it if someone does find the article if they can provide a copy/link to this : > Check the cisco-nsp archive, specifically from Rodney; he has talked about what the > CPU load versus throughput implications are on the G1 and G2. It might surprise you a > little. Thanks, David From menog at ripe.net Wed Mar 18 12:55:05 2009 From: menog at ripe.net (Paul Rendek) Date: Wed, 18 Mar 2009 18:55:05 +0100 Subject: RIPE NCC Regional Meeting/MENOG 4: Updated Agenda Message-ID: <49C13579.2060705@ripe.net> [Apologies for duplicate emails] Dear Colleagues, Join us at the RIPE NCC Regional Meeting/MENOG 4 in Manama, Bahrain, on 5?9 April 2009 at the M?venpick Hotel. This unique event for network operators and network engineers from the Middle East offers an exciting opportunity for you and your peers to discuss cross-regional issues, share experiences and meet with key players in the local and global Internet industry. This meeting includes tutorials, conference sessions and social events as well as two special world-class workshops on Routing and IPv6 for network operators and engineers from the Middle East. These three-day interactive workshops include a full lab designed for network engineers and operators who are running existing ISP infrastructure. Agenda ----------- The meeting agenda has been *updated* and is available online at: http://www.menog.net/meetings/menog4/agenda.php Registration ------------ The tutorials, conference sessions and social dinner are free to attend and are open to everyone. The special three-day workshops on Routing and IPv6 for network operators and engineers from the Middle East require an attendance fee of ?235 per workshop. The workshops run from Sunday through Tuesday, 5-7 April. The meeting takes place in three weeks time, so please register now at: http://www.menog.net/dyn.php?page=menog4registration Meeting Venue and Accommodation ------------------------------- Rooms at the M?venpick Hotel have been reserved at a special discounted rate for attendees. You must act by 22 March to secure a room at our special meeting rate! Room Rate per night: Single room is BD 85 Double room is BD 95 The booking form and details about the hotel can be found at: http://www.menog.net/meetings/menog4/venue.php We look forward to meeting you and your colleagues at the RIPE NCC Regional Meeting/MENOG 4. Please extend this invitation to anyone you feel may be interested in participating in this event. If you have any questions, please email . Regards, Paul Rendek Head of External Relations and Communications RIPE NCC On behalf of the RIPE NCC Regional Meeting/MENOG 4 Organisers From deepak at ai.net Wed Mar 18 14:31:52 2009 From: deepak at ai.net (Deepak Jain) Date: Wed, 18 Mar 2009 15:31:52 -0400 Subject: Leap second tonight In-Reply-To: <938AC6786A9CE64EA17214D592E906050A5D116784@exc01.office.nbl.fi> References: <20090317150651.83A731CC0B@ptavv.es.net> <24598.1237310500@turing-police.cc.vt.edu> <938AC6786A9CE64EA17214D592E906050A5D116784@exc01.office.nbl.fi> Message-ID: > > Not being a time geek, since Cisco's were called out for being wild > > jitter-mongers... how much jitter are we talking about? > > > > Clock is synchronized, stratum 2, xxxxxxxxxxxxxxxxxxxxxxxx > > nominal freq is 250.0000 Hz, actual freq is 249.9989 Hz, precision is > 2**18 > > reference time is CD6A7CD4.45A9BB00 (19:47:32.272 UTC Tue Mar 17 > 2009) > > clock offset is 2.0581 msec, root delay is 29.62 msec > > root dispersion is 6.81 msec, peer dispersion is 3.30 msec > > > > Are we talking about +/- 30 seconds, or a problem bounded by +/- 30 > msec? > > I've actually been gathering some statistics on this using Munin > (http://munin.projects.linpro.no/) on my linux server. There's > currently 10 ntp servers being monitored and one of them is a 7600- > series Cisco, which is handling quite a bit of traffic (CPU load around > 20%). Here are the Munin graphs for it http://dx.fi/alt/ntp/7600.png > (times in Finnish time, UTC+2). > > In comparison, here are the same graphs for time1.mikes.fi (a stratum-2 > clock provided by the Finnish Centre for metrology and accreditation) > http://dx.fi/alt/ntp/time1.mikes.fi.png and for Netnods stratum-1 clock > in Stockholm http://dx.fi/alt/ntp/ntp1.sth.netnod.se.png > In an NTP scenario, where each device is keeping its own time, and being "disciplined" by several others... don't these spikes of jitter get wiped away -- especially when multiple NTP sources are used? Perhaps I'm mistaken, but I thought that was the point of trying to keep precise time via an imprecise network [the jitter could easily be congestion in the case of long haul links] was that this can be mathematically worked out to a level of precision. Is a Cisco device lying when it says it has 2^18th precision? Are we just comparing and stating that between each sample from any one NTP device we might see wildly differently levels of accuracy/precision and the truly diligent time keeper will discipline his clocks with multiple readings over time? Thanks, Deepak From sil at infiltrated.net Wed Mar 18 14:37:14 2009 From: sil at infiltrated.net (J. Oquendo) Date: Wed, 18 Mar 2009 14:37:14 -0500 Subject: Off topic contact needed for Sangoma Message-ID: <20090318193714.GB67098@infiltrated.net> Apologies all, does anyone have a security contact on the network side for Sangoma. =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ J. Oquendo SGFA, SGFE, C|EH, CNDA, CHFI, OSCP "Enough research will tend to support your conclusions." - Arthur Bloch "A conclusion is the place where you got tired of thinking" - Arthur Bloch 227C 5D35 7DCB 0893 95AA 4771 1DCE 1FD1 5CCD 6B5E http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x5CCD6B5E From goemon at anime.net Wed Mar 18 14:40:47 2009 From: goemon at anime.net (goemon at anime.net) Date: Wed, 18 Mar 2009 12:40:47 -0700 (PDT) Subject: Redundant AS's In-Reply-To: <5.1.0.14.2.20090318095944.04fdb070@efes.iucc.ac.il> References: <5021774B-6774-4DF9-8864-DC45A184BCAA@eyeconomics.com> <5021774B-6774-4DF9-8864-DC45A184BCAA@eyeconomics.com> <5.1.0.14.2.20090318095944.04fdb070@efes.iucc.ac.il> Message-ID: On Wed, 18 Mar 2009, Hank Nussbacher wrote: > At 08:18 AM 18-03-09 +0100, Henk Uijterwaal wrote: >>> It's a bit dated now, but the RIPE report, ASN MIA, sounds like what >>> you're looking for... >>> www.apnic.net/meetings/21/docs/sigs/routing/routing-pres-uijterwaal-asn-mia.ppt >> When I look at this more recently, the conclusion still seems to be >> valid: we'll run out of 16 bit ASN's somewhere in 2011 to 2013. There >> are a lot of unused ASN's out there. Recovering them will postpone the >> problem by a few years but it won't solve it. The basic problem with >> recovery is how to decide if an ASN is really no longer used/needed. >> There is (still) no mechanism to do this. >> Henk > Why not go after low lying fruit first? If an ASN was assigned years ago and > hasn't appeared in the RIB for the past year that ASN should be reclaimed. > Send warning emails to the registered contacts as well as to the assigning > LIR and after 3 months - just reclaim it. How about just nailing everyone who has invalid contact info? That would certainly be incentive to get it updated. Nothing else seems to work. -Dan From deric.kwok2000 at gmail.com Wed Mar 18 14:51:59 2009 From: deric.kwok2000 at gmail.com (Deric Kwok) Date: Wed, 18 Mar 2009 15:51:59 -0400 Subject: real hardware router VS linux router In-Reply-To: <7BF22750-2082-4169-A5B2-8E61E20FAE33@daork.net> References: <40d8a95a0902190630k638b6487u6590dafd6e231eb2@mail.gmail.com> <499D754A.6030008@tiedyenetworks.com> <49A0559E.4050103@consolejunkie.net> <7BF22750-2082-4169-A5B2-8E61E20FAE33@daork.net> Message-ID: <40d8a95a0903181251p22701b7atde1a763b73501a60@mail.gmail.com> Anymore success to use multiple CPU to bind NIC to increase the performance Thank you On Sun, Feb 22, 2009 at 4:52 AM, Nathan Ward wrote: > On 22/02/2009, at 8:27 AM, Leen Besselink wrote: > > If you had to choose, it's probably smarted to go with OpenBSD, it has a >> lot better integration of packet filter, bgpd-daemon, ospf, vrrp-like, >> etc. >> > > If you have one eBGP session in your whole network, sure. > > However if you have more than one, BGP cannot do the "Prefer the path with > the lowest IGP next-hop metric" thing, as OpenBGPd does not know metrics > from OpenOSPFd. Someone commented that OpenBSD would be able to do this soon > as metrics were added in to the routing code in -current, but I have not > tried this personally and a quick couple of queries on Google didn't reveal > anything other than internal OpenOSPFd stuff. > > I have however used OpenBGPd and OpenOSPFd with great success on routers we > put at single-homed customer sites for a small business-only ISP I used to > work at. We used BGP communities to put prefixes in to PF tables, and then > shaped and accounted based on that. (Here in NZ we have a few thousand > domestic prefixes, which transit to/from is often cheaper than transit > off-shore). > > -- > Nathan Ward > > > From joelja at bogus.com Wed Mar 18 16:20:17 2009 From: joelja at bogus.com (Joel Jaeggli) Date: Wed, 18 Mar 2009 14:20:17 -0700 Subject: help with connectivity check? In-Reply-To: <49C04521.2020405@packetnexus.com> References: <49C04521.2020405@packetnexus.com> Message-ID: <49C16591.4090306@bogus.com> Jason Lewis wrote: > This brings up something I've been thinking about. Are there any free > services that let you submit an IP and get traces back from multiple > geographic locations? > > There are plenty of internet measurement projects, but none of them seem > to let you do a live trace and get the data back in a parseable format. not it's intended purpose however I would observe: [jaeggli at winged-monkey ~]$ telnet route-views.routeviews.org Trying 128.223.51.103... Connected to route-views.routeviews.org. Escape character is '^]'. C ********************************************************************** Oregon Exchange BGP Route Viewer route-views.oregon-ix.net / route-views.routeviews.org route views data is archived on http://archive.routeviews.org This hardware is part of a grant from Cisco Systems. Please contact help at routeviews.org if you have questions or comments about this service, its use, or if you might be able to contribute your view. This router has views of the full routing tables from several ASes. The list of ASes is documented under "Current Participants" on http://www.routeviews.org/. ************** route-views.routeviews.org is now using AAA for logins. Login with username "rviews". See http://routeviews.org/aaa.html ********************************************************************** User Access Verification Username: rviews route-views.oregon-ix.net>traceroute google.com Type escape sequence to abort. Tracing the route to google.com (209.85.171.100) 1 vl-51.uonet1-gw.uoregon.edu (128.223.51.2) [AS 3582] 0 msec 0 msec 0 msec 2 0.ge-0-1-0.uonet8-gw.uoregon.edu (128.223.3.8) [AS 3582] 0 msec 0 msec 0 msec 3 eugn-car1-gw.nero.net (207.98.64.65) [AS 3582] 0 msec 0 msec 0 msec 4 eugn-core2-gw.nero.net (207.98.64.162) [AS 3701] 0 msec 4 msec 0 msec 5 ptck-core2-gw.nero.net (207.98.64.10) [AS 3701] 0 msec 4 msec 4 msec 6 * * * 7 72.14.239.13 [AS 15169] [MPLS: Label 736513 Exp 4] 4 msec 8 msec 8 msec 8 72.14.233.117 [AS 15169] [MPLS: Label 532102 Exp 4] 52 msec 56 msec 52 msec 9 209.85.240.159 [AS 15169] 52 msec 52 msec 56 msec 10 google.com (209.85.171.100) [AS 15169] 52 msec 52 msec 52 msec > jas > > Edward B. DREGER wrote: >> EBD> Date: Wed, 18 Mar 2009 00:13:48 +0000 (GMT) >> EBD> From: Edward B. DREGER >> >> Many thanks to all who have responded. I think/hope I have enough >> information now! >> >> > From woody at pch.net Wed Mar 18 18:18:20 2009 From: woody at pch.net (Bill Woodcock) Date: Wed, 18 Mar 2009 16:18:20 -0700 Subject: Seeking Connectivity in IRAQ In-Reply-To: <16720fe00903161103p7e462cb3p244e672ab2d05c45@mail.gmail.com> References: <023b01c9a65a$70cd9b00$5268d100$@edu> <16720fe00903161103p7e462cb3p244e672ab2d05c45@mail.gmail.com> Message-ID: On Mar 16, 2009, at 11:03 AM, Jeffrey Lyon wrote: > Check out Wataniya and Zain... > > On Mon, Mar 16, 2009 at 1:12 PM, Robert D. Scott > wrote: >> A unit within the University has need to get reliable network >> connectivity >> to Iraq, more specifically Baghdad. I was wondering if any nanogers >> have any >> recommendations and/or contacts with providers in the area. Forwarded from Ryan Lackey: > satellite is the only good option in iraq still, if he really wants > reliable. standard international scpc. > > in kuwait you can buy a zain "ego2go" prepaid 3G, but most of the zain > stores don't like to sell them. also, att/tmo have international > blackberry roaming which works with edge, flatrate, and if you have > a BES > you can tether it. -Bill -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part URL: From pauldotwall at gmail.com Wed Mar 18 18:34:03 2009 From: pauldotwall at gmail.com (Paul Wall) Date: Wed, 18 Mar 2009 19:34:03 -0400 Subject: UnitedLayer Message-ID: <620fd17c0903181634k42f8b9e2m128df330a7921deb@mail.gmail.com> I heard about some recent lay-offs and customer losses at UnitedLayer and I was wondering if they're still solvent? Paul From gerard at avolutia.com Wed Mar 18 19:12:03 2009 From: gerard at avolutia.com (Gerard Dupont III) Date: Wed, 18 Mar 2009 20:12:03 -0400 Subject: Seeking Connectivity in IRAQ In-Reply-To: <023b01c9a65a$70cd9b00$5268d100$@edu> References: <023b01c9a65a$70cd9b00$5268d100$@edu> Message-ID: <49C18DD3.1040008@avolutia.com> Have you looked at http://www.tigrisnet.net or http://www.sniperhill.com Gerard Robert D. Scott wrote: > A unit within the University has need to get reliable network connectivity > to Iraq, more specifically Baghdad. I was wondering if any nanogers have any > recommendations and/or contacts with providers in the area. Wired or > Wireless. Off-list is fine. > > TIA > > Robert D. Scott Robert at ufl.edu > Senior Network Engineer 352-273-0113 Phone > CNS - Network Services 352-392-2061 CNS Phone Tree > University of Florida 352-392-9440 FAX > Florida Lambda Rail 352-294-3571 FLR NOC > Gainesville, FL 32611 321-663-0421 Cell > > > > From tim at baseworx.net Wed Mar 18 21:27:25 2009 From: tim at baseworx.net (Tim McKee) Date: Wed, 18 Mar 2009 22:27:25 -0400 Subject: Seeking Connectivity in IRAQ In-Reply-To: <49C18DD3.1040008@avolutia.com> References: <023b01c9a65a$70cd9b00$5268d100$@edu> <49C18DD3.1040008@avolutia.com> Message-ID: <005f01c9a83a$3e758af0$bb60a0d0$@net> www.sdnglobal.com does enterprise grade satellite service. Tim mckee -----Original Message----- From: Gerard Dupont III [mailto:gerard at avolutia.com] Sent: Wednesday, March 18, 2009 20:12 To: Robert D. Scott Cc: nanog at nanog.org Subject: Re: Seeking Connectivity in IRAQ Have you looked at http://www.tigrisnet.net or http://www.sniperhill.com Gerard Robert D. Scott wrote: > A unit within the University has need to get reliable network connectivity > to Iraq, more specifically Baghdad. I was wondering if any nanogers have any > recommendations and/or contacts with providers in the area. Wired or > Wireless. Off-list is fine. > > TIA > > Robert D. Scott Robert at ufl.edu > Senior Network Engineer 352-273-0113 Phone > CNS - Network Services 352-392-2061 CNS Phone Tree > University of Florida 352-392-9440 FAX > Florida Lambda Rail 352-294-3571 FLR NOC > Gainesville, FL 32611 321-663-0421 Cell > > > > ________________________________________ This email has been scanned with ClamAV! ________________________________________ This email has been scanned with ClamAV! From jules.rogers at gmail.com Wed Mar 18 22:10:03 2009 From: jules.rogers at gmail.com (Jules Rogers) Date: Wed, 18 Mar 2009 22:10:03 -0500 Subject: Seeking Connectivity in IRAQ In-Reply-To: <023b01c9a65a$70cd9b00$5268d100$@edu> References: <023b01c9a65a$70cd9b00$5268d100$@edu> Message-ID: <89e9216c0903182010n2f25c8e6g14ab8e0591571fdc@mail.gmail.com> Try Stratos Global http://www.stratosglobal.com/, they offer MSS and VSAT services. _____________ Jules J. Rogers On Mon, Mar 16, 2009 at 12:12 PM, Robert D. Scott wrote: > A unit within the University has need to get reliable network connectivity > to Iraq, more specifically Baghdad. I was wondering if any nanogers have > any > recommendations and/or contacts with providers in the area. Wired or > Wireless. Off-list is fine. > > TIA > > Robert D. Scott Robert at ufl.edu > Senior Network Engineer 352-273-0113 Phone > CNS - Network Services 352-392-2061 CNS Phone Tree > University of Florida 352-392-9440 FAX > Florida Lambda Rail 352-294-3571 FLR NOC > Gainesville, FL 32611 321-663-0421 Cell > > > > > From vish.yelsangikar at rea-group.com Wed Mar 18 22:10:53 2009 From: vish.yelsangikar at rea-group.com (Vish Yelsangikar) Date: Thu, 19 Mar 2009 14:10:53 +1100 Subject: Connectivity Issues between Eu and Au? In-Reply-To: <005f01c9a83a$3e758af0$bb60a0d0$@net> References: <023b01c9a65a$70cd9b00$5268d100$@edu><49C18DD3.1040008@avolutia.com> <005f01c9a83a$3e758af0$bb60a0d0$@net> Message-ID: <6FA6124E9378214883CA93A54AED601D1046F715@EMAIL.win.int.realestate.com.au> Has anyone noticed any connectivity problems between Europe (Milan, London and Amsterdam) to Au (Melbourne). We have various carriers on Europe side including Level3, Telecity's IP transit and on Australia side we have Telstra, MCI and Primus. We have seen intermittent connectivity issues in 2 days in a row between all these carriers. Send me a mail off-list if you have any info on this. Cheers. Vish Yelsangikar Global Infrastructure Architect realestate.com.au the biggest address in property M: +91 99802 96853 T: +1 408 253 7282 From lowen at pari.edu Wed Mar 18 23:18:28 2009 From: lowen at pari.edu (Lamar Owen) Date: Thu, 19 Mar 2009 00:18:28 -0400 Subject: Seeking Connectivity in IRAQ In-Reply-To: <005f01c9a83a$3e758af0$bb60a0d0$@net> References: <023b01c9a65a$70cd9b00$5268d100$@edu> Message-ID: <200903190018.29104.lowen@pari.edu> On Wednesday 18 March 2009 22:27:25 Tim McKee wrote: > www.sdnglobal.com does enterprise grade satellite service. > > Tim mckee As a side job, I'm a consultant for a radio station in NC with a mobile SDN system; works great, very reliable, tolerable latency; a must, since this station, due to the terrain in the Appalachians, cannot easily use standard RPU's for many live remotes, and thus is using SDN satellite IP to carry audio and video streams from the site of the remote. Setup at the time this system was installed as a certified installer only thing; but the guy that did ours did it good. SDN has a good reputation from what I can find, too. Shades of SunBelt, Tim! From hank at efes.iucc.ac.il Thu Mar 19 00:50:36 2009 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Thu, 19 Mar 2009 07:50:36 +0200 Subject: Redundant AS's In-Reply-To: References: <5.1.0.14.2.20090318095944.04fdb070@efes.iucc.ac.il> <5021774B-6774-4DF9-8864-DC45A184BCAA@eyeconomics.com> <5021774B-6774-4DF9-8864-DC45A184BCAA@eyeconomics.com> <5.1.0.14.2.20090318095944.04fdb070@efes.iucc.ac.il> Message-ID: <5.1.0.14.2.20090319074418.00aca8c8@efes.iucc.ac.il> At 12:40 PM 18-03-09 -0700, goemon at anime.net wrote: >On Wed, 18 Mar 2009, Hank Nussbacher wrote: >>At 08:18 AM 18-03-09 +0100, Henk Uijterwaal wrote: >>>>It's a bit dated now, but the RIPE report, ASN MIA, sounds like what >>>>you're looking for... >>>>www.apnic.net/meetings/21/docs/sigs/routing/routing-pres-uijterwaal-asn-mia.ppt >>>> >>>When I look at this more recently, the conclusion still seems to be >>>valid: we'll run out of 16 bit ASN's somewhere in 2011 to 2013. There >>>are a lot of unused ASN's out there. Recovering them will postpone the >>>problem by a few years but it won't solve it. The basic problem with >>>recovery is how to decide if an ASN is really no longer used/needed. >>>There is (still) no mechanism to do this. >>>Henk >>Why not go after low lying fruit first? If an ASN was assigned years ago >>and hasn't appeared in the RIB for the past year that ASN should be >>reclaimed. Send warning emails to the registered contacts as well as to >>the assigning LIR and after 3 months - just reclaim it. > >How about just nailing everyone who has invalid contact info? That would >certainly be incentive to get it updated. Nothing else seems to work. > >-Dan How about making it financially worth it? RIRs charge for resources - like IPs and ASNs: http://www.ripe.net/ripe/docs/charging2009.html 1 ASN = /21 in money terms. It takes me about 3-5 hours of work to track down and get an old unused ASN to be deallocated. How about updating the 2010 charging model so that LIRs that return ASNs are compensated? -Hank From arman at unitedlayer.com Thu Mar 19 01:07:29 2009 From: arman at unitedlayer.com (Arman Khalili) Date: Wed, 18 Mar 2009 23:07:29 -0700 Subject: UnitedLayer In-Reply-To: <620fd17c0903181634k42f8b9e2m128df330a7921deb@mail.gmail.com> References: <620fd17c0903181634k42f8b9e2m128df330a7921deb@mail.gmail.com> Message-ID: <49C1E121.701@unitedlayer.com> Paul We are doing well. Not sure where you are getting your info from. Arman Paul Wall wrote: > I heard about some recent lay-offs and customer losses at UnitedLayer > and I was wondering if they're still solvent? > > Paul > > From a.harrowell at gmail.com Thu Mar 19 03:40:42 2009 From: a.harrowell at gmail.com (Alexander Harrowell) Date: Thu, 19 Mar 2009 08:40:42 +0000 Subject: Seeking Connectivity in IRAQ In-Reply-To: <200903190018.29104.lowen@pari.edu> References: <023b01c9a65a$70cd9b00$5268d100$@edu> <49C18DD3.1040008@avolutia.com> <005f01c9a83a$3e758af0$bb60a0d0$@net> <200903190018.29104.lowen@pari.edu> Message-ID: NewSkies' NSS703 is apparently intended to cover Turkey and Iraq especially well; www.talia.net and probably many others resell the service, or you can buy it directly (http://www.newskies.com/ipsyssolutions.htm). Perhaps you could say what kind of connectivity you need? As various people have pointed out, there are several GSM/UMTS operators, but this isn't a solution for a whole network there. On Thu, Mar 19, 2009 at 4:18 AM, Lamar Owen wrote: > On Wednesday 18 March 2009 22:27:25 Tim McKee wrote: > > www.sdnglobal.com does enterprise grade satellite service. > > > > Tim mckee > > As a side job, I'm a consultant for a radio station in NC with a mobile SDN > system; works great, very reliable, tolerable latency; a must, since this > station, due to the terrain in the Appalachians, cannot easily use standard > RPU's for many live remotes, and thus is using SDN satellite IP to carry > audio > and video streams from the site of the remote. > > Setup at the time this system was installed as a certified installer only > thing; but the guy that did ours did it good. SDN has a good reputation > from > what I can find, too. > > Shades of SunBelt, Tim! > > From damin at nacs.net Thu Mar 19 07:19:50 2009 From: damin at nacs.net (Gregory Boehnlein) Date: Thu, 19 Mar 2009 08:19:50 -0400 Subject: Seeking Connectivity in IRAQ In-Reply-To: <89e9216c0903182010n2f25c8e6g14ab8e0591571fdc@mail.gmail.com> References: <023b01c9a65a$70cd9b00$5268d100$@edu> <89e9216c0903182010n2f25c8e6g14ab8e0591571fdc@mail.gmail.com> Message-ID: <036d01c9a88d$006da2d0$0148e870$@net> I've also had good luck with Skycasters (http://www.skycasters.com) but I'm not sure if their coverage extends to that part of the world. From nick at switchtower.org Thu Mar 19 10:54:27 2009 From: nick at switchtower.org (Nicholas R. Cappelletti) Date: Thu, 19 Mar 2009 11:54:27 -0400 (EDT) Subject: Issues with Level3 in chicago? In-Reply-To: <16841352.01237477981690.JavaMail.root@mail.switchtower.org> Message-ID: <8664812.21237478067917.JavaMail.root@mail.switchtower.org> We just experienced some connection issues with outgoing traffic through Level3. Anyone with similar issues? I can provide some traceroutes if needed, but just wanted to see if anyone else had similar problems. --- Nick Cappelletti nick at switchtower.org From rrodriguez at ifbyphone.com Thu Mar 19 11:10:32 2009 From: rrodriguez at ifbyphone.com (Robin Rodriguez) Date: Thu, 19 Mar 2009 11:10:32 -0500 Subject: Issues with Level3 in chicago? In-Reply-To: <8664812.21237478067917.JavaMail.root@mail.switchtower.org> References: <8664812.21237478067917.JavaMail.root@mail.switchtower.org> Message-ID: <49C26E78.7010005@ifbyphone.com> What kind of issues? I just checked two 10G connections from 350 Canal and 1905 Lunt and don't seen anything of concern. Most of my traffic stays on Level3, so I only briefly checked that I could route off Level3 from the connections. Seems fine here Robin Nicholas R. Cappelletti wrote: > We just experienced some connection issues with outgoing traffic through Level3. Anyone with similar issues? > > I can provide some traceroutes if needed, but just wanted to see if anyone else had similar problems. > > --- > > Nick Cappelletti > nick at switchtower.org > > > -- Robin D. Rodriguez Systems Engineer Ifbyphone, Inc. Phone: (866) 250-1663 Fax: (847) 676-6553 rrodriguez at ifbyphone.com http://www.ifbyphone.com From nick at switchtower.org Thu Mar 19 11:15:59 2009 From: nick at switchtower.org (Nicholas R. Cappelletti) Date: Thu, 19 Mar 2009 12:15:59 -0400 (EDT) Subject: Issues with Level3 in chicago? In-Reply-To: <49C26E78.7010005@ifbyphone.com> Message-ID: <24999505.3551237479256630.JavaMail.nick@switchtower> Robin, It's resolved now, but we had customers calling in saying they could no longer get to their sites. The traceroutes to us were dying at the servers, and a reverse trace to their public IP address was showing the trace dying a few hops past our borders. --- Nick Cappelletti nick at switchtower.org ----- Original Message ----- From: "Robin Rodriguez" To: nanog at nanog.org Sent: Thursday, March 19, 2009 12:10:32 PM GMT -05:00 US/Canada Eastern Subject: Re: Issues with Level3 in chicago? What kind of issues? I just checked two 10G connections from 350 Canal and 1905 Lunt and don't seen anything of concern. Most of my traffic stays on Level3, so I only briefly checked that I could route off Level3 from the connections. Seems fine here Robin Nicholas R. Cappelletti wrote: > We just experienced some connection issues with outgoing traffic through Level3. Anyone with similar issues? > > I can provide some traceroutes if needed, but just wanted to see if anyone else had similar problems. > > --- > > Nick Cappelletti > nick at switchtower.org > > > -- Robin D. Rodriguez Systems Engineer Ifbyphone, Inc. Phone: (866) 250-1663 Fax: (847) 676-6553 rrodriguez at ifbyphone.com http://www.ifbyphone.com From nick at switchtower.org Thu Mar 19 11:16:39 2009 From: nick at switchtower.org (Nicholas R. Cappelletti) Date: Thu, 19 Mar 2009 12:16:39 -0400 (EDT) Subject: Issues with Level3 in chicago? In-Reply-To: <49C26E78.7010005@ifbyphone.com> Message-ID: <23262776.3571237479294170.JavaMail.nick@switchtower> Robin, It's resolved now, but we had customers calling in saying they could no longer get to their sites. The traceroutes to us were dying at the servers, and a reverse trace to their public IP address was showing the trace dying a few hops past our borders. --- Nick Cappelletti nick at switchtower.org --- Nick Cappelletti nick at switchtower.org ----- Original Message ----- From: "Robin Rodriguez" To: nanog at nanog.org Sent: Thursday, March 19, 2009 12:10:32 PM GMT -05:00 US/Canada Eastern Subject: Re: Issues with Level3 in chicago? What kind of issues? I just checked two 10G connections from 350 Canal and 1905 Lunt and don't seen anything of concern. Most of my traffic stays on Level3, so I only briefly checked that I could route off Level3 from the connections. Seems fine here Robin Nicholas R. Cappelletti wrote: > We just experienced some connection issues with outgoing traffic through Level3. Anyone with similar issues? > > I can provide some traceroutes if needed, but just wanted to see if anyone else had similar problems. > > --- > > Nick Cappelletti > nick at switchtower.org > > > -- Robin D. Rodriguez Systems Engineer Ifbyphone, Inc. Phone: (866) 250-1663 Fax: (847) 676-6553 rrodriguez at ifbyphone.com http://www.ifbyphone.com From geoincidents at nls.net Thu Mar 19 11:16:54 2009 From: geoincidents at nls.net (Geo.) Date: Thu, 19 Mar 2009 12:16:54 -0400 Subject: Issues with Level3 in chicago? In-Reply-To: <49C26E78.7010005@ifbyphone.com> Message-ID: Don't know if it's related but there was a Level 3 OC48 that went down at 2:52am this morning because of a DMX issue. It's been back up since about 10am EDT though. George Roettger Netlink Services > -----Original Message----- > From: Robin Rodriguez [mailto:rrodriguez at ifbyphone.com] > Sent: Thursday, March 19, 2009 12:11 PM > To: nanog at nanog.org > Subject: Re: Issues with Level3 in chicago? > > > What kind of issues? I just checked two 10G connections from 350 Canal > and 1905 Lunt and don't seen anything of concern. Most of my traffic > stays on Level3, so I only briefly checked that I could route off Level3 > from the connections. Seems fine here > > Robin From nrauhauser at gmail.com Thu Mar 19 11:25:17 2009 From: nrauhauser at gmail.com (neal rauhauser) Date: Thu, 19 Mar 2009 11:25:17 -0500 Subject: Issues with Level3 in chicago? In-Reply-To: <8664812.21237478067917.JavaMail.root@mail.switchtower.org> References: <16841352.01237477981690.JavaMail.root@mail.switchtower.org> <8664812.21237478067917.JavaMail.root@mail.switchtower.org> Message-ID: <9515c62d0903190925t1cd73a9bi1b046216da54f6df@mail.gmail.com> Major convulsions visible to Sprint customers when crossing into Level3 and lots of flaps showing in route-views.oregon-ix.net for our prefixes. Calgon, take me away ... On Thu, Mar 19, 2009 at 10:54 AM, Nicholas R. Cappelletti < nick at switchtower.org> wrote: > We just experienced some connection issues with outgoing traffic through > Level3. Anyone with similar issues? > > I can provide some traceroutes if needed, but just wanted to see if anyone > else had similar problems. > > --- > > Nick Cappelletti > nick at switchtower.org > > -- mailto:Neal at layer3arts.com // GoogleTalk: nrauhauser at gmail.com IM: nealrauhauser From jrichesin at gmail.com Thu Mar 19 13:13:01 2009 From: jrichesin at gmail.com (Josh Richesin) Date: Thu, 19 Mar 2009 11:13:01 -0700 Subject: Looking for a contact at Google Noc Message-ID: Hello, I for some reason, can not find a way to get in contact with the Google NOC. I am having trouble with some of our routes getting to them. I tried calling the number that ARIN has for them but no luck. Thanks, -- Josh Richesin From fw at deneb.enyo.de Fri Mar 20 03:44:21 2009 From: fw at deneb.enyo.de (Florian Weimer) Date: Fri, 20 Mar 2009 09:44:21 +0100 Subject: Redundant AS's In-Reply-To: <5.1.0.14.2.20090319074418.00aca8c8@efes.iucc.ac.il> (Hank Nussbacher's message of "Thu, 19 Mar 2009 07:50:36 +0200") References: <5.1.0.14.2.20090318095944.04fdb070@efes.iucc.ac.il> <5021774B-6774-4DF9-8864-DC45A184BCAA@eyeconomics.com> <5021774B-6774-4DF9-8864-DC45A184BCAA@eyeconomics.com> <5.1.0.14.2.20090318095944.04fdb070@efes.iucc.ac.il> <5.1.0.14.2.20090319074418.00aca8c8@efes.iucc.ac.il> Message-ID: <878wn060t6.fsf@mid.deneb.enyo.de> * Hank Nussbacher: > It takes me about 3-5 hours of work to track down and get an old > unused ASN to be deallocated. How about updating the 2010 charging > model so that LIRs that return ASNs are compensated? I don't think this is a good way of using RIR funds. Why should the old guys receive even more special treatment? RIPE's charging scheme already discriminates heavily against newcomers. From hank at efes.iucc.ac.il Fri Mar 20 05:40:15 2009 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Fri, 20 Mar 2009 12:40:15 +0200 (IST) Subject: Redundant AS's In-Reply-To: <878wn060t6.fsf@mid.deneb.enyo.de> References: <5.1.0.14.2.20090318095944.04fdb070@efes.iucc.ac.il> <5021774B-6774-4DF9-8864-DC45A184BCAA@eyeconomics.com> <5021774B-6774-4DF9-8864-DC45A184BCAA@eyeconomics.com> <5.1.0.14.2.20090318095944.04fdb070@efes.iucc.ac.il> <5.1.0.14.2.20090319074418.00aca8c8@efes.iucc.ac.il> <878wn060t6.fsf@mid.deneb.enyo.de> Message-ID: On Fri, 20 Mar 2009, Florian Weimer wrote: > * Hank Nussbacher: > >> It takes me about 3-5 hours of work to track down and get an old >> unused ASN to be deallocated. How about updating the 2010 charging >> model so that LIRs that return ASNs are compensated? > > I don't think this is a good way of using RIR funds. Why should the > old guys receive even more special treatment? RIPE's charging scheme > already discriminates heavily against newcomers. I disagree. Older LIRs have more allocations which compensates for the time factor of the algorithm. Older allocations need almost no human handling by the RIR vs a new LIR of a year which has a oodles of tickets that need human intervention. -Hank From cidr-report at potaroo.net Fri Mar 20 06:00:05 2009 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 20 Mar 2009 22:00:05 +1100 (EST) Subject: BGP Update Report Message-ID: <200903201100.n2KB05Nr014733@wattle.apnic.net> BGP Update Report Interval: 16-Feb-09 -to- 19-Mar-09 (32 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS9583 253960 5.8% 239.4 -- SIFY-AS-IN Sify Limited 2 - AS3130 89734 2.1% 690.3 -- RGNET-3130 RGnet/PSGnet 3 - AS6629 47663 1.1% 6809.0 -- NOAA-AS - NOAA 4 - AS17974 38119 0.9% 73.4 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 5 - AS35805 35885 0.8% 119.6 -- UTG-AS United Telecom AS 6 - AS5056 31399 0.7% 273.0 -- INS-NET-2 - Iowa Network Services 7 - AS4771 29929 0.7% 114.2 -- NZTELECOM Netgate 8 - AS6458 28813 0.7% 86.5 -- Telgua 9 - AS9498 28440 0.7% 40.7 -- BBIL-AP BHARTI Airtel Ltd. 10 - AS29372 27845 0.6% 312.9 -- SFR-NETWORK SFR 11 - AS17488 25506 0.6% 15.5 -- HATHWAY-NET-AP Hathway IP Over Cable Internet 12 - AS5050 24268 0.6% 2426.8 -- PSC-EXT - Pittsburgh Supercomputing Center 13 - AS9829 24134 0.6% 38.3 -- BSNL-NIB National Internet Backbone 14 - AS30306 23561 0.5% 5890.2 -- AfOL-Sz-AS 15 - AS7643 22355 0.5% 19.6 -- VNN-AS-AP Vietnam Posts and Telecommunications (VNPT) 16 - AS4648 21617 0.5% 106.0 -- NZIX-2 Netgate 17 - AS4795 19482 0.5% 59.9 -- INDOSATM2-ID INDOSATM2 ASN 18 - AS8103 19256 0.4% 32.1 -- STATE-OF-FLA - Florida Department of Management Services - Technology Program 19 - AS4249 18550 0.4% 106.0 -- LILLY-AS - Eli Lilly and Company 20 - AS10620 17379 0.4% 20.3 -- TV Cable S.A. TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS5691 10287 0.2% 10287.0 -- MITRE-AS-5 - The MITRE Corporation 2 - AS6629 47663 1.1% 6809.0 -- NOAA-AS - NOAA 3 - AS30306 23561 0.5% 5890.2 -- AfOL-Sz-AS 4 - AS19017 5796 0.1% 5796.0 -- QUALCOMM-QWBS-LV - Qualcomm, Inc. 5 - AS6312 3279 0.1% 3279.0 -- WESTWORLD-AS - WestWorld Media, LLC 6 - AS8225 3108 0.1% 3108.0 -- ASTELIT-MSK-AS Astelit Autonomous System 7 - AS41343 5906 0.1% 2953.0 -- TRIUNFOTEL-ASN TRIUNFOTEL 8 - AS5050 24268 0.6% 2426.8 -- PSC-EXT - Pittsburgh Supercomputing Center 9 - AS28194 4620 0.1% 2310.0 -- 10 - AS46653 6467 0.1% 2155.7 -- FREDRIKSON---BYRON - Fredrikson & Byron, P.A. 11 - AS12500 6320 0.1% 2106.7 -- RCS-AS RCS Autonomus System 12 - AS8755 2068 0.1% 2068.0 -- CITYLINESPB-AS CityLine-SPb Autonomous System 13 - AS48144 2006 0.1% 2006.0 -- NETWORKTECH Network Technology 14 - AS30552 1966 0.1% 1966.0 -- SAINT-JOSEPHS-HOSPITAL-OF-ATLANTA - Saint Joseph's Hospital of Atlanta 15 - AS3944 1944 0.0% 1944.0 -- PARTAN-LAB - Partan & Partan 16 - AS32398 12766 0.3% 1595.8 -- REALNET-ASN-1 17 - AS46328 14167 0.3% 1574.1 -- PTCNEBRASKA - PIERCE TELEPHONE COMPANY, INCORPORATED 18 - AS35335 1527 0.0% 1527.0 -- ESSTU-AS East-Siberian State Technological University AS 19 - AS30287 1492 0.0% 1492.0 -- ALON-USA - ALON USA, LP 20 - AS30520 5756 0.1% 1439.0 -- NUANCE-SOMERVILLE - NUANCE COMMUNICATIONS, INC TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 72.23.246.0/24 24166 0.5% AS5050 -- PSC-EXT - Pittsburgh Supercomputing Center 2 - 221.134.32.0/24 22424 0.5% AS9583 -- SIFY-AS-IN Sify Limited 3 - 221.135.105.0/24 21045 0.4% AS9583 -- SIFY-AS-IN Sify Limited 4 - 210.214.177.0/24 20999 0.4% AS9583 -- SIFY-AS-IN Sify Limited 5 - 210.214.232.0/24 20910 0.4% AS9583 -- SIFY-AS-IN Sify Limited 6 - 210.214.184.0/24 20833 0.4% AS9583 -- SIFY-AS-IN Sify Limited 7 - 210.214.156.0/24 20830 0.4% AS9583 -- SIFY-AS-IN Sify Limited 8 - 210.214.132.0/24 20826 0.4% AS9583 -- SIFY-AS-IN Sify Limited 9 - 210.214.222.0/24 20744 0.4% AS9583 -- SIFY-AS-IN Sify Limited 10 - 210.214.146.0/24 20619 0.4% AS9583 -- SIFY-AS-IN Sify Limited 11 - 210.214.117.0/24 20472 0.4% AS9583 -- SIFY-AS-IN Sify Limited 12 - 210.210.127.0/24 20403 0.4% AS9583 -- SIFY-AS-IN Sify Limited 13 - 192.35.129.0/24 15986 0.3% AS6629 -- NOAA-AS - NOAA 14 - 192.102.88.0/24 15872 0.3% AS6629 -- NOAA-AS - NOAA 15 - 198.77.177.0/24 15790 0.3% AS6629 -- NOAA-AS - NOAA 16 - 41.204.2.0/24 12442 0.3% AS32398 -- REALNET-ASN-1 17 - 212.85.223.0/24 11395 0.2% AS30306 -- AfOL-Sz-AS 18 - 212.85.220.0/24 11387 0.2% AS19711 -- SWAZI-NET AS30306 -- AfOL-Sz-AS 20 - 205.104.240.0/20 10674 0.2% AS5237 -- DODNIC - DoD Network Information Center AS5839 -- DDN-ASNBLK - DoD Network Information Center Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Mar 20 06:00:02 2009 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 20 Mar 2009 22:00:02 +1100 (EST) Subject: The Cidr Report Message-ID: <200903201100.n2KB02fm014726@wattle.apnic.net> This report has been generated at Fri Mar 20 21:14:04 2009 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 13-03-09 289939 180761 14-03-09 289873 180675 15-03-09 289989 180688 16-03-09 289977 180873 17-03-09 289990 180964 18-03-09 290318 180827 19-03-09 290375 181084 20-03-09 290412 181230 AS Summary 30948 Number of ASes in routing system 13129 Number of ASes announcing only one prefix 4324 Largest number of prefixes announced by an AS AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc. 89742336 Largest address span announced by an AS (/32s) AS27064: DDN-ASNBLK1 - DoD Network Information Center Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 20Mar09 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 290499 181251 109248 37.6% All ASes AS6389 4324 343 3981 92.1% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4323 4244 1839 2405 56.7% TWTC - tw telecom holdings, inc. AS209 2916 1281 1635 56.1% ASN-QWEST - Qwest Communications Corporation AS4766 1818 527 1291 71.0% KIXS-AS-KR Korea Telecom AS17488 1530 330 1200 78.4% HATHWAY-NET-AP Hathway IP Over Cable Internet AS22773 1038 66 972 93.6% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS4755 1218 263 955 78.4% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS8452 1250 335 915 73.2% TEDATA TEDATA AS8151 1445 558 887 61.4% Uninet S.A. de C.V. AS1785 1732 888 844 48.7% AS-PAETEC-NET - PaeTec Communications, Inc. AS19262 969 250 719 74.2% VZGNI-TRANSIT - Verizon Internet Services Inc. AS11492 1194 525 669 56.0% CABLEONE - CABLE ONE, INC. AS7545 785 199 586 74.6% TPG-INTERNET-AP TPG Internet Pty Ltd AS6478 1295 736 559 43.2% ATT-INTERNET3 - AT&T WorldNet Services AS18101 755 201 554 73.4% RIL-IDC Reliance Infocom Ltd Internet Data Centre, AS3356 1175 646 529 45.0% LEVEL3 Level 3 Communications AS2706 544 26 518 95.2% HKSUPER-HK-AP Pacific Internet (Hong Kong) Limited AS22047 606 120 486 80.2% VTR BANDA ANCHA S.A. AS17908 601 125 476 79.2% TCISL Tata Communications AS4808 612 158 454 74.2% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS7018 1451 1017 434 29.9% ATT-INTERNET4 - AT&T WorldNet Services AS24560 678 250 428 63.1% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS9443 510 91 419 82.2% INTERNETPRIMUS-AS-AP Primus Telecommunications AS4804 476 63 413 86.8% MPX-AS Microplex PTY LTD AS17676 530 119 411 77.5% GIGAINFRA BB TECHNOLOGY Corp. AS4668 691 284 407 58.9% LGNET-AS-KR LG CNS AS4134 933 529 404 43.3% CHINANET-BACKBONE No.31,Jin-rong Street AS7011 953 553 400 42.0% FRONTIER-AND-CITIZENS - Frontier Communications of America, Inc. AS10620 845 460 385 45.6% TV Cable S.A. AS6471 441 62 379 85.9% ENTEL CHILE S.A. Total 37559 12844 24715 65.8% Top 30 total Possible Bogus Routes 24.75.116.0/22 AS10796 SCRR-10796 - Road Runner HoldCo LLC 24.245.128.0/17 AS11492 CABLEONE - CABLE ONE, INC. 24.246.0.0/17 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 24.246.128.0/18 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 41.220.16.0/20 AS8668 TELONE-AS TelOne Zimbabwe P/L 41.223.112.0/22 AS5713 SAIX-NET 41.223.188.0/24 AS22351 INTELSAT Intelsat Global BGP Routing Policy 41.223.189.0/24 AS26452 BRING-AS - BringCom, Inc. 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 63.140.213.0/24 AS22555 UTC - Universal Talkware Corporation 63.143.251.0/24 AS22555 UTC - Universal Talkware Corporation 64.31.32.0/19 AS11955 SCRR-11955 - Road Runner HoldCo LLC 64.31.32.0/22 AS10796 SCRR-10796 - Road Runner HoldCo LLC 64.31.36.0/23 AS10796 SCRR-10796 - Road Runner HoldCo LLC 64.31.38.0/23 AS12262 RR-CINCINNATI-ASN-01 - Road Runner HoldCo LLC 64.31.40.0/23 AS12262 RR-CINCINNATI-ASN-01 - Road Runner HoldCo LLC 64.31.42.0/23 AS10796 SCRR-10796 - Road Runner HoldCo LLC 64.31.44.0/23 AS10796 SCRR-10796 - Road Runner HoldCo LLC 64.31.46.0/24 AS10796 SCRR-10796 - Road Runner HoldCo LLC 64.31.48.0/22 AS11060 NEO-RR-COM - Road Runner HoldCo LLC 64.31.53.0/24 AS10796 SCRR-10796 - Road Runner HoldCo LLC 64.31.55.0/24 AS10796 SCRR-10796 - Road Runner HoldCo LLC 64.31.59.0/24 AS7017 SCRR-7015 - Road Runner HoldCo LLC 64.31.60.0/24 AS7017 SCRR-7015 - Road Runner HoldCo LLC 64.64.159.0/24 AS32004 BIG-ASN - Business Information Group, Inc. 64.73.192.0/19 AS11247 IBSINC - Internet Business Services, Inc. 64.79.88.0/24 AS26096 LODDEN - Lodden Services 64.79.89.0/24 AS26096 LODDEN - Lodden Services 64.147.64.0/19 AS40156 THEOPT-HOU - The Optimal Link Corporation 64.186.0.0/19 AS6371 AMERICATEL - Americatel Corporation 64.186.6.0/24 AS6371 AMERICATEL - Americatel Corporation 66.11.32.0/20 AS6261 VISINET - Visionary Systems, Inc. 66.11.40.0/21 AS6261 VISINET - Visionary Systems, Inc. 66.54.91.0/24 AS30506 BLACKSUN-1 - Blacksun Technologies LLC 66.55.160.0/19 AS29994 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.206.32.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.33.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.34.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.35.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.40.0/22 AS174 COGENT Cogent/PSI 66.206.44.0/23 AS174 COGENT Cogent/PSI 66.206.47.0/24 AS17557 PKTELECOM-AS-AP Pakistan Telecom 66.207.32.0/20 AS23011 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 69.71.192.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 69.80.0.0/17 AS3043 AMPHIB-AS - Amphibian Media Corporation 80.88.0.0/21 AS33774 DJAWEB 80.88.8.0/22 AS33774 DJAWEB 80.88.10.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 95.215.184.0/22 AS39056 ANOXIN PB Anoxin 98.96.0.0/13 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 109.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 109.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 109.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 121.50.168.0/21 AS9931 CAT-AP The Communication Authoity of Thailand, CAT 122.128.120.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. 137.0.0.0/13 AS27064 DDN-ASNBLK1 - DoD Network Information Center 163.142.0.0/16 AS2500 WIDE-BB WIDE Project 172.7.0.0/24 AS28175 172.10.1.0/30 AS18305 POSNET POSDATA Co.,Ltd 178.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 178.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 178.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc 192.9.200.0/24 AS3602 AS3602-RTI - Rogers Telecom Inc. 192.64.85.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.107.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.108.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.177.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.70.164.0/24 AS25689 NRCNET-AS - National Research Council of Canada 192.96.37.0/24 AS10474 NETACTIVE 192.96.135.0/24 AS2018 TENET-1 192.96.136.0/23 AS2018 TENET-1 192.96.141.0/24 AS2018 TENET-1 192.96.143.0/24 AS2018 TENET-1 192.96.145.0/24 AS2018 TENET-1 192.96.177.0/24 AS6083 POSIX-AFRICA 192.101.45.0/24 AS2905 TICSA-ASN 192.101.46.0/24 AS6503 Avantel, S.A. 192.101.64.0/21 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.72.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.74.0/24 AS1239 SPRINTLINK - Sprint 192.124.248.0/23 AS680 DFN-IP service G-WiN 192.124.252.0/22 AS680 DFN-IP service G-WiN 192.131.233.0/24 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 192.133.6.0/24 AS10282 ORANGE-BUSINESS-SERVICES-CEEUR Orange Business Services (formerly Equant) AS for CEEUR 192.153.144.0/21 AS27064 DDN-ASNBLK1 - DoD Network Information Center 192.154.32.0/19 AS81 NCREN - MCNC 192.188.208.0/20 AS27064 DDN-ASNBLK1 - DoD Network Information Center 196.6.108.0/24 AS5713 SAIX-NET 196.10.119.0/24 AS2018 TENET-1 196.10.122.0/23 AS2018 TENET-1 196.10.251.0/24 AS2018 TENET-1 196.10.252.0/23 AS2018 TENET-1 196.10.254.0/24 AS2018 TENET-1 196.13.101.0/24 AS2018 TENET-1 196.13.102.0/23 AS2018 TENET-1 196.13.104.0/24 AS2018 TENET-1 196.13.121.0/24 AS2018 TENET-1 196.13.125.0/24 AS2018 TENET-1 196.13.126.0/24 AS2018 TENET-1 196.13.169.0/24 AS2018 TENET-1 196.13.174.0/23 AS2018 TENET-1 196.13.176.0/21 AS2018 TENET-1 196.13.192.0/22 AS2018 TENET-1 196.13.196.0/24 AS2018 TENET-1 196.32.96.0/20 AS6453 GLOBEINTERNET TATA Communications 196.202.224.0/21 AS8818 TELE Greenland Autonomous System 198.1.2.0/24 AS4761 INDOSAT-INP-AP INDOSAT Internet Network Provider 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc. 198.54.82.0/24 AS2018 TENET-1 198.54.92.0/24 AS2018 TENET-1 198.54.222.0/24 AS2018 TENET-1 198.97.72.0/21 AS27064 DDN-ASNBLK1 - DoD Network Information Center 198.97.96.0/19 AS27064 DDN-ASNBLK1 - DoD Network Information Center 198.97.240.0/20 AS27064 DDN-ASNBLK1 - DoD Network Information Center 198.161.87.0/24 AS6539 GT-BELL - Bell Canada 198.167.0.0/16 AS7456 INTERHOP - Interhop Network SERVICES Inc. 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 198.169.0.0/16 AS803 SASKTEL - Saskatchewan Telecommunications 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services 199.10.0.0/16 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.114.0.0/21 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.114.128.0/18 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.114.130.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.131.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.132.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.134.0/24 AS3541 ITSDN-U4 - DoD Network Information Center 199.114.136.0/24 AS27044 DDN-ASNBLK1 - DoD Network Information Center 199.114.138.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.140.0/24 AS3544 ITSDN-U7 - DoD Network Information Center 199.114.142.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.144.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.148.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.150.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.152.0/24 AS27033 DDN-ASNBLK1 - DoD Network Information Center 199.114.153.0/24 AS27034 DDN-ASNBLK1 - DoD Network Information Center 199.114.154.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.114.156.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.114.160.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.121.0.0/16 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.123.0.0/18 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.123.16.0/20 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.123.80.0/21 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.189.32.0/19 AS7332 IQUEST-AS - IQuest Internet 199.202.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.202.216.0/21 AS577 BACOM - Bell Canada 199.246.116.0/24 AS813 UUNET-CANADA - MCI Communications Services, Inc. d/b/a Verizon Business 202.6.176.0/20 AS24316 202.58.113.0/24 AS19161 INNOCOM-TELECOM - INNOCOM TELECOM 202.72.40.0/24 AS38205 202.72.41.0/24 AS38205 202.73.144.0/20 AS4788 TMNET-AS-AP TM Net, Internet Service Provider 202.80.192.0/20 AS2706 HKSUPER-HK-AP Pacific Internet (Hong Kong) Limited 202.86.252.0/22 AS4748 RESOLINK-AS-AP Resources Link Network Limited 202.86.252.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.253.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.254.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.255.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.94.70.0/24 AS9837 POWERTEL-AP Powertel Ltd 202.122.120.0/21 AS17494 BTTB-AS-AP Telecom Operator & Internet Service Provider as well 202.124.195.0/24 AS17557 PKTELECOM-AS-AP Pakistan Telecom 202.133.70.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.133.73.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.136.254.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.136.255.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.140.160.0/24 AS4841 202.140.161.0/24 AS4841 202.140.162.0/24 AS4841 202.140.163.0/24 AS4841 202.140.164.0/24 AS4841 202.140.165.0/24 AS4841 202.140.166.0/24 AS4841 202.140.167.0/24 AS4841 202.140.168.0/24 AS4841 202.140.169.0/24 AS4841 202.140.170.0/24 AS4841 202.140.171.0/24 AS4841 202.140.172.0/24 AS4841 202.140.173.0/24 AS4841 202.140.174.0/24 AS4841 202.140.175.0/24 AS4841 202.140.180.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.140.181.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.140.182.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.150.227.0/24 AS17727 NAPINFO-AS-AP PT. NAP Info Lintas Nusa 202.181.32.0/24 AS4645 ASN-HKNET-AP HKNet Co. Ltd 203.12.45.0/24 AS4854 NETSPACE-AS-AP Netspace Online Systems 203.62.0.0/17 AS7575 AARNET-AS-AP Australian Academic and Reasearch Network (AARNet) 203.78.48.0/20 AS9299 IPG-AS-AP Philippine Long Distance Telephone Company 203.89.139.0/24 AS17911 BRAINPK-AS-AP Brain Telecommunication Ltd. 203.111.192.0/20 AS7473 SINGTEL-AS-AP Singapore Telecommunications Ltd 203.112.111.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.113.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.114.0/24 AS4802 ASN-IINET iiNet Limited 203.112.116.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.117.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.118.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.119.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.120.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.121.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.127.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.128.128.0/19 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 203.128.128.0/24 AS23849 CNNIC-NET263-AP Beijing Capital-online science development Co.,Ltd. 203.152.154.0/23 AS9583 SIFY-AS-IN Sify Limited 204.9.216.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.9.217.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.9.218.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.13.140.0/22 AS7270 NET2PHONE - Net2Phone Corp. 204.16.120.0/23 AS12077 204.16.122.0/23 AS12077 204.19.14.0/23 AS577 BACOM - Bell Canada 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.189.134.0/24 AS11814 CYBERSURF - Cybersurf Inc. 205.210.145.0/24 AS11814 CYBERSURF - Cybersurf Inc. 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 207.174.0.0/16 AS13790 INTERNAP-BLK3 - Internap Network Services Corporation 207.174.130.0/24 AS13345 ROCKYNET-COM - Rockynet.com, Inc 207.174.131.0/24 AS30715 NETRACK - Netrack, Inc. 207.174.132.0/23 AS30715 NETRACK - Netrack, Inc. 207.174.137.0/24 AS13345 ROCKYNET-COM - Rockynet.com, Inc 207.174.138.0/23 AS13345 ROCKYNET-COM - Rockynet.com, Inc 207.174.140.0/22 AS13345 ROCKYNET-COM - Rockynet.com, Inc 207.174.151.0/24 AS11500 PEAKPEAK - Peak to Peak Internet 207.174.152.0/22 AS30715 NETRACK - Netrack, Inc. 207.174.157.0/24 AS13345 ROCKYNET-COM - Rockynet.com, Inc 207.174.158.0/24 AS11500 PEAKPEAK - Peak to Peak Internet 207.174.173.0/24 AS16618 AS-HFS-CAVION - Harland Financial Solutions, Inc. 207.174.175.0/24 AS13345 ROCKYNET-COM - Rockynet.com, Inc 207.174.177.0/24 AS11500 PEAKPEAK - Peak to Peak Internet 207.174.178.0/24 AS11500 PEAKPEAK - Peak to Peak Internet 207.174.182.0/24 AS29831 FONENET - FONE NET, LLC 207.174.188.0/22 AS30715 NETRACK - Netrack, Inc. 207.174.192.0/24 AS29831 FONENET - FONE NET, LLC 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.174.201.0/24 AS13345 ROCKYNET-COM - Rockynet.com, Inc 207.174.202.0/24 AS13345 ROCKYNET-COM - Rockynet.com, Inc 207.174.210.0/23 AS16618 AS-HFS-CAVION - Harland Financial Solutions, Inc. 207.174.211.0/24 AS16618 AS-HFS-CAVION - Harland Financial Solutions, Inc. 207.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 207.204.168.0/24 AS15150 BELLTECH-AS - BELLWETHER TECHNOLOGY CORPORATION 207.204.222.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 209.54.93.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 209.54.111.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 209.54.123.0/24 AS6062 NETPLEX - NETPLEX 209.54.240.0/21 AS10887 BPSI-AS - BPSI Internet Services 209.74.96.0/19 AS10912 INTERNAP-BLK - Internap Network Services Corporation 209.140.90.0/24 AS14461 NTSL - NET SOLUTIONS 209.140.224.0/21 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.234.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.235.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.236.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.237.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.238.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.239.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.141.16.0/21 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.141.48.0/22 AS14461 NTSL - NET SOLUTIONS 209.145.192.0/18 AS3043 AMPHIB-AS - Amphibian Media Corporation 209.222.5.0/24 AS26699 PSI-CT - Printing For Systems Inc 209.222.6.0/24 AS26699 PSI-CT - Printing For Systems Inc 209.236.64.0/19 AS7911 LVLT-7911 - Level 3 Communications, Inc. 209.236.96.0/19 AS7911 LVLT-7911 - Level 3 Communications, Inc. 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 216.37.114.0/23 AS3549 GBLX Global Crossing Ltd. 216.37.120.0/23 AS13377 216.99.16.0/24 AS6395 LVLT-6395 - Level 3 Communications, Inc. 216.99.20.0/24 AS6395 LVLT-6395 - Level 3 Communications, Inc. 216.172.198.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.172.199.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.210.86.0/24 AS577 BACOM - Bell Canada 216.240.240.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.240.241.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.240.242.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.251.207.0/24 AS1239 SPRINTLINK - Sprint 217.78.71.0/24 AS12491 IPPLANET-AS IPPlanet 217.78.72.0/24 AS12491 IPPLANET-AS IPPlanet 217.78.73.0/24 AS12491 IPPLANET-AS IPPlanet Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From heather.schiller at verizonbusiness.com Fri Mar 20 11:50:26 2009 From: heather.schiller at verizonbusiness.com (Heather Schiller) Date: Fri, 20 Mar 2009 12:50:26 -0400 Subject: Redundant AS's In-Reply-To: References: <5.1.0.14.2.20090318095944.04fdb070@efes.iucc.ac.il> <5021774B-6774-4DF9-8864-DC45A184BCAA@eyeconomics.com> <5021774B-6774-4DF9-8864-DC45A184BCAA@eyeconomics.com> <5.1.0.14.2.20090318095944.04fdb070@efes.iucc.ac.il> <5.1.0.14.2.20090319074418.00aca8c8@efes.iucc.ac.il> <878wn060t6.fsf@mid.deneb.enyo.de> Message-ID: <49C3C952.4050808@verizonbusiness.com> Hank Nussbacher wrote: > On Fri, 20 Mar 2009, Florian Weimer wrote: > >> * Hank Nussbacher: >> >>> It takes me about 3-5 hours of work to track down and get an old >>> unused ASN to be deallocated. How about updating the 2010 charging >>> model so that LIRs that return ASNs are compensated? >> >> I don't think this is a good way of using RIR funds. Why should the >> old guys receive even more special treatment? RIPE's charging scheme >> already discriminates heavily against newcomers. > > I disagree. > > Older LIRs have more allocations which compensates for the time factor > of the algorithm. Older allocations need almost no human handling by > the RIR vs a new LIR of a year which has a oodles of tickets that need > human intervention. > > -Hank > > I don't think old vs new really matters.. pardon me for sticking w/ ARIN in this example.. I can follow their fee structure easiest - and doesn't have the old vs new: (https://www.arin.net/fees/fee_schedule.html) ARIN charges $100/yr for ASN's ... any "compensation" for returning an ASN should be less than the $100 they charge? Would it make any financial sense to compensate someone $500 for returning an ASN that only generates $100 a year? (Remember that the RIR's are non-profits..) I tend to agree w/ Randy.. it's time and money better spent focusing our efforts on supporting 4byte ASN (and v6 for that matter) Attempts at recovering 2byte ASN's (and v4 space..) are short term solutions, at best extend the 'free pool' for a short and unpredictable period of time, while incurring more headache, expense, and arguing, than working toward supporting the inevitable. --h From herrin-nanog at dirtside.com Fri Mar 20 12:58:03 2009 From: herrin-nanog at dirtside.com (William Herrin) Date: Fri, 20 Mar 2009 13:58:03 -0400 Subject: Redundant AS's In-Reply-To: References: <5021774B-6774-4DF9-8864-DC45A184BCAA@eyeconomics.com> <49C0A063.8080607@ripe.net> Message-ID: <3c3e3fca0903201058o2eebbca3q83b300dfdf058afe@mail.gmail.com> On Wed, Mar 18, 2009 at 9:44 AM, Randy Bush wrote: >> Why not go after low lying fruit first? ?If an ASN was assigned years >> ago and hasn't appeared in the RIB for the past year that ASN should >> be reclaimed. ?Send warning emails to the registered contacts as well >> as to the assigning LIR and after 3 months - just reclaim it. > > because property is unused publicly does not affect the rights of its > owner(s). ?otherwise old car collector wannabes could have a heyday. Randy, A. AS numbers are not property. B. If they were property (and they're not), then at least in NANOG's region there are adequate laws regarding escheat of unclaimed property. I interpret this to be what Hank was going for: attempt to contact anyone with a registered but apparently unused AS number and "escheat" the ones that go unclaimed back to the registries. Whether or not this is a worthwhile activity is an entirely different question for which I intentionally decline to offer an opinion. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From cscora at apnic.net Fri Mar 20 13:12:54 2009 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 21 Mar 2009 04:12:54 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <200903201812.n2KICs8g019849@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 21 Mar, 2009 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 283363 Prefixes after maximum aggregation: 134180 Deaggregation factor: 2.11 Unique aggregates announced to Internet: 138749 Total ASes present in the Internet Routing Table: 30859 Prefixes per ASN: 9.18 Origin-only ASes present in the Internet Routing Table: 26860 Origin ASes announcing only one prefix: 13062 Transit ASes present in the Internet Routing Table: 3999 Transit-only ASes present in the Internet Routing Table: 90 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 25 Max AS path prepend of ASN (18678) 21 Prefixes from unregistered ASNs in the Routing Table: 498 Unregistered ASNs in the Routing Table: 166 Number of 32-bit ASNs allocated by the RIRs: 132 Prefixes from 32-bit ASNs in the Routing Table: 19 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 238 Number of addresses announced to Internet: 2017104896 Equivalent to 120 /8s, 58 /16s and 148 /24s Percentage of available address space announced: 54.4 Percentage of allocated address space announced: 63.6 Percentage of available address space allocated: 85.5 Percentage of address space in use by end-sites: 76.0 Total number of prefixes smaller than registry allocations: 139447 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 65453 Total APNIC prefixes after maximum aggregation: 23417 APNIC Deaggregation factor: 2.80 Prefixes being announced from the APNIC address blocks: 62300 Unique aggregates announced from the APNIC address blocks: 28437 APNIC Region origin ASes present in the Internet Routing Table: 3576 APNIC Prefixes per ASN: 17.42 APNIC Region origin ASes announcing only one prefix: 963 APNIC Region transit ASes present in the Internet Routing Table: 552 Average APNIC Region AS path length visible: 3.5 Max APNIC Region AS path length visible: 19 Number of APNIC addresses announced to Internet: 405339808 Equivalent to 24 /8s, 40 /16s and 254 /24s Percentage of available APNIC address space announced: 80.5 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 APNIC Address Blocks 58/8, 59/8, 60/8, 61/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 124216 Total ARIN prefixes after maximum aggregation: 65427 ARIN Deaggregation factor: 1.90 Prefixes being announced from the ARIN address blocks: 93638 Unique aggregates announced from the ARIN address blocks: 36241 ARIN Region origin ASes present in the Internet Routing Table: 12858 ARIN Prefixes per ASN: 7.28 ARIN Region origin ASes announcing only one prefix: 4944 ARIN Region transit ASes present in the Internet Routing Table: 1242 Average ARIN Region AS path length visible: 3.3 Max ARIN Region AS path length visible: 20 Number of ARIN addresses announced to Internet: 419705152 Equivalent to 25 /8s, 4 /16s and 49 /24s Percentage of available ARIN address space announced: 80.7 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 ARIN Address Blocks 24/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 108/8, 173/8, 174/8, 184/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 64872 Total RIPE prefixes after maximum aggregation: 37755 RIPE Deaggregation factor: 1.72 Prefixes being announced from the RIPE address blocks: 59455 Unique aggregates announced from the RIPE address blocks: 39555 RIPE Region origin ASes present in the Internet Routing Table: 12812 RIPE Prefixes per ASN: 4.64 RIPE Region origin ASes announcing only one prefix: 6725 RIPE Region transit ASes present in the Internet Routing Table: 1924 Average RIPE Region AS path length visible: 4.0 Max RIPE Region AS path length visible: 23 Number of RIPE addresses announced to Internet: 391469984 Equivalent to 23 /8s, 85 /16s and 91 /24s Percentage of available RIPE address space announced: 83.3 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223 RIPE Address Blocks 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 178/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 23523 Total LACNIC prefixes after maximum aggregation: 5813 LACNIC Deaggregation factor: 4.05 Prefixes being announced from the LACNIC address blocks: 21691 Unique aggregates announced from the LACNIC address blocks: 11409 LACNIC Region origin ASes present in the Internet Routing Table: 1082 LACNIC Prefixes per ASN: 20.05 LACNIC Region origin ASes announcing only one prefix: 343 LACNIC Region transit ASes present in the Internet Routing Table: 179 Average LACNIC Region AS path length visible: 4.0 Max LACNIC Region AS path length visible: 25 Number of LACNIC addresses announced to Internet: 61525504 Equivalent to 3 /8s, 170 /16s and 206 /24s Percentage of available LACNIC address space announced: 61.1 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247 plus ERX transfers LACNIC Address Blocks 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 4836 Total AfriNIC prefixes after maximum aggregation: 1392 AfriNIC Deaggregation factor: 3.47 Prefixes being announced from the AfriNIC address blocks: 4536 Unique aggregates announced from the AfriNIC address blocks: 1343 AfriNIC Region origin ASes present in the Internet Routing Table: 288 AfriNIC Prefixes per ASN: 15.75 AfriNIC Region origin ASes announcing only one prefix: 87 AfriNIC Region transit ASes present in the Internet Routing Table: 55 Average AfriNIC Region AS path length visible: 3.9 Max AfriNIC Region AS path length visible: 15 Number of AfriNIC addresses announced to Internet: 10131968 Equivalent to 0 /8s, 154 /16s and 154 /24s Percentage of available AfriNIC address space announced: 30.2 AfriNIC AS Blocks 36864-37887 & ERX transfers AfriNIC Address Blocks 41/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 1691 6930 393 Korea Telecom (KIX) 17488 1527 119 98 Hathway IP Over Cable Interne 4755 1218 431 179 TATA Communications formerly 9583 1093 86 531 Sify Limited 4134 925 16263 365 CHINANET-BACKBONE 7545 765 159 104 TPG Internet Pty Ltd 18101 755 206 31 Reliance Infocom Ltd Internet 9498 692 296 50 BHARTI BT INTERNET LTD. 24560 678 228 175 Bharti Airtel Ltd. 9829 637 490 21 BSNL National Internet Backbo Complete listing at http://thyme.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 4324 3672 329 bellsouth.net, inc. 209 2908 4149 634 Qwest 4323 1801 1049 372 Time Warner Telecom 1785 1732 717 139 PaeTec Communications, Inc. 20115 1593 1431 720 Charter Communications 7018 1445 5896 1019 AT&T WorldNet Services 6478 1295 297 530 AT&T Worldnet Services 2386 1263 681 902 AT&T Data Communications Serv 11492 1194 192 12 Cable One 3356 1174 10976 444 Level 3 Communications, LLC Complete listing at http://thyme.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8452 1250 188 7 TEDATA 3292 444 1762 389 TDC Tele Danmark 30890 441 87 196 SC Kappa Invexim SRL 12479 404 578 6 Uni2 Autonomous System 3320 353 7081 296 Deutsche Telekom AG 3301 344 1686 309 TeliaNet Sweden 8866 337 109 22 Bulgarian Telecommunication C 3215 336 2985 109 France Telecom Transpac 29049 321 26 3 AzerSat LLC. 8551 313 288 40 Bezeq International Complete listing at http://thyme.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 1444 2832 234 UniNet S.A. de C.V. 10620 845 191 80 TVCABLE BOGOTA 22047 606 302 14 VTR PUNTO NET S.A. 7303 520 260 80 Telecom Argentina Stet-France 11830 520 294 42 Instituto Costarricense de El 16814 491 31 10 NSS, S.A. 6471 441 95 32 ENTEL CHILE S.A. 11172 406 102 72 Servicios Alestra S.A de C.V 7738 397 794 28 Telecomunicacoes da Bahia S.A 28573 385 518 25 NET Servicos de Comunicao S.A Complete listing at http://thyme.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 829 74 30 LINKdotNET AS number 20858 292 34 3 This AS will be used to conne 3741 272 858 232 The Internet Solution 2018 241 215 141 Tertiary Education Network 6713 159 150 15 Itissalat Al-MAGHRIB 33783 150 10 8 EEPAD TISP TELECOM & INTERNET 29571 132 15 8 Ci Telecom Autonomous system 5536 123 8 9 Internet Egypt Network 5713 115 507 65 Telkom SA Ltd 33776 112 6 6 Starcomms Nigeria Limited Complete listing at http://thyme.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 4324 3672 329 bellsouth.net, inc. 209 2908 4149 634 Qwest 4323 1801 1049 372 Time Warner Telecom 1785 1732 717 139 PaeTec Communications, Inc. 4766 1691 6930 393 Korea Telecom (KIX) 20115 1593 1431 720 Charter Communications 17488 1527 119 98 Hathway IP Over Cable Interne 7018 1445 5896 1019 AT&T WorldNet Services 8151 1444 2832 234 UniNet S.A. de C.V. 6478 1295 297 530 AT&T Worldnet Services Complete listing at http://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 209 2908 2274 Qwest 1785 1732 1593 PaeTec Communications, Inc. 4323 1801 1429 Time Warner Telecom 17488 1527 1429 Hathway IP Over Cable Interne 4766 1691 1298 Korea Telecom (KIX) 8452 1250 1243 TEDATA 8151 1444 1210 UniNet S.A. de C.V. 11492 1194 1182 Cable One 18566 1061 1051 Covad Communications 4755 1218 1039 TATA Communications formerly Complete listing at http://thyme.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 16927 UNALLOCATED 12.0.252.0/23 7018 AT&T WorldNet Servic 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 7018 AT&T WorldNet Servic 13746 UNALLOCATED 12.24.56.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.25.107.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.152.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.154.0/23 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.159.0/24 7018 AT&T WorldNet Servic 32326 UNALLOCATED 12.40.49.0/24 7018 AT&T WorldNet Servic 25639 UNALLOCATED 12.41.169.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 24.75.116.0/22 10796 ServiceCo LLC - Road Runner 24.246.0.0/17 7018 AT&T WorldNet Services 24.246.128.0/18 7018 AT&T WorldNet Services 41.220.16.0/20 8668 TelOne Zimbabwe P/L 41.223.112.0/22 5713 Telkom SA Ltd 41.223.188.0/24 22351 Intelsat 41.223.189.0/24 26452 Local Communications Networks 62.61.220.0/24 24974 Tachyon Europe BV - Wireless 62.61.221.0/24 24974 Tachyon Europe BV - Wireless 63.140.213.0/24 22555 Universal Talkware Corporatio Complete listing at http://thyme.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:19 /9:10 /10:20 /11:55 /12:163 /13:320 /14:580 /15:1134 /16:10384 /17:4638 /18:7988 /19:17022 /20:20163 /21:19860 /22:25312 /23:25214 /24:148254 /25:697 /26:861 /27:545 /28:106 /29:8 /30:3 /31:0 /32:7 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2806 4324 bellsouth.net, inc. 209 1615 2908 Qwest 4766 1395 1691 Korea Telecom (KIX) 17488 1297 1527 Hathway IP Over Cable Interne 8452 1229 1250 TEDATA 11492 1149 1194 Cable One 1785 1140 1732 PaeTec Communications, Inc. 18566 1042 1061 Covad Communications 2386 964 1263 AT&T Data Communications Serv 9583 945 1093 Sify Limited Complete listing at http://thyme.apnic.net/current/data/sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 4:13 8:172 12:2195 13:3 15:19 16:3 17:4 20:35 24:1115 32:51 38:551 40:97 41:2009 43:1 44:2 47:21 52:3 55:2 56:3 57:25 58:536 59:624 60:460 61:1107 62:1121 63:2011 64:3549 65:2421 66:3562 67:1493 68:677 69:2509 70:509 71:164 72:1665 73:2 74:1439 75:205 76:313 77:833 78:544 79:304 80:958 81:824 82:560 83:411 84:596 85:1019 86:397 87:632 88:352 89:1491 90:45 91:2064 92:276 93:1110 94:1202 95:829 96:104 97:190 98:238 99:17 109:1 110:7 112:87 113:89 114:221 115:234 116:1128 117:477 118:289 119:656 120:138 121:708 122:981 123:564 124:958 125:1291 128:220 129:225 130:130 131:413 132:74 133:9 134:188 135:39 136:223 137:144 138:146 139:78 140:416 141:104 142:393 143:326 144:325 145:41 146:374 147:149 148:513 149:237 150:147 151:206 152:151 153:135 154:11 155:266 156:167 157:297 158:132 159:266 160:281 161:137 162:270 163:148 164:479 165:516 166:277 167:361 168:682 169:163 170:472 171:39 172:10 173:246 174:161 178:1 186:6 187:44 188:8 189:310 190:2709 192:5807 193:4216 194:3329 195:2658 196:1067 198:3729 199:3314 200:5500 201:1360 202:7865 203:8051 204:3783 205:2162 206:2359 207:2805 208:3880 209:3446 210:2635 211:1114 212:1493 213:1692 214:68 215:25 216:4527 217:1263 218:371 219:418 220:1216 221:459 222:261 End of report From james.cutler at consultant.com Fri Mar 20 13:33:23 2009 From: james.cutler at consultant.com (James R. Cutler) Date: Fri, 20 Mar 2009 14:33:23 -0400 Subject: Redundant AS's In-Reply-To: <49C3C952.4050808@verizonbusiness.com> References: <5.1.0.14.2.20090318095944.04fdb070@efes.iucc.ac.il> <5021774B-6774-4DF9-8864-DC45A184BCAA@eyeconomics.com> <5021774B-6774-4DF9-8864-DC45A184BCAA@eyeconomics.com> <5.1.0.14.2.20090318095944.04fdb070@efes.iucc.ac.il> <5.1.0.14.2.20090319074418.00aca8c8@efes.iucc.ac.il> <878wn060t6.fsf@mid.deneb.enyo.de> <49C3C952.4050808@verizonbusiness.com> Message-ID: <96A7B27A-7E8A-4FE5-8654-3AE39A0B3F14@consultant.com> What this quote means is that it is 65536 times more cost-effective to deploy 4 byte ASN than to mess with legacy assignments. On Mar 20, 2009, at 12:50 PM, Heather Schiller wrote: > I tend to agree w/ Randy.. it's time and money better spent focusing > our efforts on supporting 4byte ASN (and v6 for that matter) > Attempts at recovering 2byte ASN's (and v4 space..) are short term > solutions, at best extend the 'free pool' for a short and > unpredictable period of time, while incurring more headache, > expense, and arguing, than working toward supporting the inevitable. James R. Cutler james.cutler at consultant.com From gih at apnic.net Fri Mar 20 21:46:19 2009 From: gih at apnic.net (Geoff Huston) Date: Sat, 21 Mar 2009 13:46:19 +1100 Subject: Redundant AS's In-Reply-To: <49C0A063.8080607@ripe.net> References: <5021774B-6774-4DF9-8864-DC45A184BCAA@eyeconomics.com> <49C0A063.8080607@ripe.net> Message-ID: <1A35716A-6BFB-41E5-B162-7425A1E2AEF0@apnic.net> On 18/03/2009, at 6:18 PM, Henk Uijterwaal wrote: >> > > When I look at this more recently, the conclusion still seems to be > valid: we'll run out of 16 bit ASN's somewhere in 2011 to 2013. There > are a lot of unused ASN's out there. I make it 25 June 2011 given current use patterns (http://www.potaroo.net/tools/asn16/ ) > Recovering them will postpone the > problem by a few years but it won't solve it. The basic problem with > recovery is how to decide if an ASN is really no longer used/needed. > There is (still) no mechanism to do this. thats the problem - there are current 14902 AS numbers that allocated but not visible in my part of the public Internet, but its entirely inknown to what extent these numbers are used in various forms of private or semi-private contests Geoff From jlewis at packetnexus.com Fri Mar 20 21:48:44 2009 From: jlewis at packetnexus.com (Jason Lewis) Date: Fri, 20 Mar 2009 22:48:44 -0400 Subject: AS path weirdness Message-ID: <49C4558C.8050306@packetnexus.com> I'm seeing the following in the MRT data from RRC04 at ripe. http://www.ripe.net/projects/ris/rawdata.html http://data.ris.ripe.net/rrc04/2009.03/bview.20090320.2359.gz for reference. I'm not entirely sure what I'm looking at. The reserved AS, 65490 appears in parentheses and I've never seen that in MRT formatted data and not sure why it's happening. I'm also not clear on why I see 23456 *and* a 32 bit AS in the path. Is anyone else seeing this or is it something wacky at RRC04? 91.201.176.0/22|29222 6830 (65490) 3356 21219 3.30 91.207.218.0/23|29222 6830 (65490) 3356 35320 3.21 23456 195.88.52.0/23|29222 6830 (65490) 3356 13249 28761 3.57 95.128.230.0/24|29222 6830 (65490) 2914 35320 3.21 23456 35748 195.128.231.0/24|29222 6830 (65490) 2914 35320 3.21 23456 35748 jas From pfunix at gmail.com Sat Mar 21 01:12:13 2009 From: pfunix at gmail.com (Beavis) Date: Sat, 21 Mar 2009 00:12:13 -0600 Subject: REVERSE DNS Practices. Message-ID: hi, I want to ask some folks out there that maintain reverse DNS queries of their respective IP blocks. I want to know if there is a need for me to contact my upstream provider. I am in charge of 2 /24's under LACNIC. I've already registered my DNS servers on LACNIC. but for some weird reason it's not owning reverse resolves. any tips would be gladly appreciated. thanks, b -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments From jtrooney at nexdlevel.com Sat Mar 21 01:31:17 2009 From: jtrooney at nexdlevel.com (Jeff Rooney) Date: Sat, 21 Mar 2009 01:31:17 -0500 Subject: Savvis Outage? Message-ID: Anyone else seeing an outage with Savvis in the Chicago area? Specifically in their colo we are seeing asynchronous connectivity, traffic is coming in, but not getting back out. Jeff Rooney jtrooney at nexdlevel.com From johnl at iecc.com Sat Mar 21 05:32:30 2009 From: johnl at iecc.com (John Levine) Date: 21 Mar 2009 10:32:30 -0000 Subject: REVERSE DNS Practices. In-Reply-To: Message-ID: <20090321103230.24415.qmail@simone.iecc.com> > I want to ask some folks out there that maintain reverse DNS queries >of their respective IP blocks. I want to know if there is a need for >me to contact my upstream provider. I am in charge of 2 /24's under >LACNIC. I've already registered my DNS servers on LACNIC. but for some >weird reason it's not owning reverse resolves. any tips would be >gladly appreciated. The RIRs don't maintain rDNS for you. You'll have to trace the delegations downward from in-addr.arpa, find out who's handling your /24's, and contact them to get them to delegate your chunks to you. R's, John From bruce at yoafrica.com Sat Mar 21 05:38:55 2009 From: bruce at yoafrica.com (bruce at yoafrica.com) Date: Sat, 21 Mar 2009 13:38:55 +0300 Subject: REVERSE DNS Practices. In-Reply-To: <20090321103230.24415.qmail@simone.iecc.com> References: <20090321103230.24415.qmail@simone.iecc.com> Message-ID: <7c9a4be6ad650d86a4884a739cb2ada9@imap.yoafrica.com> Slighty related... Can people please post their recommended reverse dns naming conventions for a small ISP with growth and scalability in mind. I already have one drawn up, but I would like to contrast and compare :D Thanks On 21 Mar 2009 10:32:30 -0000, John Levine wrote: >> I want to ask some folks out there that maintain reverse DNS queries >>of their respective IP blocks. I want to know if there is a need for >>me to contact my upstream provider. I am in charge of 2 /24's under >>LACNIC. I've already registered my DNS servers on LACNIC. but for some >>weird reason it's not owning reverse resolves. any tips would be >>gladly appreciated. > > The RIRs don't maintain rDNS for you. You'll have to trace the > delegations downward from in-addr.arpa, find out who's handling your > /24's, and contact them to get them to delegate your chunks to you. > > R's, > John From dtzgathum at gmail.com Sat Mar 21 06:45:12 2009 From: dtzgathum at gmail.com (david gathu) Date: Sat, 21 Mar 2009 06:45:12 -0500 Subject: hi Message-ID: <87f158410903210445s7f1efa57y2bf09c7fbadc29f6@mail.gmail.com> i am getting one volume of the list thats vol 14.i sure bet i am missing some vol's. can you give me a hand on this anyone -- regards DAVID From mike at steadfast.net Sat Mar 21 07:16:33 2009 From: mike at steadfast.net (Mike Bailey) Date: Sat, 21 Mar 2009 07:16:33 -0500 Subject: NANOG Digest, Vol 14, Issue 44 In-Reply-To: References: Message-ID: <49C4DAA1.2010207@steadfast.net> nanog-request at nanog.org wrote: > hi, > > I want to ask some folks out there that maintain reverse DNS queries > of their respective IP blocks. I want to know if there is a need for > me to contact my upstream provider. I am in charge of 2 /24's under > LACNIC. I've already registered my DNS servers on LACNIC. but for some > weird reason it's not owning reverse resolves. any tips would be > gladly appreciated. > > > thanks, > b > > You can use the dig utility that usually comes with bind to trace the NS records for the ip block down, just run: # dig 255.254.253.252.in-addr.arpa @a.root-servers.net NS +trace That will tell you what nameserver is directing you where. You can also use this web-based utility to query the root nameservers to figure out where your queries are being directed to: http://www.squish.net/dnscheck . Just make sure you are entering your ip in the reverse-dns, *.in-addr.arpa format, and not the actual ip address. > > Slighty related... > > > > Can people please post their recommended reverse dns naming > conventions for a small ISP with growth and scalability in mind. > > I already have one drawn up, but I would like to contrast and compare :D > > > > Thanks ip4.1-2-3.static.ourdomain.net From bmanning at vacation.karoshi.com Sat Mar 21 08:00:55 2009 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Sat, 21 Mar 2009 13:00:55 +0000 Subject: REVERSE DNS Practices. In-Reply-To: <7c9a4be6ad650d86a4884a739cb2ada9@imap.yoafrica.com> References: <20090321103230.24415.qmail@simone.iecc.com> <7c9a4be6ad650d86a4884a739cb2ada9@imap.yoafrica.com> Message-ID: <20090321130055.GA5782@vacation.karoshi.com.> the 20th or 21st century answer? if you really don't care about the actual node, then you should map the numbers to topologically significant names - after all, the reverse map follows topology, not some goofball - layer 9 - ego trip thing. or - the more modern approach is to let the node (w/ proper authorization) do a secure dynamic update of the revserse map - so the forward and reverse delegations match. ... a -VERY- useful technique. --bill On Sat, Mar 21, 2009 at 01:38:55PM +0300, bruce at yoafrica.com wrote: > Slighty related... > > Can people please post their recommended reverse dns naming conventions for a small ISP with growth and scalability in mind. > I already have one drawn up, but I would like to contrast and compare :D > > Thanks > > On 21 Mar 2009 10:32:30 -0000, John Levine wrote: > >> I want to ask some folks out there that maintain reverse DNS queries > >>of their respective IP blocks. I want to know if there is a need for > >>me to contact my upstream provider. I am in charge of 2 /24's under > >>LACNIC. I've already registered my DNS servers on LACNIC. but for some > >>weird reason it's not owning reverse resolves. any tips would be > >>gladly appreciated. > > > > The RIRs don't maintain rDNS for you. You'll have to trace the > > delegations downward from in-addr.arpa, find out who's handling your > > /24's, and contact them to get them to delegate your chunks to you. > > > > R's, > > John > From fw at deneb.enyo.de Sat Mar 21 08:53:45 2009 From: fw at deneb.enyo.de (Florian Weimer) Date: Sat, 21 Mar 2009 14:53:45 +0100 Subject: Redundant AS's In-Reply-To: (Hank Nussbacher's message of "Fri, 20 Mar 2009 12:40:15 +0200 (IST)") References: <5.1.0.14.2.20090318095944.04fdb070@efes.iucc.ac.il> <5021774B-6774-4DF9-8864-DC45A184BCAA@eyeconomics.com> <5021774B-6774-4DF9-8864-DC45A184BCAA@eyeconomics.com> <5.1.0.14.2.20090318095944.04fdb070@efes.iucc.ac.il> <5.1.0.14.2.20090319074418.00aca8c8@efes.iucc.ac.il> <878wn060t6.fsf@mid.deneb.enyo.de> Message-ID: <87iqm3kmmu.fsf@mid.deneb.enyo.de> * Hank Nussbacher: > Older LIRs have more allocations which compensates for the time > factor of the algorithm. Older allocations need almost no human > handling by the RIR vs a new LIR of a year which has a oodles of > tickets that need human intervention. And how much of that is the result of not returning old resources to the RIR? My own experience as an end user is not that good: After insisting repeatedly, only one of the LIRs we contacted eventually removed our historic PA assignment from the RIPE database (years after the last contract ended). It's just a tiny amount of resources which was involved, but I guess even those sum up in the end. Presumably, the current environment encourages LIRs to treat this as some sort of inner reserve. And as long as the LIR's resource requirements are not stagnant, this isn't even a significant problem from a global perspective. From j at arpa.com Sat Mar 21 10:15:50 2009 From: j at arpa.com (jamie rishaw) Date: Sat, 21 Mar 2009 10:15:50 -0500 Subject: REVERSE DNS Practices. In-Reply-To: <20090321130055.GA5782@vacation.karoshi.com.> References: <20090321103230.24415.qmail@simone.iecc.com> <7c9a4be6ad650d86a4884a739cb2ada9@imap.yoafrica.com> <20090321130055.GA5782@vacation.karoshi.com.> Message-ID: On Sat, Mar 21, 2009 at 8:00 AM, wrote: > the 20th or 21st century answer? > if you really don't care about the actual node, then you should map the > numbers to topologically significant names - after all, the reverse map > follows topology, not some goofball - layer 9 - ego trip thing. >>> For routing / backbone devices/interfaces/loopbacks, absolutely. <<< There are security implications [sort of] with being verbose about infrastructure naming, but obscurity in DNS never stopped a crawler from walking the ipv4 space looking for vulnerabilities... I'm going to guess tho that your question pertains to user ips. >>> For end-user (dsl/dial/cable/eyeball) ips on a small or large scale, simpler is better. <<< There's no need to put "-slip" or 'ppp' or isdn or dial or poolXXX or city names in an in-addr. Nobody needs to know, nobody will probably care, and eventually, it'll change somehow. There is a quite elegant, database-friendly, probably-easy-to-generate/code sans textfiles method - a rather clever nomenclature for its insanely ginormous [yes, thats the technical term] user ip pools. AOL uses it in their user pools. * each octet is converted to a to byte hex value, and concatenated. example: 172.137.220.58 = AC89DC3A.ipt.aol.com. o It's short, simple, and not geographically tying or revealing (your noc should know where your dial blocks sit) ;) etc etc. o Being hex, It's also not language-specific .. o Win factor? With a different SLD or subdomain (e.g. /ipt/.aol.com) , queries can be offloaded to less critical nameservers The problem eventually, as bill hints to, is that hostnames (esp. in-addr) *will* change. A certain phone co out here (cant tell you their name, but their initials are sbc) is annoyingly famous for this. Tens of thousands of in-addrs resolve to hostnames with locations in other states, other time zones, because, pools get shuffled around.. and really, nobody likes to sit and manage DNS all day. Even noc monkies. Using the hex method solves this. > or - the more modern approach is to let the node (w/ proper authorization) do a secure dynamic update of the revserse map - so the forward and reverse delegations match. ... a -VERY- useful technique. Lots of administration in this one, too, tho.. keys, manual definitions .. i suppose it could be automated, but you still have client configs, interoperability issues, and worst case / improperly configured dns update controls, namespace collisions. A lot of this of course is about context. What are the IPs purposed to? Infrastructure? Users? Everyone's mileage will vary, but, I've yet to come across any serious issues with dotted quads to hex... -jamie On Sat, Mar 21, 2009 at 01:38:55PM +0300, bruce at yoafrica.com wrote: > Slighty related... > > Can people please post their recommended reverse dns naming conventions for a small ISP with growth and scalability in mind. > I already have one drawn up, but I would like to contrast and compare :D > > Thanks > > On 21 Mar 2009 10:32:30 -0000, John Levine wrote: > >> I want to ask some folks out there that maintain reverse DNS queries > >>of their respective IP blocks. I want to know if there is a need for > >>me to contact my upstream provider. I am in charge of 2 /24's under > >>LACNIC. I've already registered my DNS servers on LACNIC. but for some > >>weird reason it's not owning reverse resolves. any tips would be > >>gladly appreciated. > > > > The RIRs don't maintain rDNS for you. You'll have to trace the > > delegations downward from in-addr.arpa, find out who's handling your > > /24's, and contact them to get them to delegate your chunks to you. > > > > R's, > > John > -- Jamie Rishaw // .com.arpa at j <- reverse it. ish. [Impressive C-level Title Here], arpa / arpa labs From randy at psg.com Sat Mar 21 10:44:23 2009 From: randy at psg.com (Randy Bush) Date: Sat, 21 Mar 2009 08:44:23 -0700 Subject: Redundant AS's In-Reply-To: <878wn060t6.fsf@mid.deneb.enyo.de> References: <5.1.0.14.2.20090318095944.04fdb070@efes.iucc.ac.il> <5021774B-6774-4DF9-8864-DC45A184BCAA@eyeconomics.com> <5.1.0.14.2.20090319074418.00aca8c8@efes.iucc.ac.il> <878wn060t6.fsf@mid.deneb.enyo.de> Message-ID: >> It takes me about 3-5 hours of work to track down and get an old >> unused ASN to be deallocated. How about updating the 2010 charging >> model so that LIRs that return ASNs are compensated? > > I don't think this is a good way of using RIR funds. Why should the > old guys receive even more special treatment? RIPE's charging scheme > already discriminates heavily against newcomers. beancounters know how cut expenses, not how to increase sales. thus, they (though well-meaning) shrink the company and eventually drive it into the ground. the real path is to move forward, increase income, and grow. perhaps there is a lesson here. move on to 4-byte asns. randy From fw at deneb.enyo.de Sat Mar 21 11:12:41 2009 From: fw at deneb.enyo.de (Florian Weimer) Date: Sat, 21 Mar 2009 17:12:41 +0100 Subject: Redundant AS's In-Reply-To: (Randy Bush's message of "Sat, 21 Mar 2009 08:44:23 -0700") References: <5.1.0.14.2.20090318095944.04fdb070@efes.iucc.ac.il> <5021774B-6774-4DF9-8864-DC45A184BCAA@eyeconomics.com> <5.1.0.14.2.20090319074418.00aca8c8@efes.iucc.ac.il> <878wn060t6.fsf@mid.deneb.enyo.de> Message-ID: <87r60qg8hy.fsf@mid.deneb.enyo.de> * Randy Bush: > the real path is to move forward, increase income, and grow. Sure. I was enlightened when someone posted to a RIPE mailing list, "we are heading towards a future where address space is scarce" (my words, not his). But the exact opposite is true. From bmanning at vacation.karoshi.com Sat Mar 21 11:36:31 2009 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Sat, 21 Mar 2009 16:36:31 +0000 Subject: Redundant AS's In-Reply-To: References: <5.1.0.14.2.20090318095944.04fdb070@efes.iucc.ac.il> <5021774B-6774-4DF9-8864-DC45A184BCAA@eyeconomics.com> <5.1.0.14.2.20090319074418.00aca8c8@efes.iucc.ac.il> <878wn060t6.fsf@mid.deneb.enyo.de> Message-ID: <20090321163631.GD5782@vacation.karoshi.com.> On Sat, Mar 21, 2009 at 08:44:23AM -0700, Randy Bush wrote: > > perhaps there is a lesson here. move on to 4-byte asns. > > randy er... 'parm me sir, but aren't -all- ASNs 4 bytes? i mean, for lo these many years we cheated and only used the first two bytes... but the spec always called out four bytes. --bill From frnkblk at iname.com Sat Mar 21 12:44:15 2009 From: frnkblk at iname.com (Frank Bulk) Date: Sat, 21 Mar 2009 12:44:15 -0500 Subject: REVERSE DNS Practices. In-Reply-To: <7c9a4be6ad650d86a4884a739cb2ada9@imap.yoafrica.com> References: <20090321103230.24415.qmail@simone.iecc.com> <7c9a4be6ad650d86a4884a739cb2ada9@imap.yoafrica.com> Message-ID: The recommendations in this draft proposal have worked for me: http://tools.ietf.org/id/draft-msullivan-dnsop-generic-naming-schemes-00.txt Frank -----Original Message----- From: bruce at yoafrica.com [mailto:bruce at yoafrica.com] Sent: Saturday, March 21, 2009 5:39 AM To: John Levine Cc: nanog at nanog.org Subject: Re: REVERSE DNS Practices. Slighty related... Can people please post their recommended reverse dns naming conventions for a small ISP with growth and scalability in mind. I already have one drawn up, but I would like to contrast and compare :D Thanks On 21 Mar 2009 10:32:30 -0000, John Levine wrote: >> I want to ask some folks out there that maintain reverse DNS queries >>of their respective IP blocks. I want to know if there is a need for >>me to contact my upstream provider. I am in charge of 2 /24's under >>LACNIC. I've already registered my DNS servers on LACNIC. but for some >>weird reason it's not owning reverse resolves. any tips would be >>gladly appreciated. > > The RIRs don't maintain rDNS for you. You'll have to trace the > delegations downward from in-addr.arpa, find out who's handling your > /24's, and contact them to get them to delegate your chunks to you. > > R's, > John From hank at efes.iucc.ac.il Sat Mar 21 12:48:50 2009 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Sat, 21 Mar 2009 19:48:50 +0200 (IST) Subject: Redundant AS's In-Reply-To: <49C3C952.4050808@verizonbusiness.com> References: <5.1.0.14.2.20090318095944.04fdb070@efes.iucc.ac.il> <5021774B-6774-4DF9-8864-DC45A184BCAA@eyeconomics.com> <5021774B-6774-4DF9-8864-DC45A184BCAA@eyeconomics.com> <5.1.0.14.2.20090318095944.04fdb070@efes.iucc.ac.il> <5.1.0.14.2.20090319074418.00aca8c8@efes.iucc.ac.il> <878wn060t6.fsf@mid.deneb.enyo.de> <49C3C952.4050808@verizonbusiness.com> Message-ID: On Fri, 20 Mar 2009, Heather Schiller wrote: > I don't think old vs new really matters.. pardon me for sticking w/ ARIN in > this example.. I can follow their fee structure easiest - and doesn't have > the old vs new: (https://www.arin.net/fees/fee_schedule.html) > > ARIN charges $100/yr for ASN's ... any "compensation" for returning an ASN > should be less than the $100 they charge? Would it make any financial sense > to compensate someone $500 for returning an ASN that only generates $100 a > year? (Remember that the RIR's are non-profits..) Well old vs new does have consequences. I have many ASNs issued since 1996, yet they were never charged. See 2006: ftp://ftp.ripe.net/ripe/docs/ripe-360.pdf "Note: AS Numbers, PI IPv4 and IPv6 special purpose assignments issued before 1 October 2004 will NOT count toward the 2006 billing score." As it had been up till that point. Yet in 2007: ftp://ftp.ripe.net/ripe/docs/ripe-392.pdf that rule changed and suddenly older allocations were suddenly billed. So a LIR that issued ASNs to customers and only charged them a one-time fee in 1996-2006 (processing and handling) is suddenly saddled with additional costs that they can no longer pass on to the customer. I wonder what ARIN did in that regards. Regards, Hank From mtinka at globaltransit.net Sat Mar 21 21:30:07 2009 From: mtinka at globaltransit.net (Mark Tinka) Date: Sun, 22 Mar 2009 10:30:07 +0800 Subject: REVERSE DNS Practices. In-Reply-To: <7c9a4be6ad650d86a4884a739cb2ada9@imap.yoafrica.com> References: <20090321103230.24415.qmail@simone.iecc.com> <7c9a4be6ad650d86a4884a739cb2ada9@imap.yoafrica.com> Message-ID: <200903221030.12564.mtinka@globaltransit.net> On Saturday 21 March 2009 06:38:55 pm bruce at yoafrica.com wrote: > Slighty related... > > Can people please post their recommended reverse dns > naming conventions for a small ISP with growth and > scalability in mind. I already have one drawn up, but I > would like to contrast and compare :D As regards core infrastructure, I posted the below on this list a while back, not sure if it'll help. http://www.merit.edu/mail.archives/nanog/msg01341.html YMMV. Cheers, Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. URL: From jhma at mcvax.org Sun Mar 22 07:09:34 2009 From: jhma at mcvax.org (James Aldridge) Date: Sun, 22 Mar 2009 12:09:34 +0000 Subject: AS path weirdness In-Reply-To: <49C4558C.8050306@packetnexus.com> References: <49C4558C.8050306@packetnexus.com> Message-ID: Jason Lewis wrote: > I'm not entirely sure what I'm looking at. The reserved AS, 65490 > appears in parentheses and I've never seen that in MRT formatted data > and not sure why it's happening. That would be a single-element AS_SET, I guess. > I'm also not clear on why I see 23456 *and* a 32 bit AS in the path. Is > anyone else seeing this or is it something wacky at RRC04? That's certainly not limited to rrc04. From one of our routers at the AMS-IX I see the following (JunOS 9.2, so 32-bit AS numbers are in "ASPLAIN" format and AS_TRANS is spelt out): A Destination P Prf Metric 1 Metric 2 Next hop AS path * 91.201.176.0/22 B 170 100 0 >195.69.144.110 3356 21219 196638 I B 170 100 10 >193.0.0.147 12859 21219 196638 I B 170 100 50 >195.69.144.200 12859 21219 196638 I B 170 100 100 >195.69.144.35 12859 21219 196638 I B 170 100 >195.69.144.178 6320 3327 21219 196638 I B 170 100 0 >195.69.145.47 8218 3257 3356 21219 196638 I B 170 100 >195.69.144.50 1103 3549 3327 21219 196638 I B 170 100 >195.69.144.34 1103 3257 3356 21219 196638 I B 170 100 0 >195.69.145.144 1273 3549 3327 21219 196638 I B 170 100 100 >195.69.144.89 286 3549 3549 3327 21219 196638 I * 91.207.218.0/23 B 170 100 0 >195.69.144.110 3356 13249 6886 196629 I B 170 100 0 >193.0.0.147 3356 13249 6886 196629 I B 170 100 50 >195.69.144.200 12859 35320 196629 AS_TRANS ? B 170 100 100 >195.69.144.35 12859 35320 196629 AS_TRANS ? B 170 100 >195.69.144.178 6320 2914 35320 196629 AS_TRANS ? B 170 100 0 >195.69.145.144 1273 2914 35320 196629 AS_TRANS ? B 170 100 100 >195.69.144.89 286 2914 35320 196629 AS_TRANS ? B 170 100 0 >195.69.145.47 8218 3257 3356 13249 6886 196629 I B 170 100 >195.69.144.50 1103 3549 3356 13249 6886 196629 I B 170 100 >195.69.144.34 1103 3257 3356 13249 6886 196629 I * 195.88.52.0/23 B 170 100 0 >195.69.144.110 3356 13249 28761 196665 I B 170 100 0 >193.0.0.147 3356 13249 28761 196665 I B 170 100 50 >195.69.144.200 12859 13249 28761 196665 I B 170 100 100 >195.69.144.35 12859 13249 28761 196665 I B 170 100 0 >195.69.145.144 1273 3356 13249 28761 196665 I B 170 100 100 >195.69.144.89 286 3356 13249 28761 196665 I B 170 100 0 >195.69.145.47 8218 3257 3356 13249 28761 196665 I B 170 100 >195.69.144.50 1103 3549 3356 13249 28761 196665 I B 170 100 >195.69.144.34 1103 3257 3356 13249 28761 196665 I * 195.128.231.0/24 B 170 100 0 >195.69.144.110 3356 13249 6886 196629 35748 I B 170 100 10 >193.0.0.147 12859 35320 196629 AS_TRANS 35748 I B 170 100 50 >195.69.144.200 12859 35320 196629 AS_TRANS 35748 I B 170 100 100 >195.69.144.35 12859 35320 196629 AS_TRANS 35748 I B 170 100 >195.69.144.178 6320 2914 35320 196629 AS_TRANS 35748 I B 170 100 0 >195.69.145.144 1273 2914 35320 196629 AS_TRANS 35748 I B 170 100 100 >195.69.144.89 286 2914 35320 196629 AS_TRANS 35748 I B 170 100 0 >195.69.145.47 8218 3257 2914 35320 196629 AS_TRANS 35748 I B 170 100 >195.69.144.50 1103 3257 2914 35320 196629 AS_TRANS 35748 I B 170 100 >195.69.144.34 1103 3257 2914 35320 196629 AS_TRANS 35748 I AS_TRANS and a 32-bit ASN only seem to appear together in the paths through 35320 so it looks as though something odd is going on there. James From jlewis at packetnexus.com Sun Mar 22 09:51:48 2009 From: jlewis at packetnexus.com (Jason Lewis) Date: Sun, 22 Mar 2009 10:51:48 -0400 Subject: AS path weirdness In-Reply-To: References: <49C4558C.8050306@packetnexus.com> Message-ID: <49C65084.1020209@packetnexus.com> I was under the impression that MRT only used brackets for sets. eg. [ASNUM] Thanks for taking a look. jas James Aldridge wrote: > Jason Lewis wrote: >> I'm not entirely sure what I'm looking at. The reserved AS, 65490 >> appears in parentheses and I've never seen that in MRT formatted data >> and not sure why it's happening. > > That would be a single-element AS_SET, I guess. > From christian at broknrobot.com Sun Mar 22 12:19:45 2009 From: christian at broknrobot.com (Christian Koch) Date: Sun, 22 Mar 2009 10:19:45 -0700 Subject: AS path weirdness In-Reply-To: <49C65084.1020209@packetnexus.com> References: <49C4558C.8050306@packetnexus.com> <49C65084.1020209@packetnexus.com> Message-ID: a private asn in (parentheses) indicates a bgp confederation, i would tend to think that there is some sort of mis-config or software bug in one of the routers in that path thats leaking it On Sun, Mar 22, 2009 at 7:51 AM, Jason Lewis wrote: > I was under the impression that MRT only used brackets for sets. ?eg. > [ASNUM] > > Thanks for taking a look. > > jas > > James Aldridge wrote: >> Jason Lewis wrote: >>> I'm not entirely sure what I'm looking at. The reserved AS, 65490 >>> appears in parentheses and I've never seen that in MRT formatted data >>> and not sure why it's happening. >> >> That would be a single-element AS_SET, I guess. >> > > From nick at foobar.org Sun Mar 22 17:56:06 2009 From: nick at foobar.org (Nick Hilliard) Date: Sun, 22 Mar 2009 22:56:06 +0000 Subject: Redundant AS's In-Reply-To: <20090321163631.GD5782@vacation.karoshi.com.> References: <5.1.0.14.2.20090318095944.04fdb070@efes.iucc.ac.il> <5021774B-6774-4DF9-8864-DC45A184BCAA@eyeconomics.com> <5.1.0.14.2.20090319074418.00aca8c8@efes.iucc.ac.il> <878wn060t6.fsf@mid.deneb.enyo.de> <20090321163631.GD5782@vacation.karoshi.com.> Message-ID: <49C6C206.4060907@foobar.org> On 21/03/2009 16:36, bmanning at vacation.karoshi.com wrote: > er... 'parm me sir, but aren't -all- ASNs 4 bytes? > > i mean, for lo these many years we cheated and only > used the first two bytes... but the spec always > called out four bytes. There seems to be a bug in my router: > router(config)#router bgp 196641 > ^ > % Invalid input detected at '^' marker. > > router(config)# Do you know of anyone I could call who can fix this? Nick From r.hyunseog at ieee.org Sun Mar 22 18:16:41 2009 From: r.hyunseog at ieee.org (Alex H. Ryu) Date: Sun, 22 Mar 2009 18:16:41 -0500 Subject: Redundant AS's In-Reply-To: <49C6C206.4060907@foobar.org> References: <5.1.0.14.2.20090318095944.04fdb070@efes.iucc.ac.il> <5021774B-6774-4DF9-8864-DC45A184BCAA@eyeconomics.com> <5.1.0.14.2.20090319074418.00aca8c8@efes.iucc.ac.il> <878wn060t6.fsf@mid.deneb.enyo.de> <20090321163631.GD5782@vacation.karoshi.com.> <49C6C206.4060907@foobar.org> Message-ID: <49C6C6D9.1090607@ieee.org> Not all of Cisco IOS supports 4-byte ASN. http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6554/ps6599/data_sheet_C78-521821.html Alex Nick Hilliard wrote: > On 21/03/2009 16:36, bmanning at vacation.karoshi.com wrote: >> er... 'parm me sir, but aren't -all- ASNs 4 bytes? >> >> i mean, for lo these many years we cheated and only >> used the first two bytes... but the spec always >> called out four bytes. > > There seems to be a bug in my router: > >> router(config)#router bgp 196641 >> ^ >> % Invalid input detected at '^' marker. >> >> router(config)# > > Do you know of anyone I could call who can fix this? > > Nick > > > From nanog2 at adns.net Sun Mar 22 19:01:03 2009 From: nanog2 at adns.net (John Palmer (NANOG Acct)) Date: Sun, 22 Mar 2009 19:01:03 -0500 Subject: Akamai wierdness Message-ID: <0bda01c9ab4a$7513a0c0$64904002@TAKA> Most of the sites served by Akamai seem to be wacky this afternoon from Chicago. Probably the March Madness stuff, but its really bad today - Chicagotribune.com wont load at all from here and SunTimes.com is missing all of its images. Are others seeing this problem from other locations? Getting alot of support calls from folks.... From twright at internode.com.au Sun Mar 22 19:01:22 2009 From: twright at internode.com.au (Tom Wright) Date: Mon, 23 Mar 2009 10:31:22 +1030 Subject: REVERSE DNS Practices. In-Reply-To: <20090321130055.GA5782@vacation.karoshi.com.> References: <20090321103230.24415.qmail@simone.iecc.com> <7c9a4be6ad650d86a4884a739cb2ada9@imap.yoafrica.com> <20090321130055.GA5782@vacation.karoshi.com.> Message-ID: <4BA14C06-5E96-4064-999A-52AD1B2743F2@internode.com.au> On 21/03/2009, at 11:30 PM, bmanning at vacation.karoshi.com wrote: > if you really don't care about the actual node, then you should map > the > numbers to topologically significant names - after all, the reverse > map > follows topology, not some goofball - layer 9 - ego trip thing. Agreed - and its certainly manageable if you automate the process. Generating reverse lookups from your config backups is a pretty reliable way of doing this for infrastructure/dynamic allocations. Your NOC staff will love it because they won't have to worry when they shuffle around local pools, or turn up new interfaces. > or - the more modern approach is to let the node (w/ proper > authorization) > do a secure dynamic update of the revserse map - so the forward and > reverse > delegations match. ... a -VERY- useful technique. Are there any network operators actually doing this on a large scale? -- Tom -- Kind Regards, Tom Wright Internode Network Operations P: +61 8 8228 2999 W: http://www.internode.on.net From pstewart at nexicomgroup.net Sun Mar 22 19:05:49 2009 From: pstewart at nexicomgroup.net (Paul Stewart) Date: Sun, 22 Mar 2009 20:05:49 -0400 Subject: Akamai wierdness In-Reply-To: <0bda01c9ab4a$7513a0c0$64904002@TAKA> References: <0bda01c9ab4a$7513a0c0$64904002@TAKA> Message-ID: <89D27DE3375BB6428DDCC2927489826A021B71EE@nexus.nexicomgroup.net> Hi there.. Chicagotribune.com is coming up from here (Toronto area) but very slow loading.... suntimes.com loads nice and fast from here. Having said that, we're an Akamai powered network here so presume most/all is coming from local caches.... didn't break down each page to see sources... Paul -----Original Message----- From: John Palmer (NANOG Acct) [mailto:nanog2 at adns.net] Sent: March 22, 2009 8:01 PM To: nanog at nanog.org Subject: Akamai wierdness Most of the sites served by Akamai seem to be wacky this afternoon from Chicago. Probably the March Madness stuff, but its really bad today - Chicagotribune.com wont load at all from here and SunTimes.com is missing all of its images. Are others seeing this problem from other locations? Getting alot of support calls from folks.... ---------------------------------------------------------------------------- "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you." From nanog2 at adns.net Sun Mar 22 20:39:12 2009 From: nanog2 at adns.net (John Palmer (NANOG Acct)) Date: Sun, 22 Mar 2009 20:39:12 -0500 Subject: Akamai wierdness References: <0bda01c9ab4a$7513a0c0$64904002@TAKA> <89D27DE3375BB6428DDCC2927489826A021B71EE@nexus.nexicomgroup.net> Message-ID: <0c0a01c9ab58$4bc31e40$64904002@TAKA> Its something to do with Akamai in Chicago. Been flakey all day. ----- Original Message ----- From: "Paul Stewart" To: "John Palmer (NANOG Acct)" Cc: "NANOG list" Sent: Sunday, March 22, 2009 7:05 PM Subject: RE: Akamai wierdness Hi there.. Chicagotribune.com is coming up from here (Toronto area) but very slow loading.... suntimes.com loads nice and fast from here. Having said that, we're an Akamai powered network here so presume most/all is coming from local caches.... didn't break down each page to see sources... Paul -----Original Message----- From: John Palmer (NANOG Acct) [mailto:nanog2 at adns.net] Sent: March 22, 2009 8:01 PM To: nanog at nanog.org Subject: Akamai wierdness Most of the sites served by Akamai seem to be wacky this afternoon from Chicago. Probably the March Madness stuff, but its really bad today - Chicagotribune.com wont load at all from here and SunTimes.com is missing all of its images. Are others seeing this problem from other locations? Getting alot of support calls from folks.... ---------------------------------------------------------------------------- "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you." From patrick at ianai.net Sun Mar 22 20:59:05 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Sun, 22 Mar 2009 21:59:05 -0400 Subject: Akamai wierdness In-Reply-To: <0c0a01c9ab58$4bc31e40$64904002@TAKA> References: <0bda01c9ab4a$7513a0c0$64904002@TAKA> <89D27DE3375BB6428DDCC2927489826A021B71EE@nexus.nexicomgroup.net> <0c0a01c9ab58$4bc31e40$64904002@TAKA> Message-ID: <385D08D6-35CC-40EF-ACC3-7B5D6E84A27E@ianai.net> Belive it or not, noc at akamai.com is a real address which is read and responds 24/7. Perhaps using the RFC required address would be more productive than e- mailing 10k strangers? -- TTFN, patrick Sent from my iPhone 3-J, please excuse any errors. (That's 3-Jezuz for the uninitiated.) On Mar 22, 2009, at 21:39, "John Palmer \(NANOG Acct\)" wrote: > Its something to do with Akamai in Chicago. Been flakey all day. > > ----- Original Message ----- From: "Paul Stewart" > > To: "John Palmer (NANOG Acct)" > Cc: "NANOG list" > Sent: Sunday, March 22, 2009 7:05 PM > Subject: RE: Akamai wierdness > > > Hi there.. > > Chicagotribune.com is coming up from here (Toronto area) but very slow > loading.... suntimes.com loads nice and fast from here. > > Having said that, we're an Akamai powered network here so presume > most/all is coming from local caches.... didn't break down each page > to > see sources... > > Paul > > > -----Original Message----- > From: John Palmer (NANOG Acct) [mailto:nanog2 at adns.net] > Sent: March 22, 2009 8:01 PM > To: nanog at nanog.org > Subject: Akamai wierdness > > Most of the sites served by Akamai seem to be wacky this afternoon > from > Chicago. > > Probably the March Madness stuff, but its really bad today - > Chicagotribune.com wont load at all > from here and SunTimes.com is missing all of its images. > > Are others seeing this problem from other locations? Getting alot of > support calls from folks.... > > > > > > > --- > --- > ---------------------------------------------------------------------- > > "The information transmitted is intended only for the person or > entity to which it is addressed and contains confidential and/or > privileged material. If you received this in error, please contact > the sender immediately and then destroy this transmission, including > all attachments, without copying, distributing or disclosing same. > Thank you." > > > From bmanning at vacation.karoshi.com Sun Mar 22 21:45:22 2009 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Mon, 23 Mar 2009 02:45:22 +0000 Subject: Redundant AS's In-Reply-To: <49C6C206.4060907@foobar.org> References: <5.1.0.14.2.20090318095944.04fdb070@efes.iucc.ac.il> <5021774B-6774-4DF9-8864-DC45A184BCAA@eyeconomics.com> <5.1.0.14.2.20090319074418.00aca8c8@efes.iucc.ac.il> <878wn060t6.fsf@mid.deneb.enyo.de> <20090321163631.GD5782@vacation.karoshi.com.> <49C6C206.4060907@foobar.org> Message-ID: <20090323024522.GA2012@vacation.karoshi.com.> On Sun, Mar 22, 2009 at 10:56:06PM +0000, Nick Hilliard wrote: > On 21/03/2009 16:36, bmanning at vacation.karoshi.com wrote: > > er... 'parm me sir, but aren't -all- ASNs 4 bytes? > > > > i mean, for lo these many years we cheated and only > > used the first two bytes... but the spec always > > called out four bytes. > > There seems to be a bug in my router: > > >router(config)#router bgp 196641 > > ^ > >% Invalid input detected at '^' marker. > > > >router(config)# > > Do you know of anyone I could call who can fix this? > > Nick your using the wrong protocol.. :) or the wrong version of a vendors code. try EGP and you should be fine w/ 4byte ASNs. --bill From rs at seastrom.com Sun Mar 22 22:03:16 2009 From: rs at seastrom.com (Robert E. Seastrom) Date: Sun, 22 Mar 2009 23:03:16 -0400 Subject: Redundant AS's In-Reply-To: <20090323024522.GA2012@vacation.karoshi.com.> (bmanning@vacation.karoshi.com's message of "Mon, 23 Mar 2009 02:45:22 +0000") References: <5.1.0.14.2.20090318095944.04fdb070@efes.iucc.ac.il> <5021774B-6774-4DF9-8864-DC45A184BCAA@eyeconomics.com> <5.1.0.14.2.20090319074418.00aca8c8@efes.iucc.ac.il> <878wn060t6.fsf@mid.deneb.enyo.de> <20090321163631.GD5782@vacation.karoshi.com.> <49C6C206.4060907@foobar.org> <20090323024522.GA2012@vacation.karoshi.com.> Message-ID: <864oxlj5zf.fsf@seastrom.com> bmanning at vacation.karoshi.com writes: > On Sun, Mar 22, 2009 at 10:56:06PM +0000, Nick Hilliard wrote: >> On 21/03/2009 16:36, bmanning at vacation.karoshi.com wrote: >> > er... 'parm me sir, but aren't -all- ASNs 4 bytes? >> > >> > i mean, for lo these many years we cheated and only >> > used the first two bytes... but the spec always >> > called out four bytes. >> >> There seems to be a bug in my router: >> >> >router(config)#router bgp 196641 >> > ^ >> >% Invalid input detected at '^' marker. >> > >> >router(config)# >> >> Do you know of anyone I could call who can fix this? >> >> Nick > > > your using the wrong protocol.. :) > or the wrong version of a vendors code. > try EGP and you should be fine w/ 4byte ASNs. rfc 827, page 3: Autonomous systems will be assigned 16-bit identification numbers (in much the same ways as network and protocol numbers are now assigned), and every EGP message header contains one word for this number. -r From lyndon at orthanc.ca Sun Mar 22 23:35:01 2009 From: lyndon at orthanc.ca (Lyndon Nerenberg) Date: Sun, 22 Mar 2009 21:35:01 -0700 (PDT) Subject: Redundant AS's In-Reply-To: <864oxlj5zf.fsf@seastrom.com> References: <5.1.0.14.2.20090318095944.04fdb070@efes.iucc.ac.il> <5021774B-6774-4DF9-8864-DC45A184BCAA@eyeconomics.com> <5.1.0.14.2.20090319074418.00aca8c8@efes.iucc.ac.il> <878wn060t6.fsf@mid.deneb.enyo.de> <20090321163631.GD5782@vacation.karoshi.com.> <49C6C206.4060907@foobar.org> <20090323024522.GA2012@vacation.karoshi.com.> <864oxlj5zf.fsf@seastrom.com> Message-ID: > Autonomous systems will be assigned 16-bit identification > numbers (in much the same ways as network and protocol numbers > are now assigned), and every EGP message header contains one word > for this number. Was that a 36-bit word? --lyndon I think 3B2 code deserves its own place in hell. Poring over the ESS#5 code, someone found that there were lots of strcmp(p, "f(") == 0 checks (I may have gotten the exact string wrong but it's close). It took us a while to figure out why. Apparently, location 0 on the 3b had the 3 bytes 'f' '(' '\0', someone noticed that when programs blew up they were pointing to "f(", and the worlds most amazing kludge for detecting nil pointers was born. -- Dave Presotto From andy at nosignal.org Mon Mar 23 02:40:38 2009 From: andy at nosignal.org (Andy Davidson) Date: Mon, 23 Mar 2009 07:40:38 +0000 Subject: AS path weirdness In-Reply-To: <49C4558C.8050306@packetnexus.com> References: <49C4558C.8050306@packetnexus.com> Message-ID: <1CDE960B-63CD-4D42-8C42-1C6BC475C371@nosignal.org> On 21 Mar 2009, at 02:48, Jason Lewis wrote: > I'm not entirely sure what I'm looking at. The reserved AS, 65490 > appears in parentheses and I've never seen that in MRT formatted > data and not sure why it's happening. This has been observed when a vendor runs 32-bit AS aware code on part of their edge, and non-32-bit AS aware code on a different part of their edge. > I'm also not clear on why I see 23456 *and* a 32 bit AS in the > path. Is anyone else seeing this or is it something wacky at RRC04? > 91.207.218.0/23|29222 6830 (65490) 3356 35320 3.21 23456 There's some history with this prefix. http://www.andyd.net/media/talks/asn4_breaks_network.pdf [from nanog45] Andy From rs at seastrom.com Mon Mar 23 06:59:50 2009 From: rs at seastrom.com (Robert E. Seastrom) Date: Mon, 23 Mar 2009 07:59:50 -0400 Subject: Redundant AS's In-Reply-To: (Lyndon Nerenberg's message of "Sun, 22 Mar 2009 21:35:01 -0700 (PDT)") References: <5.1.0.14.2.20090318095944.04fdb070@efes.iucc.ac.il> <5021774B-6774-4DF9-8864-DC45A184BCAA@eyeconomics.com> <5.1.0.14.2.20090319074418.00aca8c8@efes.iucc.ac.il> <878wn060t6.fsf@mid.deneb.enyo.de> <20090321163631.GD5782@vacation.karoshi.com.> <49C6C206.4060907@foobar.org> <20090323024522.GA2012@vacation.karoshi.com.> <864oxlj5zf.fsf@seastrom.com> Message-ID: <86d4c8fo09.fsf@seastrom.com> Lyndon Nerenberg writes: >> Autonomous systems will be assigned 16-bit identification >> numbers (in much the same ways as network and protocol numbers >> are now assigned), and every EGP message header contains one word >> for this number. > > Was that a 36-bit word? 16-bit "word" in the sense of a PDP-11 or DG Nova, not 36-bit "word" in the sense of a Univac-1100 or DECSYSTEM-20. Be glad that it wasn't a 12-bit "word" in the sense of a PDP-8. (page 33, same RFC) -r From pauldotwall at gmail.com Mon Mar 23 09:18:07 2009 From: pauldotwall at gmail.com (Paul Wall) Date: Mon, 23 Mar 2009 09:18:07 -0500 Subject: Akamai wierdness In-Reply-To: <385D08D6-35CC-40EF-ACC3-7B5D6E84A27E@ianai.net> References: <0bda01c9ab4a$7513a0c0$64904002@TAKA> <89D27DE3375BB6428DDCC2927489826A021B71EE@nexus.nexicomgroup.net> <0c0a01c9ab58$4bc31e40$64904002@TAKA> <385D08D6-35CC-40EF-ACC3-7B5D6E84A27E@ianai.net> Message-ID: <620fd17c0903230718n5fa15e75nbd1ea5581ea656d2@mail.gmail.com> Patrick Gilmore wrote [context inserted]: > Perhaps using the RFC required address [noc at akamai] would be more productive than e-mailing 10k strangers? Normally I see emails like this and, if it's Not In My Back Yard, and the Internet is not going nutz, the delete key explains how worried i am. Back to your email: > using the RFC required address The correct catty response to the Akamai question is : ccare at akamai.com. That's C as in "Customer", Care as in "they actually care". I would end the email there, but it really gets me how someone that is in-house doesn't realize that noc at akamai is a black hole. Drive Slow, -paul From schampeo at hesketh.com Mon Mar 23 15:06:37 2009 From: schampeo at hesketh.com (Steven Champeon) Date: Mon, 23 Mar 2009 16:06:37 -0400 Subject: REVERSE DNS Practices. In-Reply-To: References: <20090321103230.24415.qmail@simone.iecc.com> <7c9a4be6ad650d86a4884a739cb2ada9@imap.yoafrica.com> Message-ID: <20090323200637.GC2946@hesketh.com> on Sat, Mar 21, 2009 at 12:44:15PM -0500, Frank Bulk wrote: > The recommendations in this draft proposal have worked for me: > http://tools.ietf.org/id/draft-msullivan-dnsop-generic-naming-schemes-00.txt Also: http://tools.ietf.org/html/draft-ietf-dnsop-reverse-mapping-considerations-06 http://tools.ietf.org/html/draft-ietf-dnsop-inaddr-required-07 In any case, it depends on whether those IPs will house legitimate sources of mail; I *strongly* recommend indicating whether an IP is dynamically or statically assigned, and (ideally) what sort of tech is in use (dialup? DSL? cable? wifi? etc) so that mail admins can make decisions about whether or not to allow mail from those hosts. (Hrm, do I want mail from a dynamic wifi IP? not so much; static generic dsl? okay, maybe for now). If you want to be friendly to folks who don't necessarily want to have to use regexes to match your dynamics, make sure that if you do use some sort of topology- or geography-based naming, that you put the "dynamic" or "static" token as far to the right as possible, so that you end up with rdu-1-2-3-4.cable.dynamic.example.net instead of dyn-1-2-3-4.cable.rdu.example.net because it's a lot easier for mail admins to block 'dynamic.example.net' than to have to have local access.db entries for every last geography you're serving, or have to use regexes. And please don't mix dynamics and statics under the same naming conventions. Finally, if you *do* intend for these IPs to house legit mail servers (or mail sources, for that matter), whether yours or your clients', for the love of all that is good and holy, give them /custom/ PTRs that indicate the actual domain of the responsible party, rather than just giving them generic names in your domain, unless you really want to act as an abuse report gateway for your clients. HTH, Steve -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2553 w: http://hesketh.com/ antispam news, solutions for sendmail, exim, postfix: http://enemieslist.com/ From jcdill.lists at gmail.com Mon Mar 23 16:03:28 2009 From: jcdill.lists at gmail.com (JC Dill) Date: Mon, 23 Mar 2009 14:03:28 -0700 Subject: Akamai wierdness In-Reply-To: <620fd17c0903230718n5fa15e75nbd1ea5581ea656d2@mail.gmail.com> References: <0bda01c9ab4a$7513a0c0$64904002@TAKA> <89D27DE3375BB6428DDCC2927489826A021B71EE@nexus.nexicomgroup.net> <0c0a01c9ab58$4bc31e40$64904002@TAKA> <385D08D6-35CC-40EF-ACC3-7B5D6E84A27E@ianai.net> <620fd17c0903230718n5fa15e75nbd1ea5581ea656d2@mail.gmail.com> Message-ID: <49C7F920.5040707@gmail.com> Paul Wall wrote: > Patrick Gilmore wrote [context inserted]: > >> Perhaps using the RFC required address [noc at akamai] would be more >> > productive than e-mailing 10k strangers? > > Normally I see emails like this and, if it's Not In My Back Yard, and the > Internet is not going nutz, the delete key explains how worried i am. > > Back to your email: > > >> using the RFC required address >> > > The correct catty response to the Akamai question is : ccare at akamai.com. > That's C as in "Customer", Care as in "they actually care". > > I would end the email there, but it really gets me how someone that is > in-house doesn't realize that noc at akamai is a black hole. Paul, you might want to test a theory of this nature before you post about it to more than a thousand of your colleagues. This morning I sent email to noc at akamai.com and received a personalized (non-autoresponder) reply 17 minutes later. jc From pstewart at nexicomgroup.net Mon Mar 23 17:28:04 2009 From: pstewart at nexicomgroup.net (Paul Stewart) Date: Mon, 23 Mar 2009 18:28:04 -0400 Subject: Akamai wierdness In-Reply-To: <49C7F920.5040707@gmail.com> References: <0bda01c9ab4a$7513a0c0$64904002@TAKA> <89D27DE3375BB6428DDCC2927489826A021B71EE@nexus.nexicomgroup.net> <0c0a01c9ab58$4bc31e40$64904002@TAKA> <385D08D6-35CC-40EF-ACC3-7B5D6E84A27E@ianai.net><620fd17c0903230718n5fa15e75nbd1ea5581ea656d2@mail.gmail.com> <49C7F920.5040707@gmail.com> Message-ID: <89D27DE3375BB6428DDCC2927489826A02223D17@nexus.nexicomgroup.net> Not to add to a potential "peeing" contest here.... but we have Akamai equipment in our network - it's a very important component to our service delivery. If/when there is ever a problem (quite rare in our experience other than the odd hardware failure that has no impact anyways due to the cluster configuration) we send an email to noc at akamai.com. Typical response times on a 24X7 basis never normally exceed 20 minutes at most. I can remember one time where it might have been an hour. That's a long ways from "blackhole" based on our experience... Paul Stewart -----Original Message----- From: JC Dill [mailto:jcdill.lists at gmail.com] Sent: Monday, March 23, 2009 5:03 PM Cc: NANOG list Subject: Re: Akamai wierdness Paul Wall wrote: > Patrick Gilmore wrote [context inserted]: > >> Perhaps using the RFC required address [noc at akamai] would be more >> > productive than e-mailing 10k strangers? > > Normally I see emails like this and, if it's Not In My Back Yard, and the > Internet is not going nutz, the delete key explains how worried i am. > > Back to your email: > > >> using the RFC required address >> > > The correct catty response to the Akamai question is : ccare at akamai.com. > That's C as in "Customer", Care as in "they actually care". > > I would end the email there, but it really gets me how someone that is > in-house doesn't realize that noc at akamai is a black hole. Paul, you might want to test a theory of this nature before you post about it to more than a thousand of your colleagues. This morning I sent email to noc at akamai.com and received a personalized (non-autoresponder) reply 17 minutes later. jc ---------------------------------------------------------------------------- "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you." From charles at thewybles.com Mon Mar 23 17:35:53 2009 From: charles at thewybles.com (Charles Wyble) Date: Mon, 23 Mar 2009 15:35:53 -0700 Subject: Akamai wierdness In-Reply-To: <89D27DE3375BB6428DDCC2927489826A02223D17@nexus.nexicomgroup.net> References: <0bda01c9ab4a$7513a0c0$64904002@TAKA> <89D27DE3375BB6428DDCC2927489826A021B71EE@nexus.nexicomgroup.net> <0c0a01c9ab58$4bc31e40$64904002@TAKA> <385D08D6-35CC-40EF-ACC3-7B5D6E84A27E@ianai.net><620fd17c0903230718n5fa15e75nbd1ea5581ea656d2@mail.gmail.com> <49C7F920.5040707@gmail.com> <89D27DE3375BB6428DDCC2927489826A02223D17@nexus.nexicomgroup.net> Message-ID: <49C80EC9.6080608@thewybles.com> I usually just call their toll free support number when their are occasional issues. This is from a content provider perspective (using Akamai as a CDN for the sites I support). Never had an issue getting a hold of anyone and getting the issue resolved (two times I have called them, it was issues on our side anyway). Paul Stewart wrote: > Not to add to a potential "peeing" contest here.... but we have Akamai > equipment in our network - it's a very important component to our > service delivery. If/when there is ever a problem (quite rare in our > experience other than the odd hardware failure that has no impact > anyways due to the cluster configuration) we send an email to > noc at akamai.com. > > Typical response times on a 24X7 basis never normally exceed 20 minutes > at most. I can remember one time where it might have been an hour. > > That's a long ways from "blackhole" based on our experience... > > Paul Stewart > > > -----Original Message----- > From: JC Dill [mailto:jcdill.lists at gmail.com] > Sent: Monday, March 23, 2009 5:03 PM > Cc: NANOG list > Subject: Re: Akamai wierdness > > Paul Wall wrote: >> Patrick Gilmore wrote [context inserted]: >> >>> Perhaps using the RFC required address [noc at akamai] would be more >>> >> productive than e-mailing 10k strangers? >> >> Normally I see emails like this and, if it's Not In My Back Yard, and > the >> Internet is not going nutz, the delete key explains how worried i am. >> >> Back to your email: >> >> >>> using the RFC required address >>> >> The correct catty response to the Akamai question is : > ccare at akamai.com. >> That's C as in "Customer", Care as in "they actually care". >> >> I would end the email there, but it really gets me how someone that is >> in-house doesn't realize that noc at akamai is a black hole. > > Paul, you might want to test a theory of this nature before you post > about it to more than a thousand of your colleagues. This morning I > sent email to noc at akamai.com and received a personalized > (non-autoresponder) reply 17 minutes later. > > jc > > > > > > > > ---------------------------------------------------------------------------- > > "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you." > From pauldotwall at gmail.com Tue Mar 24 00:47:02 2009 From: pauldotwall at gmail.com (Paul Wall) Date: Tue, 24 Mar 2009 01:47:02 -0400 Subject: Akamai wierdness In-Reply-To: <620fd17c0903230718n5fa15e75nbd1ea5581ea656d2@mail.gmail.com> References: <0bda01c9ab4a$7513a0c0$64904002@TAKA> <89D27DE3375BB6428DDCC2927489826A021B71EE@nexus.nexicomgroup.net> <0c0a01c9ab58$4bc31e40$64904002@TAKA> <385D08D6-35CC-40EF-ACC3-7B5D6E84A27E@ianai.net> <620fd17c0903230718n5fa15e75nbd1ea5581ea656d2@mail.gmail.com> Message-ID: <620fd17c0903232247w543ff2d0s70444843e337c90e@mail.gmail.com> On Mon, Mar 23, 2009 at 10:18 AM, Paul Wall wrote: > I would end the email there, but it really gets me how someone that is in-house doesn't realize that noc at akamai is a black hole. I am pleased hear that Akamai has remedied this situation, most likely by having Mr. Gilmore attend to the matter personally. Drive Slow, Paul Wall From ringel at net.tufts.edu Tue Mar 24 10:07:08 2009 From: ringel at net.tufts.edu (Matthew F. Ringel) Date: Tue, 24 Mar 2009 11:07:08 -0400 Subject: REVERSE DNS Practices. In-Reply-To: <200903221030.12564.mtinka@globaltransit.net> References: <20090321103230.24415.qmail@simone.iecc.com> <7c9a4be6ad650d86a4884a739cb2ada9@imap.yoafrica.com> <200903221030.12564.mtinka@globaltransit.net> Message-ID: <20090324150708.GA24053@net.tufts.edu> On Sun, Mar 22, 2009 at 10:30:07AM +0800, Mark Tinka wrote: > On Saturday 21 March 2009 06:38:55 pm bruce at yoafrica.com > wrote: > > > Slighty related... > > > > Can people please post their recommended reverse dns > > naming conventions for a small ISP with growth and > > scalability in mind. I already have one drawn up, but I > > would like to contrast and compare :D > > As regards core infrastructure, I posted the below on this > list a while back, not sure if it'll help. > > http://www.merit.edu/mail.archives/nanog/msg01341.html > Similarly, I did a presentation on this a while ago. This may be of some use. http://www.nanog.org/meetings/nanog31/abstracts.php?pt=NjExJm5hbm9nMzE=&nm=nanog31 (also: http://tinyurl.com/cuqv5e ) The details of the presentation are more geared to a multi-campus enterprise network (i.e. a university), but the two larger lessons that came out of moving the university over to a more standard naming scheme were: Derivability: Being able to synthesize the name with a few pieces of data makes naming and debugging easier. Longer is okay: Barring software limitations on name length, a longer name is not a problem if a person knows that they're going to get it right on the first try. We used CNAMEs if we wanted abbreviations. YMMV ....Matt From jlewis at lewis.org Tue Mar 24 12:00:23 2009 From: jlewis at lewis.org (Jon Lewis) Date: Tue, 24 Mar 2009 13:00:23 -0400 (EDT) Subject: Usage-Based Billing for DIA In-Reply-To: <49B4E1A6.8040905@spacething.org> References: <49B4E1A6.8040905@spacething.org> Message-ID: On Mon, 9 Mar 2009, Sam Stickland wrote: >> I need to look into this in the near future as well. The problems I'm >> aware of are: >> >> 1) we have customers on policed ports, and the interface snmp counters >> count packets before service-policy. It doesn't seem right to bill for >> packets we dropped :)...so this isn't useful data for billing purposes. >> > Torrus (www.torrus.org) can use the Cisco MIBs to graph pre and post-policy > packets. > > http://www.torrus.org/plugins/tp-cisco-cbqos.pod.html I just checked a few 3550s and 3560s, and I don't see any evidence that they support CISCO-CLASS-BASED-QOS-MIB. Walking .1.3.6.1.4.1.9.9.166, I get nothing. On our 6500s, walking .1.3.6.1.4.1.9.9.166, I do get lots of data, but I don't see anything obvious in it that tells me which numbers go with which interfaces. Is anyone actually making use of CISCO-CLASS-BASED-QOS-MIB on 3550s to graph/bill traffic passed after per-interface policing service policies are applied? ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From william.allen.simpson at gmail.com Tue Mar 24 12:42:53 2009 From: william.allen.simpson at gmail.com (William Allen Simpson) Date: Tue, 24 Mar 2009 13:42:53 -0400 Subject: REVERSE DNS Practices. In-Reply-To: <20090324150708.GA24053@net.tufts.edu> References: <20090321103230.24415.qmail@simone.iecc.com> <7c9a4be6ad650d86a4884a739cb2ada9@imap.yoafrica.com> <200903221030.12564.mtinka@globaltransit.net> <20090324150708.GA24053@net.tufts.edu> Message-ID: <49C91B9D.20301@gmail.com> Matthew F. Ringel wrote: > Derivability: Being able to synthesize the name with a few pieces of > data makes naming and debugging easier. > I agree. Remember, this is mostly going to show up in log files, and they need to be easily skimmed by even the newest staff. > Longer is okay: Barring software limitations on name length, a longer > name is not a problem if a person knows that they're going to get it > right on the first try. We used CNAMEs if we wanted abbreviations. > Clarity and consistency are paramount! I'm of the mind that you (we) should always setup the reverse *first* for each block. Only after that's propagated, then add the A records and CNAMEs. When you change from dynamic or unused assignments to static or a specific customer domain, update the reverse *first*, then the A or CNAME. The reverse lists become your assurance that you haven't accidentally added duplicate assignments. Another hint (from the days we had a lot of directed broadcast attacks): indicate never used addresses and broadcast addresses in the reverse list (such as reserved0, reserved31, reserved32, reserved255), although you will *never* have them in the A records (I always add a reminder comment line on the forward side). That makes them stand out in the log. Don't forget to block (and log) your reserved addresses at your boundary routers! A script to check the ACL against the reverse DNS is good, although many routers will handle this semi-automatically now. So, you'll have a fully defined and propagated reverse list, even though the forward side hosts don't exist (yet). Security folks sometimes worry that makes scanning targeting easier, but arguably similar effort to ping those addresses will yield similar results. It's most important for security to document the vulnerabilities (reverse addresses help with self-documentation). Sometimes, folks deliberately hide their systems in a sparsely populated block of fully defined reverse addresses. From jcdill.lists at gmail.com Tue Mar 24 13:08:45 2009 From: jcdill.lists at gmail.com (JC Dill) Date: Tue, 24 Mar 2009 11:08:45 -0700 Subject: Akamai wierdness In-Reply-To: <620fd17c0903232247w543ff2d0s70444843e337c90e@mail.gmail.com> References: <0bda01c9ab4a$7513a0c0$64904002@TAKA> <89D27DE3375BB6428DDCC2927489826A021B71EE@nexus.nexicomgroup.net> <0c0a01c9ab58$4bc31e40$64904002@TAKA> <385D08D6-35CC-40EF-ACC3-7B5D6E84A27E@ianai.net> <620fd17c0903230718n5fa15e75nbd1ea5581ea656d2@mail.gmail.com> <620fd17c0903232247w543ff2d0s70444843e337c90e@mail.gmail.com> Message-ID: <49C921AD.7030306@gmail.com> Paul Wall wrote: > On Mon, Mar 23, 2009 at 10:18 AM, Paul Wall wrote: > >> I would end the email there, but it really gets me how someone that is in-house doesn't realize that noc at akamai is a black hole. >> > > I am pleased hear that Akamai has remedied this situation, most likely > by having Mr. Gilmore attend to the matter personally. The reply I received came from someone who works in the NOC, not from Patrick (who doesn't work in the NOC). It's really poor form to make these unfounded assertions without any basis for them. jc From jrhett at netconsonance.com Tue Mar 24 14:51:30 2009 From: jrhett at netconsonance.com (Jo Rhett) Date: Tue, 24 Mar 2009 12:51:30 -0700 Subject: Yahoo and their mail filters.. In-Reply-To: <49A80252.40401@pacific.net> References: <49A80252.40401@pacific.net> Message-ID: On Feb 27, 2009, at 7:10 AM, Ken A wrote: > I agree that aol could do a better job of filtering the outbound, > but I don't think it's a useless system. We get a few dozen from aol > a day unless we have a real problem. > I see the mother-daughter conversations (worst), the subscribed lazy > user emails - we encourage our mailing list senders to include unsub > links - partly to make it easy for _us_ to click and unsub these > dummies. > > And we see the 'real deal' now and then; usually an exploited php > script being abused by spammers, or someone who has had their > password sniffed, or stolen. > Most of these are users who travel and don't use secure protocols, > or have a teenager in the house (the most insecure protocol is > adolescence). We appreciate aol's efforts, imperfect as they are. The math here is easy. 1. The time cost of reading AOL's feedback loop was greater than 2 working hours every day. 2. The number of exploited systems that we received notification about was total of 3 in 2 years of reading that loop. 3. Every one of those exploited systems also got SpamCop reports. 365 x 2 years x 2 hours = 1460 hours minimum (because it rarely took only 2 hours) 1460 hours of effort / 3 compromises = 487 hours, or 3 months of work per compromise. In short, AOL provided zero value to us. Because if a SpamCop user is reporting valid receipts, I report it back to the SpamCop admins and they go have a talk with the user. NOTE: for a small mail sending provider who controls every mail server and customer in their netblock, it probably is useful. It's just useless for colocation providers and generic ISPs. And let's be honest. AOL's effort shouldn't be applauded. It's an autobot which sends false spam reports, nothing more and nothing less. Any autobot which sends false spam reports needs to be shut down. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From jbates at brightok.net Tue Mar 24 15:18:16 2009 From: jbates at brightok.net (Jack Bates) Date: Tue, 24 Mar 2009 15:18:16 -0500 Subject: Yahoo and their mail filters.. In-Reply-To: References: <49A80252.40401@pacific.net> Message-ID: <49C94008.1010307@brightok.net> Sheesh. I thought I was replying to another mailing list, until I cleaned up the recipient list. Jo Rhett wrote: > NOTE: for a small mail sending provider who controls every mail server > and customer in their netblock, it probably is useful. It's just > useless for colocation providers and generic ISPs. > It works fine for large ISPs and colocation providers; especially those who run abacus to process large volumes of reports and keep their time well spent. If you spend 2 hours on a feedback loop without any actions having to be taken, you're definitely doing something wrong. > And let's be honest. AOL's effort shouldn't be applauded. It's an > autobot which sends false spam reports, nothing more and nothing less. > Any autobot which sends false spam reports needs to be shut down. > It's not a false spam report? The recipient obviously didn't think they wanted the email. For mailing lists/broadcasters, this means it's an opt out request. For one to one mail, it's only an issue when it's repetitive, in which case, the sender probably needs to be informed that the recipient address they are using might not be correct (or the person doesn't like their style of email). Jack P.S. This really isn't operational and I should probably be shot for even replying to the thread, so feel free to reply to me off-list. From brandon at rd.bbc.co.uk Tue Mar 24 15:51:50 2009 From: brandon at rd.bbc.co.uk (Brandon Butterworth) Date: Tue, 24 Mar 2009 20:51:50 GMT Subject: Yahoo and their mail filters.. Message-ID: <200903242051.UAA12915@sunf10.rd.bbc.co.uk> > The recipient obviously didn't think they wanted the email. For > mailing lists/broadcasters, this means it's an opt out request. That would be fine, we could auto process them and remove those addresses from any lists they've joined (might be a few false unsubscribes but after they've resubscribed a few times they might figure it's not a good idea to report it as spam) but redacted at aol.com isn't on any of our lists. If this was to be more than a token system we'd be happy to support a specific unsubscribe message for those than wished to leave our lists and didn't mind supplying details. We'd also happily supply details of our lists so their system would know there is no point treating it as spam "you are reporting a mailing list you've subscribed to as spam, do you want ot unsubscribe?" etc. I'm sure most on the list could cook up a system to do this properly. brandon From pauldotwall at gmail.com Tue Mar 24 16:00:44 2009 From: pauldotwall at gmail.com (Paul Wall) Date: Tue, 24 Mar 2009 17:00:44 -0400 Subject: Akamai wierdness In-Reply-To: <49C921AD.7030306@gmail.com> References: <0bda01c9ab4a$7513a0c0$64904002@TAKA> <89D27DE3375BB6428DDCC2927489826A021B71EE@nexus.nexicomgroup.net> <0c0a01c9ab58$4bc31e40$64904002@TAKA> <385D08D6-35CC-40EF-ACC3-7B5D6E84A27E@ianai.net> <620fd17c0903230718n5fa15e75nbd1ea5581ea656d2@mail.gmail.com> <620fd17c0903232247w543ff2d0s70444843e337c90e@mail.gmail.com> <49C921AD.7030306@gmail.com> Message-ID: <620fd17c0903241400m57281772gbd8f2050a642d8@mail.gmail.com> Nothing is unfounded. I've previously had issues reaching Akamai at noc at akamai.com, which is why I suggested that the poster try the ccare@ address. It was subsequently demonstrated (by Patrick and others) that the noc@ account is currently monitored satisfactorily. Any further discussion would be off-topic, so I'll bow out now. Drive Slow. Paul Wall From sean at labrats.us Tue Mar 24 16:24:45 2009 From: sean at labrats.us (Sean Figgins) Date: Tue, 24 Mar 2009 15:24:45 -0600 Subject: Yahoo and their mail filters.. In-Reply-To: <49C94008.1010307@brightok.net> References: <49A80252.40401@pacific.net> <49C94008.1010307@brightok.net> Message-ID: <49C94F9D.1040301@labrats.us> Jack Bates wrote: > It works fine for large ISPs and colocation providers; especially those > who run abacus to process large volumes of reports and keep their time > well spent. If you spend 2 hours on a feedback loop without any actions > having to be taken, you're definitely doing something wrong. The large national tier 1 that I work for gets about 40,000 automated emails from AOL every day. I thought it was one for every email that was sent from our netblocks, but are these actually from people that have reported something as spam? There are SO many that it's a significant load on our mail server. Our Exchange server could never have hoped to keep up. And our abuse department has no chance to keep up. I'll have to look into abacus to see if it can be of some service to our abuse department. -Sean From Valdis.Kletnieks at vt.edu Tue Mar 24 16:38:22 2009 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 24 Mar 2009 17:38:22 -0400 Subject: Yahoo and their mail filters.. In-Reply-To: Your message of "Tue, 24 Mar 2009 15:18:16 CDT." <49C94008.1010307@brightok.net> References: <49A80252.40401@pacific.net> <49C94008.1010307@brightok.net> Message-ID: <40797.1237930702@turing-police.cc.vt.edu> On Tue, 24 Mar 2009 15:18:16 CDT, Jack Bates said: > It's not a false spam report? The recipient obviously didn't think they > wanted the email. I've seen people subscribe to a list, then *reply* to the subscription confirmation - and then hit "spam" not 5 minutes later when something gets posted to the list. Did they change their minds in the 5 minutes? I've see people hit "spam" for e-mail from immediate family members. Does this mean it's a dysfunctional family? The only correct part is "The recipient obviously didn't think". Period. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From mike at mtcc.com Tue Mar 24 17:21:12 2009 From: mike at mtcc.com (Michael Thomas) Date: Tue, 24 Mar 2009 15:21:12 -0700 Subject: Yahoo and their mail filters.. In-Reply-To: <40797.1237930702@turing-police.cc.vt.edu> References: <49A80252.40401@pacific.net> <49C94008.1010307@brightok.net> <40797.1237930702@turing-police.cc.vt.edu> Message-ID: <49C95CD8.5010809@mtcc.com> Valdis.Kletnieks at vt.edu wrote: > On Tue, 24 Mar 2009 15:18:16 CDT, Jack Bates said: > >> It's not a false spam report? The recipient obviously didn't think they >> wanted the email. > > I've seen people subscribe to a list, then *reply* to the subscription > confirmation - and then hit "spam" not 5 minutes later when something > gets posted to the list. Did they change their minds in the 5 minutes? > > I've see people hit "spam" for e-mail from immediate family members. > Does this mean it's a dysfunctional family? > > The only correct part is "The recipient obviously didn't think". Period. No, sorry, Valdis this is just wrongheaded. The problem here isn't stupid users, but stupid providers not giving users what they clearly want: an "i don't want this" button. Until providers start matching users expectations about what _they_ think the "junk" button means, "st00pid l00sers -- ha ha" proclamations will continue to show that providers aren't serving their customers well. Mike From gem at rellim.com Tue Mar 24 17:35:33 2009 From: gem at rellim.com (Gary E. Miller) Date: Tue, 24 Mar 2009 15:35:33 -0700 (PDT) Subject: Yahoo and their mail filters.. In-Reply-To: <49C95CD8.5010809@mtcc.com> References: <49A80252.40401@pacific.net> <49C94008.1010307@brightok.net> <40797.1237930702@turing-police.cc.vt.edu> <49C95CD8.5010809@mtcc.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Yo Michael! On Tue, 24 Mar 2009, Michael Thomas wrote: > > I've seen people subscribe to a list, then *reply* to the subscription > > confirmation - and then hit "spam" not 5 minutes later when something > > gets posted to the list. Did they change their minds in the 5 minutes? > No, sorry, Valdis this is just wrongheaded. Every day I have people sign up for our $30 a month service then report their confirmation email as spam 5 mins later. A month later when they get their Credit Card bill we hear from them that they never got their sign-up credentials and they are mad. This is just user stupidity. RGDS GARY - --------------------------------------------------------------------------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97701 gem at rellim.com Tel:+1(541)382-8588 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFJyWA4BmnRqz71OvMRAiN4AJsGZ0QvJLXBKiTyXqw/tZHuoIZ/mwCgsRMY fFvFlIobFYuLOoI6hfnwmSY= =e6pm -----END PGP SIGNATURE----- From ops.lists at gmail.com Tue Mar 24 20:50:24 2009 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Wed, 25 Mar 2009 07:20:24 +0530 Subject: Yahoo and their mail filters.. In-Reply-To: <49C94F9D.1040301@labrats.us> References: <49A80252.40401@pacific.net> <49C94008.1010307@brightok.net> <49C94F9D.1040301@labrats.us> Message-ID: On Wed, Mar 25, 2009 at 2:54 AM, Sean Figgins wrote: > something as spam? ?There are SO many that it's a significant load on our > mail server. ?Our Exchange server could never have hoped to keep up. ?And > our abuse department has no chance to keep up. > > I'll have to look into abacus to see if it can be of some service to our > abuse department. In case you havent found out yet, AOL (and most other large ISPs) feedback loops are in ARF format - which means they are quite easy to parse and aggregate using scripts. Or using readymade software like abacus. http://wordtothewise.com/resources/arf.html has links to the arf spec and other docs, plus check out the 'tools for senders, recipients' section. http://wordtothewise.com/resources/arfrecipient.html links to arffilter - a free script to parse ARF email and feed it into your MUA / ticketing system in a much more usable format. And once you have it in that format - well, you can get counts of complaints per IP, tie it to account data drawn from your billing / radius etc systems .. most of the work you are having your abuse team do is entirely automatable. And a waste of their time to do manually. As providers, I suppose we must apologize for not making this sufficiently clear even to normally clued admins at other sites .. though several sites do seem to be consuming it just fine, and we send high volume feedback loops to hotmail/yahoo/aol etc, and they to us, without my team having to do anything much manually, its mostly automated. http://postmaster.info.aol.com/fbl/ does link to arffilter by the way. --srs From jrhett at netconsonance.com Tue Mar 24 22:46:38 2009 From: jrhett at netconsonance.com (Jo Rhett) Date: Tue, 24 Mar 2009 20:46:38 -0700 Subject: Yahoo and their mail filters.. In-Reply-To: References: <49A80252.40401@pacific.net> <49C94008.1010307@brightok.net> <49C94F9D.1040301@labrats.us> Message-ID: Suresh, in theory I like what you say but this caught my eye: On Mar 24, 2009, at 6:50 PM, Suresh Ramasubramanian wrote: > though several sites do seem to be consuming it just fine, and we send > high volume feedback loops to hotmail/yahoo/aol etc, and they to us, > without my team having to do anything much manually, its mostly > automated. I would like to point out that gmail abuse reports appear to be entirely ignored. I've been reporting and rereporting everything from spam floods to phishing attacks that were very good looking/tricky to abuse at gmail.com and report them again in 2 days, report the exact same one again in 2 days, etc. Yes, you've automated your report processing to the point you don't actually have to do any work. The problem is... you aren't doing the work. You aren't stopping the offenders. That's the goal. Automation should be a tool to help you do the job better, not avoid doing the job at all. -- Jo Rhett an abuse response administrator who reads *every* report sent to us, and takes action on *every* one of them. From ops.lists at gmail.com Tue Mar 24 23:00:35 2009 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Wed, 25 Mar 2009 09:30:35 +0530 Subject: Yahoo and their mail filters.. In-Reply-To: References: <49A80252.40401@pacific.net> <49C94008.1010307@brightok.net> <49C94F9D.1040301@labrats.us> Message-ID: On Wed, Mar 25, 2009 at 9:16 AM, Jo Rhett wrote: > Yes, you've automated your report processing to the point you don't actually > have to do any work. > > The problem is... you aren't doing the work. ?You aren't stopping the > offenders. ?That's the goal. ?Automation should be a tool to help you do the > job better, not avoid doing the job at all. And yes indeed, its a way for us to automate termination of spammers, and to discover other patterns (in signup methods / spam content etc) that we can use to update our filters. There's a whole lot of maawg best practices (some work in progress, on outbound abuse / webmail abuse) that deal with these issues. To others in this thread - If your feedback loops are actually very low volume - you are likely to find a higher percentage of person to person email. And you may not have a problem at all, in which case you can simply treat feedback loops as an irritant, or as an early warning mechanism in case something does go wrong. If on the other hand your loop traffic is actually high volume (thousands a day or more) then you probably do have a spam problem, and ARF is there to provide you near real time notification about such problems -- Suresh Ramasubramanian (ops.lists at gmail.com) From j at arpa.com Wed Mar 25 00:33:58 2009 From: j at arpa.com (jamie rishaw) Date: Wed, 25 Mar 2009 00:33:58 -0500 Subject: Akamai wierdness In-Reply-To: <49C921AD.7030306@gmail.com> References: <0bda01c9ab4a$7513a0c0$64904002@TAKA> <89D27DE3375BB6428DDCC2927489826A021B71EE@nexus.nexicomgroup.net> <0c0a01c9ab58$4bc31e40$64904002@TAKA> <385D08D6-35CC-40EF-ACC3-7B5D6E84A27E@ianai.net> <620fd17c0903230718n5fa15e75nbd1ea5581ea656d2@mail.gmail.com> <620fd17c0903232247w543ff2d0s70444843e337c90e@mail.gmail.com> <49C921AD.7030306@gmail.com> Message-ID: On Tue, Mar 24, 2009 at 1:08 PM, JC Dill wrote: > > The reply I received came from someone who works in the NOC, not from > Patrick (who doesn't work in the NOC). > > It's really poor form to make these unfounded assertions without any basis > for them. > jc [Akamai customer. Hi.] Akamai customer support is ccare at . It's in all the literature, and their support site. You're arguing a suboptimal answer. Customers with issues should use Akamai Edgecontrol. This is from the horse's mouth[1]. They can also use, and anyone can use, the ccare@ box. The ccare@ email address interfaces to Edgecontrol and tons of other Akamai sorcery[2], which does a whole bunch of jedi nunchuckery[3], giving the ops tech a lot more info out of the gate. Anyone claiming noc@ : not the place for issues to go to, and Akamai will tell you that.[4] Moving on, nation : What bugs me about this thread(thanks for asking!) is that someone posted to the list, trying to troubleshoot a problem affecting multiple customers. He tried (brace yourself) collaboration, and was met with a quasi shot across the bow from someone At That Company. If you want to judge (how do I configure my router for that?), I'd point to the key employee of said vendor, who, instead of replying to the poster with a ticket number and ownership, "posted to 10k strangers" a snarky comment that one shouldnt post "to 10k strangers". Orly. Now, I have nothing against anyone in this situation - we all get testy.. arguably, I am now ;-) Not looking to start a flame war. E-mail who you want. Obligatory Win : Someone wrote in this thread earlier re emailing noc@ and getting an email back in 17 minutes. For what it's worth, I forwarded the original two posts to *ccare@* (before the war) (with no other contact info, specifically stating it was someone else's problem) and got a phone call in less than five. Whut whut? If only /all/ vendors' systems were that good.. -j. [1] www.akamai.com/html/support/ [2] www.akamai.com/html/technology/ [3] i believe that is the technical term they used, yes. [4] +1 877 4 akatec. -- Jamie Rishaw // .com.arpa at j <- reverse it. ish. [Impressive C-level Title Here], arpa / arpa labs From jcdill.lists at gmail.com Wed Mar 25 01:21:16 2009 From: jcdill.lists at gmail.com (JC Dill) Date: Tue, 24 Mar 2009 23:21:16 -0700 Subject: Akamai wierdness In-Reply-To: References: <0bda01c9ab4a$7513a0c0$64904002@TAKA> <89D27DE3375BB6428DDCC2927489826A021B71EE@nexus.nexicomgroup.net> <0c0a01c9ab58$4bc31e40$64904002@TAKA> <385D08D6-35CC-40EF-ACC3-7B5D6E84A27E@ianai.net> <620fd17c0903230718n5fa15e75nbd1ea5581ea656d2@mail.gmail.com> <620fd17c0903232247w543ff2d0s70444843e337c90e@mail.gmail.com> <49C921AD.7030306@gmail.com> Message-ID: <49C9CD5C.8010006@gmail.com> jamie rishaw wrote: > Akamai customer support is ccare at . > Anyone claiming noc@ : not the place for issues to go to, and Akamai will > tell you that.[4] > No one said that noc@ was "not the place" - someone (who works at Akamai) said that the RFC specified noc@ works, and it does. Someone else said it didn't work, and that person was incorrect (as my testing proves) - perhaps the NOC has better things to do than engage with a nym/troll when it "tests" if the noc@ address works or not. To summarize: The RFC-specified noc@ address exists and works. Customers also have/know about ccare@ which also works. Non-customers (surprise - not everyone is an Akamai customer, and non-customers do have valid reasons to contact a NOC now and then) who don't know about the super sekret[1] ccare@ can use noc at . Is there some point you wanted to make that contradicts all of this? jc [1] TIN(Sekret)C From jrhett at netconsonance.com Wed Mar 25 01:22:45 2009 From: jrhett at netconsonance.com (Jo Rhett) Date: Tue, 24 Mar 2009 23:22:45 -0700 Subject: Yahoo and their mail filters.. In-Reply-To: References: <49A80252.40401@pacific.net> <49C94008.1010307@brightok.net> <49C94F9D.1040301@labrats.us> Message-ID: <7984D520-4168-40B6-9B92-1BBA189FEDCA@netconsonance.com> > On Wed, Mar 25, 2009 at 9:16 AM, Jo Rhett > wrote: >> The problem is... you aren't doing the work. You aren't stopping the >> offenders. That's the goal. Automation should be a tool to help >> you do the >> job better, not avoid doing the job at all. On Mar 24, 2009, at 9:00 PM, Suresh Ramasubramanian wrote: > And yes indeed, its a way for us to automate termination of spammers, > and to discover other patterns (in signup methods / spam content etc) > that we can use to update our filters. That's a great theory. Would you be willing to post an update to this list if and when your technology and automation actually get to the point of actually shutting down a spammer? > There's a whole lot of maawg best practices (some work in progress, on > outbound abuse / webmail abuse) that deal with these issues. No, see, that's the problem. Best Practices don't deal with abuse reports. Humans deal with abuse reports. You can collect and sort and collate your spam reports all day. What about the part where a human looks at the report, confirms that it is spam, and terminates the customer? You've got to do that. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From ops.lists at gmail.com Wed Mar 25 01:29:59 2009 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Wed, 25 Mar 2009 11:59:59 +0530 Subject: Yahoo and their mail filters.. In-Reply-To: <7984D520-4168-40B6-9B92-1BBA189FEDCA@netconsonance.com> References: <49A80252.40401@pacific.net> <49C94008.1010307@brightok.net> <49C94F9D.1040301@labrats.us> <7984D520-4168-40B6-9B92-1BBA189FEDCA@netconsonance.com> Message-ID: On Wed, Mar 25, 2009 at 11:52 AM, Jo Rhett wrote: > That's a great theory. ?Would you be willing to post an update to this list > if and when your technology and automation actually get to the point of > actually shutting down a spammer? I am not sure that'd be a very productive use of my time seeing you dont seem to believe me in any case. But yes, we do terminate quite a few spammer accounts based on this automation. --srs From jeffrey.k.cohen at gmail.com Wed Mar 25 02:44:51 2009 From: jeffrey.k.cohen at gmail.com (Jeffrey Cohen) Date: Wed, 25 Mar 2009 02:44:51 -0500 Subject: Akamai wierdness Message-ID: <6864f3b00903250044j557495d0q6ff17cd2cef4f9b2@mail.gmail.com> On Wed, Mar 25, 2009 at 1:21 AM, JC Dill wrote: | jamie rishaw wrote: | | | | Akamai customer support is ccare at . | | No one said that noc@ was "not the place" - someone (who works at Akamai) | said that the RFC specified noc@ works, and it does. it was a redirect, and he was pretty rude | To summarize: The RFC-specified noc@ address exists and works. it is an rfc, not a standard. check out bcp 46. according to that, the correct answer we are looking for would be hostmaster-billing at akamai.com. both documents are out of date, and to suggest otherwise is irresponsible | Customers also have/know | about ccare@ which also works. Non-customers (surprise - not everyone is an | Akamai customer, and non-customers do have valid reasons to contact a NOC | now and then) who don't know about the super sekret[1] ccare@ can use noc@ . the first click off the akamai root page is hardly "super sekret". although they are really sneaky about it. its called 'support' and it is big and bright and blue and right where you would expect it. quite the outrage | Is there some point you wanted to make that contradicts all of this? jcdill, are you eight? this is a mailing list for network professionals. if you cannot be at, at least act it jkc -- Jeff Cohen CISSP, CCNP On a Sesame Seed Bun. Opinions stated are my own, and not those of Turner. From johnl at iecc.com Wed Mar 25 06:52:20 2009 From: johnl at iecc.com (John Levine) Date: 25 Mar 2009 11:52:20 -0000 Subject: Yahoo and their mail filters.. In-Reply-To: <7984D520-4168-40B6-9B92-1BBA189FEDCA@netconsonance.com> Message-ID: <20090325115220.25451.qmail@simone.iecc.com> >> And yes indeed, its a way for us to automate termination of spammers, >> and to discover other patterns (in signup methods / spam content etc) >> that we can use to update our filters. > >That's a great theory. Would you be willing to post an update to this >list if and when your technology and automation actually get to the >point of actually shutting down a spammer? Um, perhaps this would be a good time to do a little background research and see who Suresh is and what he does. R's, John From rcorbin at traffiq.com Wed Mar 25 07:30:33 2009 From: rcorbin at traffiq.com (Ray Corbin) Date: Wed, 25 Mar 2009 07:30:33 -0500 Subject: Yahoo and their mail filters.. In-Reply-To: <7984D520-4168-40B6-9B92-1BBA189FEDCA@netconsonance.com> Message-ID: I thought that this was discussed not too long ago... Since these are standardized emails you can easily automate this to generate reports for your employees to look through. This way you can see patterns and take action. For instance if you get a single complaint against a customer then it likely isn't a big deal, but if you start getting multiple complaints about a user you might want to investigate the account and read further into what the message included says. Alternatively you could remove yourself from the voluntary FBL since you don't see the benefit of it. They aren't saying 'this is spam', they are saying 'this is what was reported to us as spam'. The ma & pa emails that get flagged aren't going to cause you to be blocked if you have some mail volume. -r > -----Original Message----- > From: Jo Rhett [mailto:jrhett at netconsonance.com] > Sent: Wednesday, March 25, 2009 2:23 AM > To: Suresh Ramasubramanian > Cc: nanog at nanog.org > Subject: Re: Yahoo and their mail filters.. > > > On Wed, Mar 25, 2009 at 9:16 AM, Jo Rhett > > wrote: > >> The problem is... you aren't doing the work. You aren't stopping the > >> offenders. That's the goal. Automation should be a tool to help > >> you do the > >> job better, not avoid doing the job at all. > > On Mar 24, 2009, at 9:00 PM, Suresh Ramasubramanian wrote: > > And yes indeed, its a way for us to automate termination of spammers, > > and to discover other patterns (in signup methods / spam content etc) > > that we can use to update our filters. > > That's a great theory. Would you be willing to post an update to this > list if and when your technology and automation actually get to the > point of actually shutting down a spammer? > > > There's a whole lot of maawg best practices (some work in progress, on > > outbound abuse / webmail abuse) that deal with these issues. > > No, see, that's the problem. Best Practices don't deal with abuse > reports. Humans deal with abuse reports. You can collect and sort > and collate your spam reports all day. What about the part where a > human looks at the report, confirms that it is spam, and terminates > the customer? You've got to do that. > > -- > Jo Rhett > Net Consonance : consonant endings by net philanthropy, open source > and other randomness > > > From ge at linuxbox.org Wed Mar 25 07:38:24 2009 From: ge at linuxbox.org (Gadi Evron) Date: Wed, 25 Mar 2009 13:38:24 +0100 Subject: phishing attacks against ISPs (also with Google translations) Message-ID: <49CA25C0.70601@linuxbox.org> In this email message I'd like to discuss two subjects: a. Phishing against ISPs. b. Phishing in different languages against ISPs as soon as Google adds a new translation module. [My apologies to those who receive this email more than once. I am approaching several different industries on this matter] In the past few weeks there has been an increasing number of phishing attacks against clients of Israeli ISPs. I've only seen a few of these, but the local ISPs confirm it's happening across the board. In all these cases, the phishing email is in Hebrew. While we have seen ISP phishing and Hebrew phishing before, these attacks started when Google added translation into Hebrew. Is this a trend? Have other countries (or populations) been targeted when Google added a translation module for more languages? Notes: a. Some Israeli ISPs emailed their clients warning against such attacks. Saying they'd never ask for their password, etc. b. While I was certainly heavily involved with phishing originally and even started the first coordination group to deal with the issue, I am somewhat removed from it now, dealing more with phishing/banking Trojan horses. Can anyone educate me as to how often ISPs get phished, if at all? c. If you get phished, what strategies if any have you taken to prevent the attacks/respond to them/educate your clients? What worked? d. I wonder if these translation misuses could eventually translate into some intelligence we will see in Google security reports, such as on malware. Gadi. From john-nanog at johnpeach.com Wed Mar 25 08:35:49 2009 From: john-nanog at johnpeach.com (John Peach) Date: Wed, 25 Mar 2009 09:35:49 -0400 Subject: Yahoo and their mail filters.. In-Reply-To: <20090325115220.25451.qmail@simone.iecc.com> References: <7984D520-4168-40B6-9B92-1BBA189FEDCA@netconsonance.com> <20090325115220.25451.qmail@simone.iecc.com> Message-ID: <20090325093549.6738884b@milhouse.peachfamily.net> On 25 Mar 2009 11:52:20 -0000 John Levine wrote: > >> And yes indeed, its a way for us to automate termination of > >> spammers, and to discover other patterns (in signup methods / spam > >> content etc) that we can use to update our filters. > > > >That's a great theory. Would you be willing to post an update to > >this list if and when your technology and automation actually get to > >the point of actually shutting down a spammer? > > Um, perhaps this would be a good time to do a little background > research and see who Suresh is and what he does. > Indeed it would; I know from experience that Suresh's automation works. -- John From pauldotwall at gmail.com Wed Mar 25 08:55:40 2009 From: pauldotwall at gmail.com (Paul Wall) Date: Wed, 25 Mar 2009 08:55:40 -0500 Subject: phishing attacks against ISPs (also with Google translations) In-Reply-To: <49CA25C0.70601@linuxbox.org> References: <49CA25C0.70601@linuxbox.org> Message-ID: <620fd17c0903250655u1e9d8170y4fd8eac7aafa54d4@mail.gmail.com> On Wed, Mar 25, 2009 at 7:38 AM, Gadi Evron wrote: > In this email message I'd like to discuss two subjects: That makes one of us, > b. Phishing in different languages against ISPs as soon as Google adds a > new translation module. > > In the past few weeks there has been an increasing number of phishing > attacks against clients of Israeli ISPs. I've only seen a few of these, > but the local ISPs confirm it's happening across the board. Confirmed. Not more than two days after google added its /intl/xx-bork/ translation site, my best friend, (he's Swedish - a high profile Chef), told me he was scammed out of thousands of dollars by someone on the internet that he didnt know. (actually his words were "Eye lost all mee moolah on der webs! Its der Googol web-en page-en! Eye don know whatta think-a, bork bork bork!"). .. On a more serious note, how does this relate to network operations? > In all these cases, the phishing email is in Hebrew. While we have seen > ISP phishing and Hebrew phishing before, these > attacks started when Google added translation into Hebrew. Since at the time Google added Hebrew translations, they also added 1. Vietnamese, 2. Slovak, 3. Serbian, 4. Catalan, 5. Filipino, 6. Indonesian, 7. Latvian, 8. Lithuanian, 9. Hebrew, and 10. Ukranian, Any reasonable person might assume that your 1/11th of new languages would make up a little less than 100% of what is probably hand-picked "data". Your data, or, to wit, your attempts to link Google and Phishing, need(s) some work. And by "needs some work" one might mean "are full of fail, try again later" Is this a trend? Have other countries (or populations) been targeted > when Google added a translation module for more languages? ^^ Insert blatant attempts to get unfounded interviews with clueless media here. ^^ Router(enable)# no ip mailing-list crazy From william.allen.simpson at gmail.com Wed Mar 25 11:02:00 2009 From: william.allen.simpson at gmail.com (William Allen Simpson) Date: Wed, 25 Mar 2009 12:02:00 -0400 Subject: phishing attacks against ISPs (also with Google translations) In-Reply-To: <620fd17c0903250655u1e9d8170y4fd8eac7aafa54d4@mail.gmail.com> References: <49CA25C0.70601@linuxbox.org> <620fd17c0903250655u1e9d8170y4fd8eac7aafa54d4@mail.gmail.com> Message-ID: <49CA5578.2080008@gmail.com> Paul Wall wrote: > That makes one of us, > Paul, please refrain from silly attacks, as your message didn't provide anything substantive for this list. And your attempts at derisive humor weren't amusing. Grow up. === I've not recently seen an ISP account phish here. The last one I remember was circa 2003. It was a dictionary attack, arriving at my was@ account (long since rendered useless by spam volume and terminated). However, I don't save phish/spam anymore. I used to save everything -- providing many of the examples for http://fraudgallery.com/ -- nowadays, just daily scan for false positives, report monetary phish to the few ISPs that actually promptly close down bad actors, and delete the rest. Good luck, Gadi. From psirt at cisco.com Wed Mar 25 11:00:00 2009 From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team) Date: Wed, 25 Mar 2009 17:00:00 +0100 Subject: Cisco Security Advisory: Cisco IOS cTCP Denial of Service Vulnerability Message-ID: <200903251705.ctcp@psirt.cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Cisco Security Advisory: Cisco IOS cTCP Denial of Service Vulnerability Advisory ID: cisco-sa-20090325-ctcp http://www.cisco.com/warp/public/707/cisco-sa-20090325-ctcp.shtml Revision 1.0 For Public Release 2009 March 25 1600 UTC (GMT) - --------------------------------------------------------------------- Summary ======= A series of TCP packets may cause a denial of service (DoS) condition on Cisco IOS devices that are configured as Easy VPN servers with the Cisco Tunneling Control Protocol (cTCP) encapsulation feature. Cisco has released free software updates that address this vulnerability. No workarounds are available; however, the IPSec NAT traversal (NAT-T) feature can be used as an alternative. This advisory is posted at http://www.cisco.com/warp/public/707/cisco-sa-20090325-ctcp.shtml Note: The March 25, 2009, Cisco IOS Security Advisory bundled publication includes eight Security Advisories. All of the advisories address vulnerabilities in Cisco IOS Software. Each advisory lists the releases that correct the vulnerability or vulnerabilities in the advisory. The following table lists releases that correct all Cisco IOS Software vulnerabilities that have been published in Cisco Security Advisories on March 25, 2009, or earlier. http://www.cisco.com/warp/public/707/cisco-sa-20090325-bundle.shtml Individual publication links are listed below: * Cisco IOS cTCP Denial of Service Vulnerability http://www.cisco.com/warp/public/707/cisco-sa-20090325-ctcp.shtml * Cisco IOS Software Multiple Features IP Sockets Vulnerability http://www.cisco.com/warp/public/707/cisco-sa-20090325-ip.shtml * Cisco IOS Software Mobile IP and Mobile IPv6 Vulnerabilities http://www.cisco.com/warp/public/707/cisco-sa-20090325-mobileip.shtml * Cisco IOS Software Secure Copy Privilege Escalation Vulnerability http://www.cisco.com/warp/public/707/cisco-sa-20090325-scp.shtml * Cisco IOS Software Session Initiation Protocol Denial of Service Vulnerability http://www.cisco.com/warp/public/707/cisco-sa-20090325-sip.shtml * Cisco IOS Software Multiple Features Crafted TCP Sequence Vulnerability http://www.cisco.com/warp/public/707/cisco-sa-20090325-tcp.shtml * Cisco IOS Software Multiple Features Crafted UDP Packet Vulnerability http://www.cisco.com/warp/public/707/cisco-sa-20090325-udp.shtml * Cisco IOS Software WebVPN and SSLVPN Vulnerabilities http://www.cisco.com/warp/public/707/cisco-sa-20090325-webvpn.shtml Affected Products ================= Vulnerable Products +------------------ Cisco IOS devices running versions 12.4(9)T or later and configured for Cisco Tunneling Control Protocol (cTCP) encapsulation for EZVPN server are vulnerable. Note: The cTCP encapsulation feature was introduced in Cisco IOS version 12.4(9)T. The cTCP encapsulation feature is disabled by default. Cisco IOS devices configured for EZVPN client are not affected by this vulnerability. Only devices configured as EZVPN servers are vulnerable. To configure the cTCP encapsulation feature for Easy VPN, use the crypto ctcp command in global configuration mode. You can optionally specify the port number that the device will listen to with the crypto ctcp port command. Up to ten numbers can be configured and the port value can be from 1 through 65535. If the port keyword is not configured, the default port number is 10000. In the following example, the Cisco IOS device is configured to listen for cTCP messages on port 10000. crypto ctcp port 10000 Note: The port keyword is configured only on the Cisco IOS device acting as an EZVPN server. To determine the version of the Cisco IOS software running on a Cisco product, log in to the device and issue the show version command to display the system banner. Cisco IOS software will identify itself as "Internetwork Operating System Software" or simply "IOS". On the next line of output, the image name will be displayed between parentheses, followed by "Version" and the IOS release name. Other Cisco devices will not have the show version command or will give different output. The following example identifies a Cisco product running Cisco IOS Software release 12.3(26) with an installed image name of C2500-IS-L: Router#show version Cisco Internetwork Operating System Software IOS (tm) 2500 Software (C2500-IS-L), Version 12.3(26), RELEASE SOFTWARE (fc2) Technical Support: http://www.cisco.com/techsupport Copyright (c) 1986-2008 by cisco Systems, Inc. Compiled Mon 17-Mar-08 14:39 by dchih The next example shows a product running Cisco IOS Software release 12.4(20)T with an image name of C1841-ADVENTERPRISEK9-M: Router#show version Cisco IOS Software, 1841 Software (C1841-ADVENTERPRISEK9-M), Version 12.4(20)T, RELEASE SOFTWARE (fc3) Technical Support: http://www.cisco.com/techsupport Copyright (c) 1986-2008 by Cisco Systems, Inc. Compiled Thu 10-Jul-08 20:25 by prod_rel_team Additional information on the Cisco IOS release naming conventions can be found on the document entitled "White Paper: Cisco IOS Reference Guide", which is available at http://www.cisco.com/warp/public/620/1.html Products Confirmed Not Vulnerable +-------------------------------- Cisco IOS devices that are not configured for cTCP are not affected by this vulnerability. The Cisco ASA and Cisco VPN 3000 series concentrators are not vulnerable. Cisco IOS devices configured as EZVPN clients are not affected by this vulnerability. The Cisco VPN Client is not vulnerable. Cisco IOS-XR and Cisco IOS-XE software are not affected by this vulnerability. No other Cisco products are currently known to be affected by this vulnerability. Details ======= The Cisco Tunneling Control Protocol (cTCP) feature is used by Easy VPN remote device operating in an environment in which standard IPSec does not function transparently without modification to existing firewall rules. The cTCP traffic is actually TCP traffic. Cisco IOS cTCP packets are Internet Key Exchange (IKE) or Encapsulating Security Payload (ESP) packets that are being transmitted over TCP. A vulnerability exists where a series of TCP packets may cause a Cisco IOS device that is configured as an Easy VPN server with the cTCP encapsulation feature to run out of memory. This vulnerability is documented in Cisco Bug IDs CSCsr16693 and CSCsu21828; and has been assigned the Common Vulnerabilities and Exposures (CVE) identifier CVE-2009-0635. Vulnerability Scoring Details ============================= Cisco has provided scores for the vulnerability in this advisory based on the Common Vulnerability Scoring System (CVSS). The CVSS scoring in this Security Advisory is done in accordance with CVSS version 2.0. CVSS is a standards-based scoring method that conveys vulnerability severity and helps determine urgency and priority of response. Cisco has provided a base and temporal score. Customers can then compute environmental scores to assist in determining the impact of the vulnerability in individual networks. Cisco has provided an FAQ to answer additional questions regarding CVSS at http://www.cisco.com/web/about/security/intelligence/cvss-qandas.html Cisco has also provided a CVSS calculator to help compute the environmental impact for individual networks at http://intellishield.cisco.com/security/alertmanager/cvss. CSCsr16693 - cTCP server may crash when processing a series of TCP packets CVSS Base Score - 7.8 Access Vector - Network Access Complexity - Low Authentication - None Confidentiality Impact - None Integrity Impact - None Availability Impact - Complete CVSS Temporal Score - 6.4 Exploitability - Functional Remediation Level - Official-Fix Report Confidence - Confirmed CSCsu21828 - Cisco IOS Device may crash with cTCP enabled CVSS Base Score - 7.8 Access Vector - Network Access Complexity - Low Authentication - None Confidentiality Impact - None Integrity Impact - None Availability Impact - Complete CVSS Temporal Score - 6.4 Exploitability - Functional Remediation Level - Official-Fix Report Confidence - Confirmed Impact ====== Successful exploitation of this vulnerability may cause the affected device to run out of memory. Repeated exploitation will result in a denial of service (DoS) condition. Software Versions and Fixes =========================== When considering software upgrades, also consult http://www.cisco.com/go/psirt and any subsequent advisories to determine exposure and a complete upgrade solution. In all cases, customers should exercise caution to be certain the devices to be upgraded contain sufficient memory and that current hardware and software configurations will continue to be supported properly by the new release. If the information is not clear, contact the Cisco Technical Assistance Center (TAC) or your contracted maintenance provider for assistance. Each row of the Cisco IOS software table (below) names a Cisco IOS release train. If a given release train is vulnerable, then the earliest possible releases that contain the fix (along with the anticipated date of availability for each, if applicable) are listed in the "First Fixed Release" column of the table. The "Recommended Release" column indicates the releases which have fixes for all the published vulnerabilities at the time of this Advisory. A device running a release in the given train that is earlier than the release in a specific column (less than the First Fixed Release) is known to be vulnerable. Cisco recommends upgrading to a release equal to or later than the release in the "Recommended Releases" column of the table. +-------------------------------------------------------------------+ | Major Release | Availability of Repaired Releases | |-------------------+-----------------------------------------------| | Affected | | | | 12.0-Based | First Fixed Release | Recommended Release | | Releases | | | |-------------------------------------------------------------------| | There are no affected 12.0 based releases | |-------------------------------------------------------------------| | Affected | | | | 12.1-Based | First Fixed Release | Recommended Release | | Releases | | | |-------------------------------------------------------------------| | There are no affected 12.1 based releases | |-------------------------------------------------------------------| | Affected | | | | 12.2-Based | First Fixed Release | Recommended Release | | Releases | | | |-------------------------------------------------------------------| | There are no affected 12.2 based releases | |-------------------------------------------------------------------| | Affected | | | | 12.3-Based | First Fixed Release | Recommended Release | | Releases | | | |-------------------------------------------------------------------| | There are no affected 12.3 based releases | |-------------------------------------------------------------------| | Affected | | | | 12.4-Based | First Fixed Release | Recommended Release | | Releases | | | |-------------------+-----------------------+-----------------------| | 12.4 | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.4JA | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.4JDA | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.4JK | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.4JL | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.4JMA | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.4JMB | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.4JX | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.4MD | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.4MR | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.4SW | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | | 12.4(20)T2 | 12.4(22)T1 | | 12.4T | | | | | 12.4(15)T9; Available | 12.4(15)T9; Available | | | on 29-APR-2009 | on 29-APR-2009 | |-------------------+-----------------------+-----------------------| | 12.4XA | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.4XB | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.4XC | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.4XD | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.4XE | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.4XF | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.4XG | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.4XJ | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.4XK | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.4XL | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.4XM | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.4XN | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.4XP | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.4XQ | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.4XR | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.4XT | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.4XV | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.4XW | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.4XY | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.4XZ | 12.4(15)XZ2 | 12.4(15)XZ2 | |-------------------+-----------------------+-----------------------| | 12.4YA | 12.4(20)YA2 | 12.4(20)YA3 | |-------------------+-----------------------+-----------------------| | 12.4YB | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.4YD | Not Vulnerable | | +-------------------------------------------------------------------+ Workarounds =========== No workarounds are available. As an alternative, the IPSec NAT traversal (NAT-T) feature can be used. The IPSec NAT-T feature introduces support for IP Security (IPSec) traffic to travel through Network Address Translation (NAT) or Port Address Translation (PAT) points in the network by addressing many known incompatabilites between NAT and IPSec. Note: The NAT-T feature was introduced in Cisco IOS version 12.2(13) T. NAT Traversal is a feature that is auto detected by VPN devices. There are no configuration steps for a router running Cisco IOS Release 12.2(13)T and later. If both VPN devices are NAT-T capable, NAT Traversal is auto-detected and auto-negotiated. Note: When you enable NAT-T, the Cisco IOS device automatically opens UDP port 4500 on all IPSec enabled interfaces. Caution: Be aware that you may need to enable IPSec over UDP on Cisco VPN software clients to support NAT-T. Additionally, you may need to change firewall rules to allow UDP port 500 for Internet Key Exchange (IKE) and UDP port 4500 for NAT-T. For more information about NAT-T, refer to the white paper at: http://www.cisco.com/en/US/docs/ios/security/configuration/guide/sec_ipsec_nat_transp.html Additional mitigations that can be deployed on Cisco devices within the network are available in the Cisco Applied Mitigation Bulletin companion document for this advisory, which is available at the following link: http://www.cisco.com/warp/public/707/cisco-amb-20090325-ctcp.shtml Obtaining Fixed Software ======================== Cisco has released free software updates that address this vulnerability. Prior to deploying software, customers should consult their maintenance provider or check the software for feature set compatibility and known issues specific to their environment. Customers may only install and expect support for the feature sets they have purchased. By installing, downloading, accessing or otherwise using such software upgrades, customers agree to be bound by the terms of Cisco's software license terms found at http://www.cisco.com/en/US/docs/general/warranty/English/EU1KEN_.html or as otherwise set forth at Cisco.com Downloads at http://www.cisco.com/public/sw-center/sw-usingswc.shtml Do not contact psirt at cisco.com or security-alert at cisco.com for software upgrades. Customers with Service Contracts +------------------------------- Customers with contracts should obtain upgraded software through their regular update channels. For most customers, this means that upgrades should be obtained through the Software Center on Cisco's worldwide website at http://www.cisco.com. Customers using Third Party Support Organizations +------------------------------------------------ Customers whose Cisco products are provided or maintained through prior or existing agreements with third-party support organizations, such as Cisco Partners, authorized resellers, or service providers should contact that support organization for guidance and assistance with the appropriate course of action in regards to this advisory. The effectiveness of any workaround or fix is dependent on specific customer situations, such as product mix, network topology, traffic behavior, and organizational mission. Due to the variety of affected products and releases, customers should consult with their service provider or support organization to ensure any applied workaround or fix is the most appropriate for use in the intended network before it is deployed. Customers without Service Contracts +---------------------------------- Customers who purchase direct from Cisco but do not hold a Cisco service contract, and customers who purchase through third-party vendors but are unsuccessful in obtaining fixed software through their point of sale should acquire upgrades by contacting the Cisco Technical Assistance Center (TAC). TAC contacts are as follows. * +1 800 553 2447 (toll free from within North America) * +1 408 526 7209 (toll call from anywhere in the world) * e-mail: tac at cisco.com Customers should have their product serial number available and be prepared to give the URL of this notice as evidence of entitlement to a free upgrade. Free upgrades for non-contract customers must be requested through the TAC. Refer to http://www.cisco.com/en/US/support/tsd_cisco_worldwide_contacts.html for additional TAC contact information, including localized telephone numbers, and instructions and e-mail addresses for use in various languages. Exploitation and Public Announcements ===================================== The Cisco PSIRT is not aware of any public announcements or malicious use of the vulnerability described in this advisory. This vulnerability was found during the resolution of a technical support service request. Status of this Notice: FINAL ============================ THIS DOCUMENT IS PROVIDED ON AN "AS IS" BASIS AND DOES NOT IMPLY ANY KIND OF GUARANTEE OR WARRANTY, INCLUDING THE WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR USE. YOUR USE OF THE INFORMATION ON THE DOCUMENT OR MATERIALS LINKED FROM THE DOCUMENT IS AT YOUR OWN RISK. CISCO RESERVES THE RIGHT TO CHANGE OR UPDATE THIS DOCUMENT AT ANY TIME. A stand-alone copy or Paraphrase of the text of this document that omits the distribution URL in the following section is an uncontrolled copy, and may lack important information or contain factual errors. Distribution ============ This advisory is posted on Cisco's worldwide website at: http://www.cisco.com/warp/public/707/cisco-sa-20090325-ctcp.shtml In addition to worldwide web posting, a text version of this notice is clear-signed with the Cisco PSIRT PGP key and is posted to the following e-mail and Usenet news recipients. * cust-security-announce at cisco.com * first-bulletins at lists.first.org * bugtraq at securityfocus.com * vulnwatch at vulnwatch.org * cisco at spot.colorado.edu * cisco-nsp at puck.nether.net * full-disclosure at lists.grok.org.uk * comp.dcom.sys.cisco at newsgate.cisco.com Future updates of this advisory, if any, will be placed on Cisco's worldwide website, but may or may not be actively announced on mailing lists or newsgroups. Users concerned about this problem are encouraged to check the above URL for any updates. Revision History ================ +---------------------------------------+ | Revision | | Initial | | 1.0 | 2009-March-25 | public | | | | release. | +---------------------------------------+ Cisco Security Procedures ========================= Complete information on reporting security vulnerabilities in Cisco products, obtaining assistance with security incidents, and registering to receive security information from Cisco, is available on Cisco's worldwide website at http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html This includes instructions for press inquiries regarding Cisco security notices. All Cisco security advisories are available at http://www.cisco.com/go/psirt -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAknKUaYACgkQ86n/Gc8U/uBSWwCbBgAQRNBNdft9MYK8bC1MP/Z4 4D8AnA7qaiFqAdeWWbS+p4K601XNoo4S =Rvhp -----END PGP SIGNATURE----- From psirt at cisco.com Wed Mar 25 11:00:00 2009 From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team) Date: Wed, 25 Mar 2009 17:00:00 +0100 Subject: Cisco Security Advisory: Cisco IOS Software Mobile IP and Mobile IPv6 Vulnerabilities Message-ID: <200903251705.mobileip@psirt.cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Cisco Security Advisory: Cisco IOS Software Mobile IP and Mobile IPv6 Vulnerabilities Advisory ID: cisco-sa-20090325-mobileip http://www.cisco.com/warp/public/707/cisco-sa-20090325-mobileip.shtml Revision 1.0 For Public Release 2009 March 25 1600 UTC (GMT) - --------------------------------------------------------------------- Summary ======= Devices that are running Cisco IOS Software and configured for Mobile IP Network Address Translation (NAT) Traversal feature or Mobile IPv6 are vulnerable to a denial of service (DoS) attack that may result in a blocked interface. Cisco has released free software updates that address these vulnerabilities. This advisory is posted at the following link http://www.cisco.com/warp/public/707/cisco-sa-20090325-mobileip.shtml Note: The March 25, 2009, Cisco IOS Security Advisory bundled publication includes eight Security Advisories. All of the advisories address vulnerabilities in Cisco IOS Software. Each advisory lists the releases that correct the vulnerability or vulnerabilities in the advisory. The following table lists releases that correct all Cisco IOS Software vulnerabilities that have been published in Cisco Security Advisories on March 25, 2009, or earlier. http://www.cisco.com/warp/public/707/cisco-sa-20090325-bundle.shtml Individual publication links are listed below: * Cisco IOS cTCP Denial of Service Vulnerability http://www.cisco.com/warp/public/707/cisco-sa-20090325-ctcp.shtml * Cisco IOS Software Multiple Features IP Sockets Vulnerability http://www.cisco.com/warp/public/707/cisco-sa-20090325-ip.shtml * Cisco IOS Software Mobile IP and Mobile IPv6 Vulnerabilities http://www.cisco.com/warp/public/707/cisco-sa-20090325-mobileip.shtml * Cisco IOS Software Secure Copy Privilege Escalation Vulnerability http://www.cisco.com/warp/public/707/cisco-sa-20090325-scp.shtml * Cisco IOS Software Session Initiation Protocol Denial of Service Vulnerability http://www.cisco.com/warp/public/707/cisco-sa-20090325-sip.shtml * Cisco IOS Software Multiple Features Crafted TCP Sequence Vulnerability http://www.cisco.com/warp/public/707/cisco-sa-20090325-tcp.shtml * Cisco IOS Software Multiple Features Crafted UDP Packet Vulnerability http://www.cisco.com/warp/public/707/cisco-sa-20090325-udp.shtml * Cisco IOS Software WebVPN and SSLVPN Vulnerabilities http://www.cisco.com/warp/public/707/cisco-sa-20090325-webvpn.shtml Affected Products ================= Devices that are running an affected version of Cisco IOS Software and configured for Mobile IP NAT Traversal feature or Mobile IPv6 are vulnerable. Vulnerable Products +------------------ Devices running Cisco IOS Software and configured for Mobile IP NAT Traversal feature will have a line similar to the following in the output of the show running-config command: ip mobile home-agent nat traversal [...] or ip mobile foreign-agent nat traversal [...] or ip mobile router-service collocated registration nat traversal [...] Devices running Cisco IOS Software and configured for Mobile IPv6 will have a line similar to the following in the output of the show running-config command: ipv6 mobile home-agent To determine the Cisco IOS Software release that is running on a Cisco product, administrators can log in to the device and issue the show version command to display the system banner. The system banner confirms that the device is running Cisco IOS Software by displaying text similar to "Cisco Internetwork Operating System Software" or "Cisco IOS Software." The image name displays in parentheses, followed by "Version" and the Cisco IOS Software release name. Other Cisco devices do not have the show version command or may provide different output. The following example identifies a Cisco product that is running Cisco IOS Software Release 12.3(26) with an installed image name of C2500-IS-L: Router#show version Cisco Internetwork Operating System Software IOS (tm) 2500 Software (C2500-IS-L), Version 12.3(26), RELEASE SOFTWARE (fc2) Technical Support: http://www.cisco.com/techsupport Copyright (c) 1986-2008 by cisco Systems, Inc. Compiled Mon 17-Mar-08 14:39 by dchih !--- output truncated The following example identifies a Cisco product that is running Cisco IOS Software Release 12.4(20)T with an installed image name of C1841-ADVENTERPRISEK9-M: Router#show version Cisco IOS Software, 1841 Software (C1841-ADVENTERPRISEK9-M), Version 12.4(20)T, RELEASE SOFTWARE (fc3) Technical Support: http://www.cisco.com/techsupport Copyright (c) 1986-2008 by Cisco Systems, Inc. Compiled Thu 10-Jul-08 20:25 by prod_rel_team !--- output truncated Additional information about Cisco IOS Software release naming conventions is available in "White Paper: Cisco IOS Reference Guide" at the following link: http://www.cisco.com/warp/public/620/1.html Products Confirmed Not Vulnerable +-------------------------------- Cisco IOS XR is not affected by these vulnerabilities. Cisco IOS XE is not affected by these vulnerabilities. No other Cisco products are currently known to be affected by these vulnerabilities. Details ======= Mobile IP is part of both IPv4 and IPv6 standards. Mobile IP allows a host device to be identified by a single IP address even though the device may move its physical point of attachment from one network to another. Regardless of movement between different networks, connectivity at the different points is achieved seamlessly without user intervention. Roaming from a wired network to a wireless or wide-area network is also possible. More information on Mobile IPv6 can be found at the following link: http://www.cisco.com/en/US/docs/ios/ipv6/configuration/guide/ip6-mobile.html The Mobile IP Support NAT Traversal feature is documented in RFC 3519. It introduces an alternative method for tunneling Mobile IP data traffic. New extensions in the Mobile IP registration request and reply messages have been added for establishing User Datagram Protocol (UDP) tunneling. This feature allows mobile devices in collocated mode that use a private IP address (RFC 1918) or foreign agents (FAs) that use a private IP address for the care-of address (CoA) to establish a tunnel and traverse a NAT-enabled router with mobile node (MN) data traffic from the home agent (HA). More information on Mobile IP NAT Traversal feature can be found at the following link: http://www.cisco.com/en/US/docs/ios/12_3t/12_3t8/feature/guide/gtnatmip.html Devices that are running an affected version of Cisco IOS Software and configured for Mobile IPv6 or Mobile IP NAT Traversal feature are affected by a DoS vulnerability. A successful exploitation of this vulnerability could cause an interface to stop processing traffic until the system is restarted. Offending packets need to be destined to the router for a successful exploit. These vulnerabilities are documented in the Cisco Bug IDs CSCsm97220 and CSCso05337 and have been assigned Common Vulnerabilities and Exposures (CVE) IDs CVE-2009-0633 and CVE-2009-0634. Vulnerability Scoring Details ============================= Cisco has provided scores for the vulnerabilities in this advisory based on the Common Vulnerability Scoring System (CVSS). The CVSS scoring in this Security Advisory is done in accordance with CVSS version 2.0. CVSS is a standards-based scoring method that conveys vulnerability severity and helps determine urgency and priority of response. Cisco has provided a base and temporal score. Customers can then compute environmental scores to assist in determining the impact of the vulnerability in individual networks. Cisco has provided an FAQ to answer additional questions regarding CVSS at http://www.cisco.com/web/about/security/intelligence/cvss-qandas.html Cisco has also provided a CVSS calculator to help compute the environmental impact for individual networks at http://intellishield.cisco.com/security/alertmanager/cvss CSCsm97220 - Input queue wedged by MIPv6 packets CVSS Base Score - 7.8 Access Vector - Network Access Complexity - Low Authentication - None Confidentiality Impact - None Integrity Impact - None Availability Impact - Complete CVSS Temporal Score - 6.4 Exploitability - Functional Remediation Level - Official-Fix Report Confidence - Confirmed CSCso05337 - HA: Input queue wedged by ICMP packet CVSS Base Score - 7.1 Access Vector - Network Access Complexity - Medium Authentication - None Confidentiality Impact - None Integrity Impact - None Availability Impact - Complete CVSS Temporal Score - 5.9 Exploitability - Functional Remediation Level - Official-Fix Report Confidence - Confirmed Impact ====== Successful exploitation of the vulnerability may result in an interface to stop processing traffic, causing a DoS condition. Software Versions and Fixes =========================== When considering software upgrades, also consult http://www.cisco.com/go/psirt and any subsequent advisories to determine exposure and a complete upgrade solution. In all cases, customers should exercise caution to be certain the devices to be upgraded contain sufficient memory and that current hardware and software configurations will continue to be supported properly by the new release. If the information is not clear, contact the Cisco Technical Assistance Center (TAC) or your contracted maintenance provider for assistance. Each row of the Cisco IOS software table (below) names a Cisco IOS release train. If a given release train is vulnerable, then the earliest possible releases that contain the fix (along with the anticipated date of availability for each, if applicable) are listed in the "First Fixed Release" column of the table. The "Recommended Release" column indicates the releases which have fixes for all the published vulnerabilities at the time of this Advisory. A device running a release in the given train that is earlier than the release in a specific column (less than the First Fixed Release) is known to be vulnerable. Cisco recommends upgrading to a release equal to or later than the release in the "Recommended Releases" column of the table. +-------------------------------------------------------------------+ | Major | Availability of Repaired Releases | | Release | | |------------+------------------------------------------------------| | Affected | | Recommended | | 12.0-Based | First Fixed Release | Release | | Releases | | | |-------------------------------------------------------------------| | There are no affected 12.0 based releases | |-------------------------------------------------------------------| | Affected | | Recommended | | 12.1-Based | First Fixed Release | Release | | Releases | | | |-------------------------------------------------------------------| | There are no affected 12.1 based releases | |-------------------------------------------------------------------| | Affected | | Recommended | | 12.2-Based | First Fixed Release | Release | | Releases | | | |-------------------------------------------------------------------| | There are no affected 12.2 based releases | |-------------------------------------------------------------------| | Affected | | Recommended | | 12.3-Based | First Fixed Release | Release | | Releases | | | |------------+--------------------------------------+---------------| | 12.3 | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3B | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3BC | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3BW | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3EU | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3JA | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3JEA | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3JEB | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3JEC | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3JK | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3JL | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3JX | Not Vulnerable | | |------------+--------------------------------------+---------------| | | | 12.4(22)T1 | | | | | | 12.3T | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+--------------------------------------+---------------| | 12.3TPC | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3VA | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3XA | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3XB | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3XC | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3XD | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3XE | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3XF | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3XG | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3XI | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3XJ | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3XK | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3XL | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3XQ | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3XR | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3XS | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3XU | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3XW | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3XX | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3XY | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3XZ | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3YA | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3YD | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3YF | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3YG | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3YH | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3YI | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3YJ | Not Vulnerable | | |------------+--------------------------------------+---------------| | | Releases prior to 12.3(11)YK3 are | 12.4(22)T1 | | | vulnerable, release 12.3(11)YK3 and | | | 12.3YK | later are not vulnerable; first | 12.4(15)T9; | | | fixed in 12.4T | Available on | | | | 29-APR-2009 | |------------+--------------------------------------+---------------| | 12.3YM | 12.3(14)YM13 | 12.3(14)YM13 | |------------+--------------------------------------+---------------| | | | 12.4(22)T1 | | | | | | 12.3YQ | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+--------------------------------------+---------------| | | | 12.4(22)T1 | | | | | | 12.3YS | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+--------------------------------------+---------------| | | | 12.4(22)T1 | | | | | | 12.3YT | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+--------------------------------------+---------------| | | | 12.4(22)T1 | | | | | | 12.3YU | Vulnerable; migrate to 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+--------------------------------------+---------------| | | Releases prior to 12.3(14)YX10 are | | | 12.3YX | vulnerable, release 12.3(14)YX10 and | 12.3(14)YX14 | | | later are not vulnerable; | | |------------+--------------------------------------+---------------| | 12.3YZ | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3ZA | Not Vulnerable | | |------------+--------------------------------------+---------------| | Affected | | Recommended | | 12.4-Based | First Fixed Release | Release | | Releases | | | |------------+--------------------------------------+---------------| | | | 12.4(18e) | | | 12.4(18e) | | | 12.4 | | 12.4(23a); | | | 12.4(23a); Available on 30-APR-2009 | Available on | | | | 30-APR-2009 | |------------+--------------------------------------+---------------| | 12.4JA | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.4JDA | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.4JK | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.4JL | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.4JMA | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.4JMB | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.4JX | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.4MD | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.4MR | 12.4(19)MR | 12.4(19)MR2 | |------------+--------------------------------------+---------------| | 12.4SW | Not Vulnerable | | |------------+--------------------------------------+---------------| | | 12.4(20)T | 12.4(22)T1 | | | | | | 12.4T | 12.4(15)T8 | 12.4(15)T9; | | | | Available on | | | 12.4(15)T9; Available on 29-APR-2009 | 29-APR-2009 | |------------+--------------------------------------+---------------| | | | 12.4(22)T1 | | | | | | 12.4XA | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+--------------------------------------+---------------| | | 12.4(15)T8 | 12.4(22)T1 | | | | | | 12.4XB | 12.4(20)T | 12.4(15)T9; | | | | Available on | | | 12.4(15)T9; Available on 29-APR-2009 | 29-APR-2009 | |------------+--------------------------------------+---------------| | | | 12.4(22)T1 | | | | | | 12.4XC | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+--------------------------------------+---------------| | | 12.4(4)XD12; Available on | 12.4(4)XD12; | | 12.4XD | 27-MAR-2009 | Available on | | | | 27-MAR-2009 | |------------+--------------------------------------+---------------| | | | 12.4(22)T1 | | | | | | 12.4XE | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+--------------------------------------+---------------| | | | 12.4(22)T1 | | | | | | 12.4XF | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+--------------------------------------+---------------| | 12.4XG | Not Vulnerable | | |------------+--------------------------------------+---------------| | | | 12.4(22)T1 | | | | | | 12.4XJ | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+--------------------------------------+---------------| | 12.4XK | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.4XL | 12.4(15)XL4 | 12.4(15)XL4 | |------------+--------------------------------------+---------------| | | | 12.4(22)T1 | | | | | | 12.4XM | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+--------------------------------------+---------------| | 12.4XN | Vulnerable; contact TAC | | |------------+--------------------------------------+---------------| | 12.4XP | Vulnerable; contact TAC | | |------------+--------------------------------------+---------------| | 12.4XQ | 12.4(15)XQ2 | 12.4(15)XQ2 | |------------+--------------------------------------+---------------| | 12.4XR | 12.4(15)XR4 | 12.4(22)T1 | |------------+--------------------------------------+---------------| | | | 12.4(22)T1 | | | | | | 12.4XT | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+--------------------------------------+---------------| | 12.4XV | Vulnerable; contact TAC | | |------------+--------------------------------------+---------------| | 12.4XW | 12.4(11)XW10 | 12.4(11)XW10 | |------------+--------------------------------------+---------------| | | | 12.4(22)T1 | | | | | | 12.4XY | 12.4(15)XY4 | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+--------------------------------------+---------------| | 12.4XZ | 12.4(15)XZ1 | 12.4(15)XZ2 | |------------+--------------------------------------+---------------| | 12.4YA | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.4YB | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.4YD | Not Vulnerable | | +-------------------------------------------------------------------+ Workarounds =========== The following mitigation and identification methods have been identified for these vulnerabilities: Infrastructure Access Control Lists +---------------------------------- Although it is often difficult to block traffic that transits a network, it is possible to identify traffic that should never be allowed to target infrastructure devices and block that traffic at the border of networks. Infrastructure Access Control Lists (iACLs) are a network security best practice and should be considered as a long-term addition to good network security as well as a workaround for these specific vulnerabilities. The iACL example below should be included as part of the deployed infrastructure access-list which will protect all devices with IP addresses in the infrastructure IP address range: IPv4 example: !--- Anti-spoofing entries are shown here. !--- Deny special-use address sources. !--- Refer to RFC 3330 for additional special use addresses. access-list 110 deny ip host 0.0.0.0 any access-list 110 deny ip 127.0.0.0 0.255.255.255 any access-list 110 deny ip 192.0.2.0 0.0.0.255 any access-list 110 deny ip 224.0.0.0 31.255.255.255 any !--- Filter RFC 1918 space. access-list 110 deny ip 10.0.0.0 0.255.255.255 any access-list 110 deny ip 172.16.0.0 0.15.255.255 any access-list 110 deny ip 192.168.0.0 0.0.255.255 any !--- Deny your space as source from entering your AS. !--- Deploy only at the AS edge. access-list 110 deny ip YOUR_CIDR_BLOCK any !--- Permit BGP. access-list 110 permit tcp host bgp_peer host router_ip eq bgp access-list 110 permit tcp host bgp_peer eq bgp host router_ip !--- Deny access to internal infrastructure addresses. access-list 110 deny ip any INTERNAL_INFRASTRUCTURE_ADDRESSES !--- Permit transit traffic. access-list 110 permit ip any any IPv6 example: !--- Configure the access-list. ipv6 access-list iacl !--- Deny your space as source from entering your AS. !--- Deploy only at the AS edge. deny ipv6 YOUR_CIDR_BLOCK_IPV6 any !--- Permit multiprotocol BGP. permit tcp host bgp_peer_ipv6 host router_ipv6 eq bgp permit tcp host bgp_peer_ipv6 eq bgp host router_ipv6 !--- Deny access to internal infrastructure addresses. deny ipv6 any INTERNAL_INFRASTRUCTURE_ADDRESSES_IPV6 !--- Permit transit traffic. permit ipv6 any any The white paper entitled "Protecting Your Core: Infrastructure Protection Access Control Lists" presents guidelines and recommended deployment techniques for infrastructure protection access lists. This white paper can be obtained at the following link http://www.cisco.com/en/US/tech/tk648/tk361/technologies_white_paper09186a00801a1a55.shtml Cisco IOS Embedded Event Manager +------------------------------- It is possible to detect blocked interface queues with a Cisco IOS Embedded Event Manager (EEM) policy. EEM provides event detection and reaction capabilities on a Cisco IOS device. EEM can alert administrators of blocked interfaces with email, a syslog message, or a Simple Network Management Protocol (SNMP) trap. A sample EEM policy that uses syslog to alert administrators of blocked interfaces is available at Cisco Beyond, an online community dedicated to EEM. A sample script is available at the following link: http://forums.cisco.com/eforum/servlet/EEM?page=eem&fn=script&scriptId=981 More information about EEM is available from Cisco.com at the following link: http://www.cisco.com/en/US/products/ps6815/products_ios_protocol_group_home.html Obtaining Fixed Software ======================== Cisco has released free software updates that address these vulnerabilities. Prior to deploying software, customers should consult their maintenance provider or check the software for feature set compatibility and known issues specific to their environment. Customers may only install and expect support for the feature sets they have purchased. By installing, downloading, accessing or otherwise using such software upgrades, customers agree to be bound by the terms of Cisco's software license terms found at http://www.cisco.com/en/US/docs/general/warranty/English/EU1KEN_.html, or as otherwise set forth at Cisco.com Downloads at http://www.cisco.com/public/sw-center/sw-usingswc.shtml Do not contact psirt at cisco.com or security-alert at cisco.com for software upgrades. Customers with Service Contracts +------------------------------- Customers with contracts should obtain upgraded software through their regular update channels. For most customers, this means that upgrades should be obtained through the Software Center on Cisco's worldwide website at http://www.cisco.com Customers using Third Party Support Organizations +------------------------------------------------ Customers whose Cisco products are provided or maintained through prior or existing agreements with third-party support organizations, such as Cisco Partners, authorized resellers, or service providers should contact that support organization for guidance and assistance with the appropriate course of action in regards to this advisory. The effectiveness of any workaround or fix is dependent on specific customer situations, such as product mix, network topology, traffic behavior, and organizational mission. Due to the variety of affected products and releases, customers should consult with their service provider or support organization to ensure any applied workaround or fix is the most appropriate for use in the intended network before it is deployed. Customers without Service Contracts +---------------------------------- Customers who purchase direct from Cisco but do not hold a Cisco service contract, and customers who purchase through third-party vendors but are unsuccessful in obtaining fixed software through their point of sale should acquire upgrades by contacting the Cisco Technical Assistance Center (TAC). TAC contacts are as follows. * +1 800 553 2447 (toll free from within North America) * +1 408 526 7209 (toll call from anywhere in the world) * e-mail: tac at cisco.com Customers should have their product serial number available and be prepared to give the URL of this notice as evidence of entitlement to a free upgrade. Free upgrades for non-contract customers must be requested through the TAC. Refer to http://www.cisco.com/en/US/support/tsd_cisco_worldwide_contacts.html for additional TAC contact information, including localized telephone numbers, and instructions and e-mail addresses for use in various languages. Exploitation and Public Announcements ===================================== The Cisco PSIRT is not aware of any public announcements or malicious use of the vulnerability described in this advisory. This vulnerability was reported to Cisco by a customer. Status of this Notice: FINAL ============================ THIS DOCUMENT IS PROVIDED ON AN "AS IS" BASIS AND DOES NOT IMPLY ANY KIND OF GUARANTEE OR WARRANTY, INCLUDING THE WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR USE. YOUR USE OF THE INFORMATION ON THE DOCUMENT OR MATERIALS LINKED FROM THE DOCUMENT IS AT YOUR OWN RISK. CISCO RESERVES THE RIGHT TO CHANGE OR UPDATE THIS DOCUMENT AT ANY TIME. A stand-alone copy or Paraphrase of the text of this document that omits the distribution URL in the following section is an uncontrolled copy, and may lack important information or contain factual errors. Distribution ============ This advisory is posted on Cisco's worldwide website at : http://www.cisco.com/warp/public/707/cisco-sa-20090325-mobileip.shtml In addition to worldwide web posting, a text version of this notice is clear-signed with the Cisco PSIRT PGP key and is posted to the following e-mail and Usenet news recipients. * cust-security-announce at cisco.com * first-bulletins at lists.first.org * bugtraq at securityfocus.com * vulnwatch at vulnwatch.org * cisco at spot.colorado.edu * cisco-nsp at puck.nether.net * full-disclosure at lists.grok.org.uk * comp.dcom.sys.cisco at newsgate.cisco.com Future updates of this advisory, if any, will be placed on Cisco's worldwide website, but may or may not be actively announced on mailing lists or newsgroups. Users concerned about this problem are encouraged to check the above URL for any updates. Revision History ================ +---------------------------------------+ | Revision | | Initial | | 1.0 | 2009-Mar-25 | public | | | | release | +---------------------------------------+ Cisco Security Procedures ========================= Complete information on reporting security vulnerabilities in Cisco products, obtaining assistance with security incidents, and registering to receive security information from Cisco, is available on Cisco's worldwide website at http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html This includes instructions for press inquiries regarding Cisco security notices. All Cisco security advisories are available at http://www.cisco.com/go/psirt -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAknKUa8ACgkQ86n/Gc8U/uBD0ACfYblb5Nscx1zIWMLeihiaZAe7 TtsAoIGgf8/ubiolVwSDmu/tCTgH8skm =YxAj -----END PGP SIGNATURE----- From psirt at cisco.com Wed Mar 25 11:00:00 2009 From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team) Date: Wed, 25 Mar 2009 17:00:00 +0100 Subject: Cisco Security Advisory: Cisco IOS Software Secure Copy Privilege Escalation Vulnerability Message-ID: <200903251705.scp@psirt.cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Cisco Security Advisory: Cisco IOS Software Secure Copy Privilege Escalation Vulnerability Advisory ID: cisco-sa-20090325-scp http://www.cisco.com/warp/public/707/cisco-sa-20090325-scp.shtml Revision 1.0 For Public Release 2009 March 25 1600 UTC (GMT) - --------------------------------------------------------------------- Summary ======= The server side of the Secure Copy (SCP) implementation in Cisco IOS software contains a vulnerability that could allow authenticated users with an attached command-line interface (CLI) view to transfer files to and from a Cisco IOS device that is configured to be an SCP server, regardless of what users are authorized to do, per the CLI view configuration. This vulnerability could allow valid users to retrieve or write to any file on the device's file system, including the device's saved configuration and Cisco IOS image files, even if the CLI view attached to the user does not allow it. This configuration file may include passwords or other sensitive information. The Cisco IOS SCP server is an optional service that is disabled by default. CLI views are a fundamental component of the Cisco IOS Role-Based CLI Access feature, which is also disabled by default. Devices that are not specifically configured to enable the Cisco IOS SCP server, or that are configured to use it but do not use role-based CLI access, are not affected by this vulnerability. This vulnerability does not apply to the Cisco IOS SCP client feature. Cisco has released free software updates that address this vulnerability. There are no workarounds available for this vulnerability apart from disabling either the SCP server or the CLI view feature if these services are not required by administrators. This advisory is posted at the following link: http://www.cisco.com/warp/public/707/cisco-sa-20090325-scp.shtml Note: The March 25, 2009, Cisco IOS Security Advisory bundled publication includes eight Security Advisories. All of the advisories address vulnerabilities in Cisco IOS Software. Each advisory lists the releases that correct the vulnerability or vulnerabilities in the advisory. The following table lists releases that correct all Cisco IOS Software vulnerabilities that have been published in Cisco Security Advisories on March 25, 2009, or earlier. http://www.cisco.com/warp/public/707/cisco-sa-20090325-bundle.shtml Individual publication links are listed below: * Cisco IOS cTCP Denial of Service Vulnerability http://www.cisco.com/warp/public/707/cisco-sa-20090325-ctcp.shtml * Cisco IOS Software Multiple Features IP Sockets Vulnerability http://www.cisco.com/warp/public/707/cisco-sa-20090325-ip.shtml * Cisco IOS Software Mobile IP and Mobile IPv6 Vulnerabilities http://www.cisco.com/warp/public/707/cisco-sa-20090325-mobileip.shtml * Cisco IOS Software Secure Copy Privilege Escalation Vulnerability http://www.cisco.com/warp/public/707/cisco-sa-20090325-scp.shtml * Cisco IOS Software Session Initiation Protocol Denial of Service Vulnerability http://www.cisco.com/warp/public/707/cisco-sa-20090325-sip.shtml * Cisco IOS Software Multiple Features Crafted TCP Sequence Vulnerability http://www.cisco.com/warp/public/707/cisco-sa-20090325-tcp.shtml * Cisco IOS Software Multiple Features Crafted UDP Packet Vulnerability http://www.cisco.com/warp/public/707/cisco-sa-20090325-udp.shtml * Cisco IOS Software WebVPN and SSLVPN Vulnerabilities http://www.cisco.com/warp/public/707/cisco-sa-20090325-webvpn.shtml Affected Products ================= Vulnerable Products +------------------ Cisco devices running an affected Cisco IOS software release, configured to offer SCP server functionality, and configured to use role-based ACL access are affected by this issue. A device running a vulnerable Cisco IOS software release is affected if its configuration is similar to the following: parser view ! username view secret ! ip scp server enable In the above configuration snippet, the parser view command defines a view that specifies what commands users in that view can execute. The username command defines a local user and attaches, via the view keyword, the previously defined view to the user. And finally, the ip scp server enable command enables the Cisco IOS SCP server. The absence of the username command does not guarantee that the device's configuration is not affected by this vulnerability because the name of a CLI view can be supplied by means of an Authentication, Authorization, and Accounting (AAA) server by using the cli-view-name attribute. Note: The CLI view attached to a user can be supplied by a AAA server. When inspecting a device's configuration to determine if it is affected by this vulnerability it is better to check if the SCP service is enabled (ip scp server enabled command) and whether there are any CLI views defined (parser view command). The Cisco IOS SCP server and role-based CLI access features are disabled by default. The SCP server functionality is only available on encryption-capable images. Encryption-capable images are those that contain either a "k8" or "k9" in the image name, for example, "C7200-ADVSECURITYK9-M". Devices that do not run encryption-capable images are not vulnerable. If a device is running an encryption-capable image, the presence in the configuration of the ip scp server enable command, the existence of CLI views (parser view command), and whether there are users (local or remote) attached to these views will determine if the device is affected. To determine the Cisco IOS Software release that is running on a Cisco product, administrators can log in to the device and issue the show version command to display the system banner. The system banner confirms that the device is running Cisco IOS Software by displaying text similar to "Cisco Internetwork Operating System Software" or "Cisco IOS Software." The image name displays in parentheses, followed by "Version" and the Cisco IOS Software release name. Other Cisco devices do not have the show version command or may provide different output. The following example identifies a Cisco product that is running Cisco IOS Software Release 12.3(26) with an installed image name of C2500-IS-L: Router#show version Cisco Internetwork Operating System Software IOS (tm) 2500 Software (C2500-IS-L), Version 12.3(26), RELEASE SOFTWARE (fc2) Technical Support: http://www.cisco.com/techsupport Copyright (c) 1986-2008 by cisco Systems, Inc. Compiled Mon 17-Mar-08 14:39 by dchih !--- output truncated The following example identifies a Cisco product that is running Cisco IOS Software Release 12.4(20)T with an installed image name of C1841-ADVENTERPRISEK9-M: Router#show version Cisco IOS Software, 1841 Software (C1841-ADVENTERPRISEK9-M), Version 12.4(20)T, RELEASE SOFTWARE (fc3) Technical Support: http://www.cisco.com/techsupport Copyright (c) 1986-2008 by Cisco Systems, Inc. Compiled Thu 10-Jul-08 20:25 by prod_rel_team !--- output truncated Additional information about Cisco IOS Software release naming conventions is available in "White Paper: Cisco IOS Reference Guide" at the following link: http://www.cisco.com/warp/public/620/1.html Cisco IOS XE Software is also affected by this vulnerability. Products Confirmed Not Vulnerable +-------------------------------- Cisco devices that do not run Cisco IOS software are not affected. Cisco IOS devices that do not have the SCP server feature enabled, or that make use of the feature but do not have the role-based CLI feature enabled, are not affected. Cisco IOS XR Software is not affected. No other Cisco products are currently known to be affected by this vulnerability. Details ======= SCP is a protocol similar to the Remote Copy (RCP) protocol, which allows the transfer of files between systems. The main difference between SCP and RCP is that in SCP, all aspects of the file transfer session, including authentication, occur in encrypted form, which makes SCP a more secure alternative than RCP. SCP relies on the Secure Shell (SSH) protocol, which uses TCP port 22 by default. The Role-Based CLI Access feature allows the network administrator to define "views". Views are sets of operational commands and configuration capabilities that provide selective or partial access to Cisco IOS software EXEC and configuration (Config) mode commands. Views restrict user access to Cisco IOS command-line interface (CLI) and configuration information; that is, a view can define what commands are accepted and what configuration information is visible. For more information about the Role-Based CLI Access feature, reference http://www.cisco.com/en/US/docs/ios/12_3t/12_3t7/feature/guide/gtclivws.html The server side of the SCP implementation in Cisco IOS software contains a vulnerability that allows authenticated users with an attached command-line interface (CLI) view to transfer files to and from a Cisco IOS device that is configured to be a SCP server, regardless of what users are authorized to do, per the CLI view configuration. This vulnerability could allow authenticated users to retrieve or write to any file on the device's file system, including the device's saved configuration and Cisco IOS image files. This configuration file may include passwords or other sensitive information. In the affected configuration presented in the Affected Products section, users confined to a CLI view can elevate their privileges by using SCP to write to the device's configuration. Note that a view can be attached to a user when defining the user in the local database (via the username view ... command), or by passing the attribute cli-view-name from an AAA server. This vulnerability does not allow for authentication bypass; login credentials are verified and access is only granted if a valid username and password is provided. This vulnerability may cause authorization to be bypassed. This vulnerability is documented in the Cisco Bug ID CSCsv38166 and has been assigned Common Vulnerabilities and Exposures (CVE) ID CVE-2009-0637. Vulnerability Scoring Details ============================== Cisco has provided scores for the vulnerabilities in this advisory based on the Common Vulnerability Scoring System (CVSS). The CVSS scoring in this Security Advisory is done in accordance with CVSS version 2.0. CVSS is a standards-based scoring method that conveys vulnerability severity and helps determine urgency and priority of response. Cisco has provided a base and temporal score. Customers can then compute environmental scores to assist in determining the impact of the vulnerability in individual networks. Cisco has provided an FAQ to answer additional questions regarding CVSS at http://www.cisco.com/web/about/security/intelligence/cvss-qandas.html Cisco has also provided a CVSS calculator to help compute the environmental impact for individual networks at http://intellishield.cisco.com/security/alertmanager/cvss CSCsv38166 - SCP + views (role-based CLI) allows privilege escalation CVSS Base Score - 9.0 Access Vector - Network Access Complexity - Low Authentication - Single Confidentiality Impact - Complete Integrity Impact - Complete Availability Impact - Complete CVSS Temporal Score - 7.4 Exploitability - Functional Remediation Level - Official-Fix Report Confidence - Confirmed Impact ====== Successful exploitation of the vulnerability described in this advisory may allow valid but unauthorized users to retrieve or write to any file on the device's file system, including the device's saved configuration and Cisco IOS image files. This configuration file may include passwords or other sensitive information. Software Versions and Fixes =========================== When considering software upgrades, also consult http://www.cisco.com/go/psirt and any subsequent advisories to determine exposure and a complete upgrade solution. In all cases, customers should exercise caution to be certain the devices to be upgraded contain sufficient memory and that current hardware and software configurations will continue to be supported properly by the new release. If the information is not clear, contact the Cisco Technical Assistance Center (TAC) or your contracted maintenance provider for assistance. Each row of the Cisco IOS software table (below) names a Cisco IOS release train. If a given release train is vulnerable, then the earliest possible releases that contain the fix (along with the anticipated date of availability for each, if applicable) are listed in the "First Fixed Release" column of the table. The "Recommended Release" column indicates the releases which have fixes for all the published vulnerabilities at the time of this Advisory. A device running a release in the given train that is earlier than the release in a specific column (less than the First Fixed Release) is known to be vulnerable. Cisco recommends upgrading to a release equal to or later than the release in the "Recommended Releases" column of the table. +-------------------------------------------------------------------+ | Major | Availability of Repaired Releases | | Release | | |------------+------------------------------------------------------| | Affected | | Recommended | | 12.0-Based | First Fixed Release | Release | | Releases | | | |-------------------------------------------------------------------| | There are no affected 12.0 based releases | |-------------------------------------------------------------------| | Affected | | Recommended | | 12.1-Based | First Fixed Release | Release | | Releases | | | |-------------------------------------------------------------------| | There are no affected 12.1 based releases | |-------------------------------------------------------------------| | Affected | | Recommended | | 12.2-Based | First Fixed Release | Release | | Releases | | | |------------+------------------------------------+-----------------| | 12.2 | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.2B | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.2BC | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.2BW | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.2BX | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.2BY | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.2BZ | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.2CX | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.2CY | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.2CZ | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.2DA | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.2DD | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.2DX | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.2EW | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.2EWA | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.2EX | Vulnerable; migrate to any release | 12.2(44)SE6 | | | in 12.2SEG | | |------------+------------------------------------+-----------------| | 12.2EY | Vulnerable; first fixed in 12.2SE | 12.2(44)SE6 | |------------+------------------------------------+-----------------| | 12.2EZ | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.2FX | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.2FY | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.2FZ | Not Vulnerable | | |------------+------------------------------------+-----------------| | | | 12.2(33)SRC4; | | 12.2IRA | Vulnerable; first fixed in 12.2SRC | Available on | | | | 18-MAY-2009 | |------------+------------------------------------+-----------------| | | | 12.2(33)SRC4; | | 12.2IRB | Vulnerable; first fixed in 12.2SRC | Available on | | | | 18-MAY-2009 | |------------+------------------------------------+-----------------| | 12.2IXA | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.2IXB | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.2IXC | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.2IXD | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.2IXE | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.2IXF | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.2IXG | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.2JA | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.2JK | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.2MB | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.2MC | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.2S | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.2SB | 12.2(33)SB4 | 12.2(33)SB4 | |------------+------------------------------------+-----------------| | 12.2SBC | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.2SCA | Vulnerable; first fixed in 12.2SCB | 12.2(33)SCB1 | |------------+------------------------------------+-----------------| | 12.2SCB | 12.2(33)SCB1 | 12.2(33)SCB1 | |------------+------------------------------------+-----------------| | | 12.2(50)SE | | | 12.2SE | | 12.2(44)SE6 | | | 12.2(44)SE6 | | |------------+------------------------------------+-----------------| | 12.2SEA | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.2SEB | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.2SEC | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.2SED | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.2SEE | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.2SEF | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.2SEG | Not Vulnerable | | |------------+------------------------------------+-----------------| | | 12.2(52)SG; Available on | 12.2(52)SG; | | 12.2SG | 15-MAY-2009 | Available on | | | | 15-MAY-2009 | |------------+------------------------------------+-----------------| | 12.2SGA | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.2SL | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.2SM | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.2SO | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.2SQ | Vulnerable; contact TAC | | |------------+------------------------------------+-----------------| | 12.2SRA | Not Vulnerable | | |------------+------------------------------------+-----------------| | | | 12.2(33)SRC4; | | | | Available on | | | | 18-MAY-2009 | | 12.2SRB | Vulnerable; first fixed in 12.2SRC | | | | | 12.2(33)SRB5a; | | | | Available on | | | | 3-April-2009 | |------------+------------------------------------+-----------------| | | 12.2(33)SRC4; Available on | 12.2(33)SRC4; | | 12.2SRC | 18-MAY-2009 | Available on | | | | 18-MAY-2009 | |------------+------------------------------------+-----------------| | 12.2SRD | 12.2(33)SRD1 | 12.2(33)SRD1 | |------------+------------------------------------+-----------------| | 12.2STE | Vulnerable; contact TAC | | |------------+------------------------------------+-----------------| | 12.2SU | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.2SV | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.2SVA | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.2SVC | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.2SVD | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.2SVE | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.2SW | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.2SX | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.2SXA | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.2SXB | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.2SXD | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.2SXE | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.2SXF | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.2SXH | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.2SXI | 12.2(33)SXI1 | 12.2(33)SXI1 | |------------+------------------------------------+-----------------| | 12.2SY | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.2SZ | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.2T | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.2TPC | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.2XA | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.2XB | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.2XC | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.2XD | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.2XE | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.2XF | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.2XG | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.2XH | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.2XI | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.2XJ | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.2XK | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.2XL | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.2XM | Not Vulnerable | | |------------+------------------------------------+-----------------| | | | 12.2(33)SB4 | | | | | | | | 12.2(33)SRD1 | | 12.2XN | Vulnerable; first fixed in 12.2SRC | | | | | 12.2(33)SRC4; | | | | Available on | | | | 18-MAY-2009 | |------------+------------------------------------+-----------------| | | | 12.2(33)SRD1 | | | | | | 12.2XNA | Vulnerable; first fixed in 12.2SRD | 12.2(33)SRC4; | | | | Available on | | | | 18-MAY-2009 | |------------+------------------------------------+-----------------| | 12.2XNB | 12.2(33)XNB3 | 12.2(33)XNB3 | |------------+------------------------------------+-----------------| | 12.2XNC | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.2XO | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.2XQ | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.2XR | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.2XS | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.2XT | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.2XU | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.2XV | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.2XW | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.2YA | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.2YB | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.2YC | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.2YD | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.2YE | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.2YF | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.2YG | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.2YH | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.2YJ | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.2YK | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.2YL | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.2YM | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.2YN | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.2YO | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.2YP | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.2YQ | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.2YR | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.2YS | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.2YT | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.2YU | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.2YV | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.2YW | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.2YX | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.2YY | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.2YZ | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.2ZA | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.2ZB | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.2ZC | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.2ZD | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.2ZE | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.2ZF | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.2ZG | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.2ZH | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.2ZJ | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.2ZL | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.2ZP | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.2ZU | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.2ZX | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.2ZY | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.2ZYA | Not Vulnerable | | |------------+------------------------------------+-----------------| | Affected | | Recommended | | 12.3-Based | First Fixed Release | Release | | Releases | | | |------------+------------------------------------+-----------------| | 12.3 | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.3B | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.3BC | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.3BW | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.3EU | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.3JA | Vulnerable; contact TAC | | |------------+------------------------------------+-----------------| | 12.3JEA | Vulnerable; contact TAC | | |------------+------------------------------------+-----------------| | 12.3JEB | Vulnerable; contact TAC | | |------------+------------------------------------+-----------------| | 12.3JEC | Vulnerable; contact TAC | | |------------+------------------------------------+-----------------| | | | 12.4(22)T1 | | | | | | 12.3JK | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+------------------------------------+-----------------| | 12.3JL | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.3JX | Vulnerable; contact TAC | | |------------+------------------------------------+-----------------| | | | 12.4(22)T1 | | | | | | 12.3T | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+------------------------------------+-----------------| | 12.3TPC | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.3VA | Vulnerable; contact TAC | | |------------+------------------------------------+-----------------| | 12.3XA | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.3XB | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.3XC | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.3XD | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.3XE | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.3XF | Vulnerable; contact TAC | | |------------+------------------------------------+-----------------| | | | 12.4(22)T1 | | | | | | 12.3XG | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+------------------------------------+-----------------| | 12.3XI | Vulnerable; first fixed in 12.2SB | 12.2(33)SB4 | |------------+------------------------------------+-----------------| | 12.3XJ | Vulnerable; first fixed in 12.3YX | 12.3(14)YX14 | |------------+------------------------------------+-----------------| | | | 12.4(22)T1 | | | | | | 12.3XK | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+------------------------------------+-----------------| | | | 12.4(22)T1 | | | | | | 12.3XL | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+------------------------------------+-----------------| | | | 12.4(22)T1 | | | | | | 12.3XQ | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+------------------------------------+-----------------| | | | 12.4(18e) | | | | | | 12.3XR | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+------------------------------------+-----------------| | | | 12.4(22)T1 | | | | | | 12.3XS | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+------------------------------------+-----------------| | | | 12.4(22)T1 | | | | | | 12.3XU | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+------------------------------------+-----------------| | 12.3XW | Vulnerable; first fixed in 12.3YX | 12.3(14)YX14 | |------------+------------------------------------+-----------------| | | | 12.4(22)T1 | | | | | | 12.3XX | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+------------------------------------+-----------------| | | | 12.4(22)T1 | | | | | | 12.3XY | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+------------------------------------+-----------------| | 12.3XZ | Not Vulnerable | | |------------+------------------------------------+-----------------| | | | 12.4(22)T1 | | | | | | 12.3YA | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+------------------------------------+-----------------| | | | 12.4(22)T1 | | | | | | 12.3YD | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+------------------------------------+-----------------| | 12.3YF | Vulnerable; first fixed in 12.3YX | 12.3(14)YX14 | |------------+------------------------------------+-----------------| | | | 12.4(22)T1 | | | | | | 12.3YG | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+------------------------------------+-----------------| | | | 12.4(22)T1 | | | | | | 12.3YH | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+------------------------------------+-----------------| | | | 12.4(22)T1 | | | | | | 12.3YI | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+------------------------------------+-----------------| | | | 12.4(22)T1 | | | | | | 12.3YJ | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+------------------------------------+-----------------| | | | 12.4(22)T1 | | | | | | 12.3YK | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+------------------------------------+-----------------| | 12.3YM | 12.3(14)YM13 | 12.3(14)YM13 | |------------+------------------------------------+-----------------| | | | 12.4(22)T1 | | | | | | 12.3YQ | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+------------------------------------+-----------------| | | | 12.4(22)T1 | | | | | | 12.3YS | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+------------------------------------+-----------------| | | | 12.4(22)T1 | | | | | | 12.3YT | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+------------------------------------+-----------------| | | | 12.4(22)T1 | | | | | | 12.3YU | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+------------------------------------+-----------------| | 12.3YX | 12.3(14)YX14 | 12.3(14)YX14 | |------------+------------------------------------+-----------------| | 12.3YZ | Vulnerable; contact TAC | | |------------+------------------------------------+-----------------| | | | 12.4(22)T1 | | | | | | 12.3ZA | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+------------------------------------+-----------------| | Affected | | Recommended | | 12.4-Based | First Fixed Release | Release | | Releases | | | |------------+------------------------------------+-----------------| | | 12.4(18e) | 12.4(18e) | | | | | | 12.4 | 12.4(23a); Available on | 12.4(23a); | | | 30-APR-2009 | Available on | | | | 30-APR-2009 | |------------+------------------------------------+-----------------| | 12.4JA | Vulnerable; contact TAC | | |------------+------------------------------------+-----------------| | 12.4JDA | Vulnerable; contact TAC | | |------------+------------------------------------+-----------------| | 12.4JK | Vulnerable; contact TAC | | |------------+------------------------------------+-----------------| | 12.4JL | Vulnerable; contact TAC | | |------------+------------------------------------+-----------------| | 12.4JMA | Vulnerable; contact TAC | | |------------+------------------------------------+-----------------| | 12.4JMB | Vulnerable; contact TAC | | |------------+------------------------------------+-----------------| | 12.4JX | Vulnerable; contact TAC | | |------------+------------------------------------+-----------------| | 12.4MD | 12.4(11)MD7 | 12.4(11)MD7 | |------------+------------------------------------+-----------------| | 12.4MR | 12.4(19)MR2 | 12.4(19)MR2 | |------------+------------------------------------+-----------------| | 12.4SW | Vulnerable; contact TAC | | |------------+------------------------------------+-----------------| | | 12.4(24)T | | | | | 12.4(22)T1 | | | 12.4(20)T2 | | | 12.4T | | 12.4(15)T9; | | | 12.4(22)T1 | Available on | | | | 29-APR-2009 | | | 12.4(15)T9; Available on | | | | 29-APR-2009 | | |------------+------------------------------------+-----------------| | | | 12.4(22)T1 | | | | | | 12.4XA | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+------------------------------------+-----------------| | | | 12.4(22)T1 | | | | | | 12.4XB | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+------------------------------------+-----------------| | | | 12.4(22)T1 | | | | | | 12.4XC | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+------------------------------------+-----------------| | | 12.4(4)XD12; Available on | 12.4(4)XD12; | | 12.4XD | 27-MAR-2009 | Available on | | | | 27-MAR-2009 | |------------+------------------------------------+-----------------| | | | 12.4(22)T1 | | | | | | 12.4XE | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+------------------------------------+-----------------| | | | 12.4(22)T1 | | | | | | 12.4XF | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+------------------------------------+-----------------| | | | 12.4(22)T1 | | | 12.4(20)T2 | | | 12.4XG | | 12.4(15)T9; | | | 12.4(22)T1 | Available on | | | | 29-APR-2009 | |------------+------------------------------------+-----------------| | | | 12.4(22)T1 | | | | | | 12.4XJ | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+------------------------------------+-----------------| | | | 12.4(22)T1 | | | | | | 12.4XK | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+------------------------------------+-----------------| | | Releases prior to 12.4(15)XL4 are | | | 12.4XL | vulnerable, release 12.4(15)XL4 | 12.4(15)XL4 | | | and later are not vulnerable; | | |------------+------------------------------------+-----------------| | | | 12.4(22)T1 | | | | | | 12.4XM | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+------------------------------------+-----------------| | 12.4XN | Vulnerable; contact TAC | | |------------+------------------------------------+-----------------| | 12.4XP | Vulnerable; contact TAC | | |------------+------------------------------------+-----------------| | 12.4XQ | 12.4(15)XQ2 | 12.4(15)XQ2 | |------------+------------------------------------+-----------------| | | | 12.4(22)T1 | | | | | | 12.4XR | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+------------------------------------+-----------------| | | | 12.4(22)T1 | | | | | | 12.4XT | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+------------------------------------+-----------------| | 12.4XV | Vulnerable; contact TAC | | |------------+------------------------------------+-----------------| | 12.4XW | 12.4(11)XW10 | 12.4(11)XW10 | |------------+------------------------------------+-----------------| | | | 12.4(22)T1 | | | | | | 12.4XY | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+------------------------------------+-----------------| | 12.4XZ | 12.4(15)XZ2 | 12.4(15)XZ2 | |------------+------------------------------------+-----------------| | 12.4YA | 12.4(20)YA2 | 12.4(20)YA3 | |------------+------------------------------------+-----------------| | 12.4YB | Not Vulnerable | | |------------+------------------------------------+-----------------| | 12.4YD | Not Vulnerable | | +-------------------------------------------------------------------+ Workarounds =========== If the Cisco IOS SCP server functionality is not needed then the vulnerability described in this document can be mitigated by disabling the SCP server or the CLI view feature. The SCP server can be disabled by executing the following command in global configuration mode: no ip scp server enable If the SCP server cannot be disabled due to operational concerns, then no workarounds exist. The risk posed by this vulnerability can be mitigated by following the best practices detailed in "Cisco Guide to Harden Cisco IOS Devices" at http://www.cisco.com/en/US/tech/tk648/tk361/technologies_tech_note09186a0080120f48.shtml Please refer to the Obtaining Fixed Software section of this advisory for appropriate solutions to resolve this vulnerability. Due to the nature of this vulnerability, networking best practices like access control lists (ACLs) and Control Plane Policing (CoPP) that restrict access to a device to certain IP addresses or subnetworks may not be effective. If access is already granted to a specific IP address or subnetwork, a user with low privileges will be able to establish an SCP session with the device, which would allow the user to exploit this vulnerability. Obtaining Fixed Software ======================== Cisco has released free software updates that address these vulnerabilities. Prior to deploying software, customers should consult their maintenance provider or check the software for feature set compatibility and known issues specific to their environment. Customers may only install and expect support for the feature sets they have purchased. By installing, downloading, accessing or otherwise using such software upgrades, customers agree to be bound by the terms of Cisco's software license terms found at http://www.cisco.com/en/US/docs/general/warranty/English/EU1KEN_.html, or as otherwise set forth at Cisco.com Downloads at http://www.cisco.com/public/sw-center/sw-usingswc.shtml Do not contact psirt at cisco.com or security-alert at cisco.com for software upgrades. Customers with Service Contracts +------------------------------- Customers with contracts should obtain upgraded software through their regular update channels. For most customers, this means that upgrades should be obtained through the Software Center on Cisco's worldwide website at http://www.cisco.com Customers using Third Party Support Organizations +------------------------------------------------ Customers whose Cisco products are provided or maintained through prior or existing agreements with third-party support organizations, such as Cisco Partners, authorized resellers, or service providers should contact that support organization for guidance and assistance with the appropriate course of action in regards to this advisory. The effectiveness of any workaround or fix is dependent on specific customer situations, such as product mix, network topology, traffic behavior, and organizational mission. Due to the variety of affected products and releases, customers should consult with their service provider or support organization to ensure any applied workaround or fix is the most appropriate for use in the intended network before it is deployed. Customers without Service Contracts +---------------------------------- Customers who purchase direct from Cisco but do not hold a Cisco service contract, and customers who purchase through third-party vendors but are unsuccessful in obtaining fixed software through their point of sale should acquire upgrades by contacting the Cisco Technical Assistance Center (TAC). TAC contacts are as follows. * +1 800 553 2447 (toll free from within North America) * +1 408 526 7209 (toll call from anywhere in the world) * e-mail: tac at cisco.com Customers should have their product serial number available and be prepared to give the URL of this notice as evidence of entitlement to a free upgrade. Free upgrades for non-contract customers must be requested through the TAC. Refer to http://www.cisco.com/en/US/support/tsd_cisco_worldwide_contacts.html for additional TAC contact information, including localized telephone numbers, and instructions and e-mail addresses for use in various languages. Exploitation and Public Announcements ===================================== The Cisco PSIRT is not aware of any public announcements or malicious use of the vulnerability described in this advisory. This vulnerability was reported to Cisco by Kevin Graham. Cisco would like to thank Mr. Graham for reporting this vulnerability and working with us towards coordinated disclosure of the vulnerability. Status of this Notice: FINAL ============================ THIS DOCUMENT IS PROVIDED ON AN "AS IS" BASIS AND DOES NOT IMPLY ANY KIND OF GUARANTEE OR WARRANTY, INCLUDING THE WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR USE. YOUR USE OF THE INFORMATION ON THE DOCUMENT OR MATERIALS LINKED FROM THE DOCUMENT IS AT YOUR OWN RISK. CISCO RESERVES THE RIGHT TO CHANGE OR UPDATE THIS DOCUMENT AT ANY TIME. A stand-alone copy or Paraphrase of the text of this document that omits the distribution URL in the following section is an uncontrolled copy, and may lack important information or contain factual errors. Distribution ============ This advisory is posted on Cisco's worldwide website at : http://www.cisco.com/warp/public/707/cisco-sa-20090325-scp.shtml In addition to worldwide web posting, a text version of this notice is clear-signed with the Cisco PSIRT PGP key and is posted to the following e-mail and Usenet news recipients. * cust-security-announce at cisco.com * first-bulletins at lists.first.org * bugtraq at securityfocus.com * vulnwatch at vulnwatch.org * cisco at spot.colorado.edu * cisco-nsp at puck.nether.net * full-disclosure at lists.grok.org.uk * comp.dcom.sys.cisco at newsgate.cisco.com Future updates of this advisory, if any, will be placed on Cisco's worldwide website, but may or may not be actively announced on mailing lists or newsgroups. Users concerned about this problem are encouraged to check the above URL for any updates. Revision History ================ +---------------------------------------+ | Revision | | Initial | | 1.0 | 2009-March-25 | public | | | | release | +---------------------------------------+ Cisco Security Procedures ========================= Complete information on reporting security vulnerabilities in Cisco products, obtaining assistance with security incidents, and registering to receive security information from Cisco, is available on Cisco's worldwide website at http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html This includes instructions for press inquiries regarding Cisco security notices. All Cisco security advisories are available at http://www.cisco.com/go/psirt -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAknKUbQACgkQ86n/Gc8U/uBoggCdGbEAh9pGrV/ApbhENou5MF4M vTIAn03h9J//T0V6BZBxwwS2hKs/JIXi =JGEE -----END PGP SIGNATURE----- From psirt at cisco.com Wed Mar 25 11:00:00 2009 From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team) Date: Wed, 25 Mar 2009 17:00:00 +0100 Subject: Cisco Security Advisory: Cisco IOS Software Multiple Features Crafted TCP Sequence Vulnerability Message-ID: <200903251705.tcp@psirt.cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Cisco Security Advisory: Cisco IOS Software Multiple Features Crafted TCP Sequence Vulnerability Advisory ID: cisco-sa-20090325-tcp http://www.cisco.com/warp/public/707/cisco-sa-20090325-tcp.shtml Revision 1.0 For Public Release 2009 March 25 1600 UTC (GMT) - --------------------------------------------------------------------- Summary ======= Cisco IOS Software contains a vulnerability in multiple features that could allow an attacker to cause a denial of service (DoS) condition on the affected device. A sequence of specially crafted TCP packets can cause the vulnerable device to reload. Cisco has released free software updates that address this vulnerability. Several mitigation strategies are outlined in the workarounds section of this advisory. This advisory is posted at http://www.cisco.com/warp/public/707/cisco-sa-20090325-tcp.shtml Note: The March 25, 2009, Cisco IOS Security Advisory bundled publication includes eight Security Advisories. All of the advisories address vulnerabilities in Cisco IOS Software. Each advisory lists the releases that correct the vulnerability or vulnerabilities in the advisory. The following table lists releases that correct all Cisco IOS Software vulnerabilities that have been published in Cisco Security Advisories on March 25, 2009, or earlier. http://www.cisco.com/warp/public/707/cisco-sa-20090325-bundle.shtml Individual publication links are listed below: * Cisco IOS cTCP Denial of Service Vulnerability http://www.cisco.com/warp/public/707/cisco-sa-20090325-ctcp.shtml * Cisco IOS Software Multiple Features IP Sockets Vulnerability http://www.cisco.com/warp/public/707/cisco-sa-20090325-ip.shtml * Cisco IOS Software Mobile IP and Mobile IPv6 Vulnerabilities http://www.cisco.com/warp/public/707/cisco-sa-20090325-mobileip.shtml * Cisco IOS Software Secure Copy Privilege Escalation Vulnerability http://www.cisco.com/warp/public/707/cisco-sa-20090325-scp.shtml * Cisco IOS Software Session Initiation Protocol Denial of Service Vulnerability http://www.cisco.com/warp/public/707/cisco-sa-20090325-sip.shtml * Cisco IOS Software Multiple Features Crafted TCP Sequence Vulnerability http://www.cisco.com/warp/public/707/cisco-sa-20090325-tcp.shtml * Cisco IOS Software Multiple Features Crafted UDP Packet Vulnerability http://www.cisco.com/warp/public/707/cisco-sa-20090325-udp.shtml * Cisco IOS Software WebVPN and SSLVPN Vulnerabilities http://www.cisco.com/warp/public/707/cisco-sa-20090325-webvpn.shtml Affected Products ================= Vulnerable Products +------------------ Devices running affected versions of Cisco IOS Software and Cisco IOS XE Software are affected when configured to use any of the following features within Cisco IOS: * Airline Product Set (ALPS) * Serial Tunnel Code (STUN) and Block Serial Tunnel Code (BSTUN) * Native Client Interface Architecture support (NCIA) * Data-link switching (DLSw) * Remote Source-Route Bridging (RSRB) * Point to Point Tunneling Protocol (PPTP) * X.25 for Record Boundary Preservation (RBP) * X.25 over TCP (XOT) * X.25 Routing Information on how to determine whether an affected feature is enabled on a device are provided in the Details section of this advisory. To determine the Cisco IOS Software release that is running on a Cisco product, administrators can log in to the device and issue the "show version" command to display the system banner. The system banner confirms that the device is running Cisco IOS Software by displaying text similar to "Cisco Internetwork Operating System Software" or "Cisco IOS Software." The image name displays in parentheses, followed by "Version" and the Cisco IOS Software release name. Other Cisco devices do not have the "show version" command or may provide different output. The following example identifies a Cisco product that is running Cisco IOS Software Release 12.3(26) with an installed image name of C2500-IS-L: Router#show version Cisco Internetwork Operating System Software IOS (tm) 2500 Software (C2500-IS-L), Version 12.3(26), RELEASE SOFTWARE (fc2) Technical Support: http://www.cisco.com/techsupport Copyright (c) 1986-2008 by cisco Systems, Inc. Compiled Mon 17-Mar-08 14:39 by dchih The following example shows a product that is running Cisco IOS Software Release 12.4(20)T with an image name of C1841-ADVENTERPRISEK9-M: Router#show version Cisco IOS Software, 1841 Software (C1841-ADVENTERPRISEK9-M), Version 12.4(20)T, RELEASE SOFTWARE (fc3) Technical Support: http://www.cisco.com/techsupport Copyright (c) 1986-2008 by Cisco Systems, Inc. Compiled Thu 10-Jul-08 20:25 by prod_rel_team Additional information about Cisco IOS Software release naming conventions is available in "White Paper: Cisco IOS Reference Guide" at the following link: http://www.cisco.com/warp/public/620/1.html . Products Confirmed Not Vulnerable +-------------------------------- The following product and feature have been confirmed not vulnerable: * Cisco IOS XR Software * BGP is not affected No other Cisco products or features configured within Cisco IOS Software are currently known to be affected by this vulnerability. Details ======= Completion of the 3-way handshake to the associated TCP port number (s) of any of the features outlined below is required in order for the vulnerability to be successfully exploited. Airline Product Set (ALPS) +------------------------- Devices configured for ALPS are vulnerable. The default TCP listening ports for ALPS are 350 and 10000. The following example shows a vulnerable ALPS configuration: alps local-peer Further information about ALPS is available in "Cisco IOS Bridging and IBM Networking Configuration Guide, Release 12.2 - Configuring the Airline Product Set" at the following link http://www.cisco.com/en/US/docs/ios/12_2/ibm/configuration/guide/bcfalps_ps1835_TSD_Products_Configuration_Guide_Chapter.html Serial Tunnel Code (STUN) and Block Serial Tunneling (BSTUN) +----------------------------------------------------------- Devices configured for either STUN or BSTUN are vulnerable. The default listening TCP ports for STUN are 1990,1991 1992 and 1994. The default listening TCP ports for BSTUN are 1963, 1976, 1977, 1978 and 1979 The following example shows a vulnerable STUN configuration: interface serial 0/0/0 encapsulation stun The following example shows a vulnerable BSTUN configuration: interface serial 0/0/0 encapsulation bstun Further information about STUN and BSTUN is available in "Cisco IOS Bridging and IBM Networking Configuration Guide, Release 12.2 - Configuring Serial Tunnel and Block Serial Tunnel" at the following link http://www.cisco.com/en/US/docs/ios/12_2/ibm/configuration/guide/bcfstun_ps1835_TSD_Products_Configuration_Guide_Chapter.html Native Client Interface Architecture support (NCIA) +-------------------------------------------------- Devices configured for NCIA are vulnerable, because of the underlying transport they will use. The default listening TCP ports will be dependent on the protocol used with NCIA, such as RSRB or DSLw. The following examples shows a vulnerable configuration: ncia server 1 10.66.91.138 0000.1111.2222 2222.2222.2222 1 Further information about NCIA is available in "Cisco IOS Bridging and IBM Networking Configuration Guide, Release 12.4 - Configuring NCIA Client/Server" at the following link http://www.cisco.com/en/US/docs/ios/bridging/configuration/guide/br_ncia_client_svr_ps6350_TSD_Products_Configuration_Guide_Chapter.html Data-link switching (DLSw) +------------------------- Devices configured for DLSw are vulnerable. The default listening TCP ports for DSLw are 2065, 2067, 1981, 1982 and 1983. The following example shows a vulnerable configuration: dlsw local-peer peer-id Devices configured with either FST Encapsulation or Direct Encapsulation are still vulnerable as the affected TCP ports are opened by the "dslw local-peer peer-id ip address" command. Further information about DLSw is available in "Cisco IOS Bridging and IBM Networking Configuration Guide, Release 12.4 - Configuring Data-Link Switching Plus" at the following link http://www.cisco.com/en/US/docs/ios/bridging/configuration/guide/br_dlsw_plus_ps6350_TSD_Products_Configuration_Guide_Chapter.html Remote Source-Route Bridging (RSRB) +---------------------------------- Devices configured for RSRB Using IP Encapsulation over a TCP connection are vulnerable. The default listening TCP ports for RSRB are 1996,1987, 1988 and 1989. The following example shows a vulnerable configuration: source-bridge ring-group 10 source-bridge remote-peer 10 tcp Devices configured with either RSRB Using Direct Encapsulation or RSRB Using IP Encapsulation over an FST Connection are not affected. Further information about RSRB is available in "Cisco IOS Bridging and IBM Networking Configuration Guide, Release 12.2 - Configuring Remote Source-Route Bridging" at the following link http://www.cisco.com/en/US/docs/ios/12_2/ibm/configuration/guide/bcfrsrb_ps1835_TSD_Products_Configuration_Guide_Chapter.html Point to Point Tunneling Protocol (PPTP) +--------------------------------------- Devices configured for PPTP are vulnerable. The default listening TCP port for PPTP is 1723. The following examples shows a vulnerable configuration: vpdn enable ! vpdn-group pptp ! Default PPTP VPDN group accept-dialin protocol pptp virtual-template 1 Or vpdn enable ! vpdn-group L2_Tunneling ! Default L2TP VPDN group ! Default PPTP VPDN group accept-dialin protocol any virtual-template 1 Further information about PPTP is available in "Cisco IOS VPDN Configuration Guide, Release 12.4 - Configuring Client-Initiated Dial-In VPDN Tunneling" at the following link http://www.cisco.com/en/US/docs/ios/vpdn/configuration/guide/client_init_dial-in_ps6350_TSD_Products_Configuration_Guide_Chapter.html#wp1105140 X.25 Record Boundary Preservation (RBP) +-------------------------------------- Devices configured for RBP are vulnerable. The listening TCP port is configured with the "local port port_number" CLI command, as shown in the next examples. The following examples shows vulnerable configurations. The first leverages switched virtual circuits (SVC): interface Serial1/0 x25 map rbp 1111 local port The second example, leverages a permanent virtual circuit (PVC): interface Serial1/0 x25 map pvc rbp local port Further information about RBP is available in "Cisco IOS Wide-Area Networking Configuration Guide, Release 12.4 - X.25 Record Boundary Preservation for Data Communications Networks" at the following link http://www.cisco.com/en/US/docs/ios/wan/configuration/guide/wan_x25_rbp_dcn_ps6350_TSD_Products_Configuration_Guide_Chapter.html X.25 over TCP (XOT) +------------------ Devices configured for XOT are vulnerable. The default listening TCP port for XOT is 1998. The following example shows a vulnerable configuration. xot access-group 1 and a corresponding access-list 1. Further information about XOT is available in "Cisco IOS Wide-Area Networking Configuration Guide, Release 12.4 - X.25 over TCP Profiles" at the following link http://www.cisco.com/en/US/docs/ios/wan/configuration/guide/wan_x25otcp_pro_ps6350_TSD_Products_Configuration_Guide_Chapter.html X25 Routing +---------- Devices configured with X25 are vulnerable. The default listening TCP port for X25 Routing is 1998. The following example shows a vulnerable configuration. x25 routing Further information about X25 is available in "Cisco IOS Wide-Area Networking Configuration Guide, Release 12.4 - Configuring X.25 and LAPB" at the following link http://www.cisco.com/en/US/docs/ios/wan/configuration/guide/wan_cfg_x25_lapb_ps6350_TSD_Products_Configuration_Guide_Chapter.html This vulnerability is documented in the following Cisco Bug ID: CSCsr29468 and has been assigned the Common Vulnerabilities and Exposures (CVE) identifier CVE-2009-0629. Vulnerability Scoring Details ============================= Cisco has provided scores for the vulnerability in this advisory based on the Common Vulnerability Scoring System (CVSS). The CVSS scoring in this Security Advisory is done in accordance with CVSS version 2.0. CVSS is a standards-based scoring method that conveys vulnerability severity and helps determine urgency and priority of response. Cisco has provided a base and temporal score. Customers can then compute environmental scores to assist in determining the impact of the vulnerability in individual networks. Cisco has provided an FAQ to answer additional questions regarding CVSS at http://www.cisco.com/web/about/security/intelligence/cvss-qandas.html Cisco has also provided a CVSS calculator to help compute the environmental impact for individual networks at http://intellishield.cisco.com/security/alertmanager/cvss CSCsr29468: Cisco IOS Software Multiple Features Crafted TCP Sequence Vulnerability CVSS Base Score - 7.8 Access Vector - Network Access Complexity - Low Authentication - None Confidentiality Impact - None Integrity Impact - None Availability Impact - Complete CVSS Temporal Score - 6.4 Exploitability - Functional Remediation Level - Official-Fix Report Confidence - Confirmed Impact ====== Successful exploitation of this vulnerability will cause the device to reload. Repeated attempts to exploit this vulnerability could result in a sustained DoS condition. Software Versions and Fixes =========================== When considering software upgrades, also consult http://www.cisco.com/go/psirt and any subsequent advisories to determine exposure and a complete upgrade solution. In all cases, customers should exercise caution to be certain the devices to be upgraded contain sufficient memory and that current hardware and software configurations will continue to be supported properly by the new release. If the information is not clear, contact the Cisco Technical Assistance Center (TAC) or your contracted maintenance provider for assistance. Each row of the Cisco IOS software table (below) names a Cisco IOS release train. If a given release train is vulnerable, then the earliest possible releases that contain the fix (along with the anticipated date of availability for each, if applicable) are listed in the "First Fixed Release" column of the table. The "Recommended Release" column indicates the releases which have fixes for all the published vulnerabilities at the time of this Advisory. A device running a release in the given train that is earlier than the release in a specific column (less than the First Fixed Release) is known to be vulnerable. Cisco recommends upgrading to a release equal to or later than the release in the "Recommended Releases" column of the table. +-------------------------------------------------------------------+ | Major | Availability of Repaired Releases | | Release | | |------------+------------------------------------------------------| | Affected | | | | 12.0-Based | First Fixed Release | Recommended Release | | Releases | | | |-------------------------------------------------------------------| | There are no affected 12.0 based releases | |-------------------------------------------------------------------| | Affected | | | | 12.1-Based | First Fixed Release | Recommended Release | | Releases | | | |-------------------------------------------------------------------| | There are no affected 12.1 based releases | |-------------------------------------------------------------------| | Affected | | | | 12.2-Based | First Fixed Release | Recommended Release | | Releases | | | |------------+-----------------------------+------------------------| | 12.2 | Not Vulnerable | | |------------+-----------------------------+------------------------| | 12.2B | Not Vulnerable | | |------------+-----------------------------+------------------------| | 12.2BC | Not Vulnerable | | |------------+-----------------------------+------------------------| | 12.2BW | Not Vulnerable | | |------------+-----------------------------+------------------------| | 12.2BX | Not Vulnerable | | |------------+-----------------------------+------------------------| | 12.2BY | Not Vulnerable | | |------------+-----------------------------+------------------------| | 12.2BZ | Not Vulnerable | | |------------+-----------------------------+------------------------| | 12.2CX | Not Vulnerable | | |------------+-----------------------------+------------------------| | 12.2CY | Not Vulnerable | | |------------+-----------------------------+------------------------| | 12.2CZ | Not Vulnerable | | |------------+-----------------------------+------------------------| | 12.2DA | Not Vulnerable | | |------------+-----------------------------+------------------------| | 12.2DD | Not Vulnerable | | |------------+-----------------------------+------------------------| | 12.2DX | Not Vulnerable | | |------------+-----------------------------+------------------------| | 12.2EW | Vulnerable; first fixed in | 12.2(31)SGA9 | | | 12.2SG | | |------------+-----------------------------+------------------------| | 12.2EWA | Vulnerable; first fixed in | 12.2(31)SGA9 | | | 12.2SG | | |------------+-----------------------------+------------------------| | | Releases prior to 12.2(44) | | | | EX are vulnerable, release | | | 12.2EX | 12.2(44)EX and later are | 12.2(44)SE6 | | | not vulnerable; first fixed | | | | in 12.2SE | | |------------+-----------------------------+------------------------| | 12.2EY | 12.2(44)EY | 12.2(44)SE6 | |------------+-----------------------------+------------------------| | 12.2EZ | Vulnerable; first fixed in | 12.2(44)SE6 | | | 12.2SE | | |------------+-----------------------------+------------------------| | 12.2FX | Not Vulnerable | | |------------+-----------------------------+------------------------| | 12.2FY | Not Vulnerable | | |------------+-----------------------------+------------------------| | 12.2FZ | Vulnerable; first fixed in | 12.2(44)SE6 | | | 12.2SE | | |------------+-----------------------------+------------------------| | | Vulnerable; first fixed in | 12.2(33)SRC4; | | 12.2IRA | 12.2SRC | Available on | | | | 18-MAY-2009 | |------------+-----------------------------+------------------------| | | Vulnerable; first fixed in | 12.2(33)SRC4; | | 12.2IRB | 12.2SRC | Available on | | | | 18-MAY-2009 | |------------+-----------------------------+------------------------| | 12.2IXA | Vulnerable; migrate to any | 12.2(18)IXH; Available | | | release in 12.2IXH | on 31-MAR-2009 | |------------+-----------------------------+------------------------| | 12.2IXB | Vulnerable; migrate to any | 12.2(18)IXH; Available | | | release in 12.2IXH | on 31-MAR-2009 | |------------+-----------------------------+------------------------| | 12.2IXC | Vulnerable; migrate to any | 12.2(18)IXH; Available | | | release in 12.2IXH | on 31-MAR-2009 | |------------+-----------------------------+------------------------| | 12.2IXD | Vulnerable; migrate to any | 12.2(18)IXH; Available | | | release in 12.2IXH | on 31-MAR-2009 | |------------+-----------------------------+------------------------| | 12.2IXE | Vulnerable; migrate to any | 12.2(18)IXH; Available | | | release in 12.2IXH | on 31-MAR-2009 | |------------+-----------------------------+------------------------| | 12.2IXF | Vulnerable; migrate to any | 12.2(18)IXH; Available | | | release in 12.2IXH | on 31-MAR-2009 | |------------+-----------------------------+------------------------| | 12.2IXG | Vulnerable; migrate to any | 12.2(18)IXH; Available | | | release in 12.2IXH | on 31-MAR-2009 | |------------+-----------------------------+------------------------| | 12.2JA | Not Vulnerable | | |------------+-----------------------------+------------------------| | 12.2JK | Not Vulnerable | | |------------+-----------------------------+------------------------| | 12.2MB | Not Vulnerable | | |------------+-----------------------------+------------------------| | 12.2MC | Not Vulnerable | | |------------+-----------------------------+------------------------| | 12.2S | Vulnerable; first fixed in | 12.2(33)SB4 | | | 12.2SB | | |------------+-----------------------------+------------------------| | | 12.2(33)SB3 | | | | | | | 12.2SB | 12.2(28)SB13 | 12.2(33)SB4 | | | | | | | 12.2(31)SB14 | | |------------+-----------------------------+------------------------| | 12.2SBC | Vulnerable; first fixed in | 12.2(33)SB4 | | | 12.2SB | | |------------+-----------------------------+------------------------| | 12.2SCA | Vulnerable; first fixed in | 12.2(33)SCB1 | | | 12.2SCB | | |------------+-----------------------------+------------------------| | 12.2SCB | 12.2(33)SCB1 | 12.2(33)SCB1 | |------------+-----------------------------+------------------------| | | 12.2(46)SE2 | | | | | | | 12.2SE | 12.2(50)SE | 12.2(44)SE6 | | | | | | | 12.2(44)SE5 | | |------------+-----------------------------+------------------------| | 12.2SEA | Vulnerable; first fixed in | 12.2(44)SE6 | | | 12.2SE | | |------------+-----------------------------+------------------------| | 12.2SEB | Vulnerable; first fixed in | 12.2(44)SE6 | | | 12.2SE | | |------------+-----------------------------+------------------------| | 12.2SEC | Vulnerable; first fixed in | 12.2(44)SE6 | | | 12.2SE | | |------------+-----------------------------+------------------------| | 12.2SED | Vulnerable; first fixed in | 12.2(44)SE6 | | | 12.2SE | | |------------+-----------------------------+------------------------| | 12.2SEE | Vulnerable; first fixed in | 12.2(44)SE6 | | | 12.2SE | | |------------+-----------------------------+------------------------| | 12.2SEF | Not Vulnerable | | |------------+-----------------------------+------------------------| | | Releases prior to 12.2(25) | | | | SEG4 are vulnerable, | | | 12.2SEG | release 12.2(25)SEG4 and | 12.2(44)SE6 | | | later are not vulnerable; | | | | first fixed in 12.2SE | | |------------+-----------------------------+------------------------| | 12.2SG | 12.2(50)SG | 12.2(52)SG; Available | | | | on 15-MAY-2009 | |------------+-----------------------------+------------------------| | 12.2SGA | 12.2(31)SGA9 | 12.2(31)SGA9 | |------------+-----------------------------+------------------------| | 12.2SL | Not Vulnerable | | |------------+-----------------------------+------------------------| | 12.2SM | Vulnerable; contact TAC | | |------------+-----------------------------+------------------------| | 12.2SO | Vulnerable; contact TAC | | |------------+-----------------------------+------------------------| | 12.2SQ | Not Vulnerable | | |------------+-----------------------------+------------------------| | | Vulnerable; first fixed in | 12.2(33)SRC4; | | 12.2SRA | 12.2SRC | Available on | | | | 18-MAY-2009 | |------------+-----------------------------+------------------------| | | | 12.2(33)SRB5a; | | | | Available on | | 12.2SRB | Vulnerable; first fixed in | 3-April-2009 12.2(33) | | | 12.2SRC | SRC4; Available on | | | | 18-MAY-2009 12.2(33) | | | | SRD1 | |------------+-----------------------------+------------------------| | | | 12.2(33)SRC4; | | 12.2SRC | 12.2(33)SRC3 | Available on | | | | 18-MAY-2009 12.2(33) | | | | SRD1 | |------------+-----------------------------+------------------------| | 12.2SRD | 12.2(33)SRD1 | 12.2(33)SRD1 | |------------+-----------------------------+------------------------| | 12.2STE | Vulnerable; contact TAC | | |------------+-----------------------------+------------------------| | 12.2SU | Not Vulnerable | | |------------+-----------------------------+------------------------| | 12.2SV | Vulnerable; contact TAC | | |------------+-----------------------------+------------------------| | 12.2SVA | Vulnerable; contact TAC | | |------------+-----------------------------+------------------------| | 12.2SVC | Vulnerable; contact TAC | | |------------+-----------------------------+------------------------| | 12.2SVD | Vulnerable; contact TAC | | |------------+-----------------------------+------------------------| | 12.2SVE | Vulnerable; contact TAC | | |------------+-----------------------------+------------------------| | 12.2SW | Vulnerable; migrate to any | | | | release in 12.4SW | | |------------+-----------------------------+------------------------| | 12.2SX | Not Vulnerable | | |------------+-----------------------------+------------------------| | 12.2SXA | Not Vulnerable | | |------------+-----------------------------+------------------------| | 12.2SXB | Not Vulnerable | | |------------+-----------------------------+------------------------| | 12.2SXD | Vulnerable; first fixed in | 12.2(18)SXF16 | | | 12.2SXF | | |------------+-----------------------------+------------------------| | 12.2SXE | Vulnerable; first fixed in | 12.2(18)SXF16 | | | 12.2SXF | | |------------+-----------------------------+------------------------| | 12.2SXF | 12.2(18)SXF16 | 12.2(18)SXF16 | |------------+-----------------------------+------------------------| | | 12.2(33)SXH5; Available on | 12.2(33)SXH5; | | 12.2SXH | 20-APR-2009 | Available on | | | | 20-APR-2009 | |------------+-----------------------------+------------------------| | 12.2SXI | 12.2(33)SXI1 | 12.2(33)SXI1 | |------------+-----------------------------+------------------------| | 12.2SY | Not Vulnerable | | |------------+-----------------------------+------------------------| | 12.2SZ | Vulnerable; first fixed in | 12.2(33)SB4 | | | 12.2SB | | |------------+-----------------------------+------------------------| | 12.2T | Not Vulnerable | | |------------+-----------------------------+------------------------| | 12.2TPC | Not Vulnerable | | |------------+-----------------------------+------------------------| | 12.2XA | Not Vulnerable | | |------------+-----------------------------+------------------------| | 12.2XB | Not Vulnerable | | |------------+-----------------------------+------------------------| | 12.2XC | Not Vulnerable | | |------------+-----------------------------+------------------------| | 12.2XD | Not Vulnerable | | |------------+-----------------------------+------------------------| | 12.2XE | Not Vulnerable | | |------------+-----------------------------+------------------------| | 12.2XF | Not Vulnerable | | |------------+-----------------------------+------------------------| | 12.2XG | Not Vulnerable | | |------------+-----------------------------+------------------------| | 12.2XH | Not Vulnerable | | |------------+-----------------------------+------------------------| | 12.2XI | Not Vulnerable | | |------------+-----------------------------+------------------------| | 12.2XJ | Not Vulnerable | | |------------+-----------------------------+------------------------| | 12.2XK | Not Vulnerable | | |------------+-----------------------------+------------------------| | 12.2XL | Not Vulnerable | | |------------+-----------------------------+------------------------| | 12.2XM | Not Vulnerable | | |------------+-----------------------------+------------------------| | | Vulnerable; first fixed in | 12.2(33)SB4 | | 12.2XN | 12.2SRC | | | | | 12.2(33)SRD1 | |------------+-----------------------------+------------------------| | 12.2XNA | Vulnerable; first fixed in | 12.2(33)SRD1 | | | 12.2SRD | | |------------+-----------------------------+------------------------| | 12.2XNB | 12.2(33)XNB1 | 12.2(33)XNB3 | |------------+-----------------------------+------------------------| | 12.2XNC | Not Vulnerable | | |------------+-----------------------------+------------------------| | 12.2XO | 12.2(46)XO | 12.2(46)XO | |------------+-----------------------------+------------------------| | 12.2XQ | Not Vulnerable | | |------------+-----------------------------+------------------------| | 12.2XR | Not Vulnerable | | |------------+-----------------------------+------------------------| | 12.2XS | Not Vulnerable | | |------------+-----------------------------+------------------------| | 12.2XT | Not Vulnerable | | |------------+-----------------------------+------------------------| | 12.2XU | Not Vulnerable | | |------------+-----------------------------+------------------------| | 12.2XV | Not Vulnerable | | |------------+-----------------------------+------------------------| | 12.2XW | Not Vulnerable | | |------------+-----------------------------+------------------------| | 12.2YA | Not Vulnerable | | |------------+-----------------------------+------------------------| | 12.2YB | Not Vulnerable | | |------------+-----------------------------+------------------------| | 12.2YC | Not Vulnerable | | |------------+-----------------------------+------------------------| | 12.2YD | Not Vulnerable | | |------------+-----------------------------+------------------------| | 12.2YE | Not Vulnerable | | |------------+-----------------------------+------------------------| | 12.2YF | Not Vulnerable | | |------------+-----------------------------+------------------------| | 12.2YG | Not Vulnerable | | |------------+-----------------------------+------------------------| | 12.2YH | Not Vulnerable | | |------------+-----------------------------+------------------------| | 12.2YJ | Not Vulnerable | | |------------+-----------------------------+------------------------| | 12.2YK | Not Vulnerable | | |------------+-----------------------------+------------------------| | 12.2YL | Not Vulnerable | | |------------+-----------------------------+------------------------| | 12.2YM | Not Vulnerable | | |------------+-----------------------------+------------------------| | 12.2YN | Not Vulnerable | | |------------+-----------------------------+------------------------| | 12.2YO | Not Vulnerable | | |------------+-----------------------------+------------------------| | 12.2YP | Not Vulnerable | | |------------+-----------------------------+------------------------| | 12.2YQ | Not Vulnerable | | |------------+-----------------------------+------------------------| | 12.2YR | Not Vulnerable | | |------------+-----------------------------+------------------------| | 12.2YS | Not Vulnerable | | |------------+-----------------------------+------------------------| | 12.2YT | Not Vulnerable | | |------------+-----------------------------+------------------------| | 12.2YU | Not Vulnerable | | |------------+-----------------------------+------------------------| | 12.2YV | Not Vulnerable | | |------------+-----------------------------+------------------------| | 12.2YW | Not Vulnerable | | |------------+-----------------------------+------------------------| | 12.2YX | Not Vulnerable | | |------------+-----------------------------+------------------------| | 12.2YY | Not Vulnerable | | |------------+-----------------------------+------------------------| | 12.2YZ | Not Vulnerable | | |------------+-----------------------------+------------------------| | 12.2ZA | Not Vulnerable | | |------------+-----------------------------+------------------------| | 12.2ZB | Not Vulnerable | | |------------+-----------------------------+------------------------| | 12.2ZC | Not Vulnerable | | |------------+-----------------------------+------------------------| | 12.2ZD | Not Vulnerable | | |------------+-----------------------------+------------------------| | 12.2ZE | Not Vulnerable | | |------------+-----------------------------+------------------------| | 12.2ZF | Not Vulnerable | | |------------+-----------------------------+------------------------| | 12.2ZG | Not Vulnerable | | |------------+-----------------------------+------------------------| | 12.2ZH | Not Vulnerable | | |------------+-----------------------------+------------------------| | 12.2ZJ | Not Vulnerable | | |------------+-----------------------------+------------------------| | 12.2ZL | Not Vulnerable | | |------------+-----------------------------+------------------------| | 12.2ZP | Not Vulnerable | | |------------+-----------------------------+------------------------| | | Vulnerable; first fixed in | 12.2(33)SXH5; | | 12.2ZU | 12.2SXH | Available on | | | | 20-APR-2009 | |------------+-----------------------------+------------------------| | 12.2ZX | Vulnerable; first fixed in | 12.2(33)SB4 | | | 12.2SB | | |------------+-----------------------------+------------------------| | 12.2ZY | Vulnerable; contact TAC | | |------------+-----------------------------+------------------------| | 12.2ZYA | 12.2(18)ZYA1 | 12.2(18)ZYA1 | |------------+-----------------------------+------------------------| | Affected | | | | 12.3-Based | First Fixed Release | Recommended Release | | Releases | | | |-------------------------------------------------------------------| | There are no affected 12.3 based releases | |-------------------------------------------------------------------| | Affected | | | | 12.4-Based | First Fixed Release | Recommended Release | | Releases | | | |------------+-----------------------------+------------------------| | 12.4 | Not Vulnerable | | |------------+-----------------------------+------------------------| | 12.4JA | Not Vulnerable | | |------------+-----------------------------+------------------------| | 12.4JDA | Not Vulnerable | | |------------+-----------------------------+------------------------| | 12.4JK | Not Vulnerable | | |------------+-----------------------------+------------------------| | 12.4JL | Not Vulnerable | | |------------+-----------------------------+------------------------| | 12.4JMA | Not Vulnerable | | |------------+-----------------------------+------------------------| | 12.4JMB | Not Vulnerable | | |------------+-----------------------------+------------------------| | 12.4JX | Not Vulnerable | | |------------+-----------------------------+------------------------| | | 12.4(15)MD2 | | | | | | | 12.4MD | Releases prior to 12.4(11) | 12.4(11)MD7 | | | MD6 are not vulnerable, | | | | releases 12.4(15)MD and | | | | later are vulnerable. | | |------------+-----------------------------+------------------------| | | 12.4(19)MR1 | | | | | | | 12.4MR | Releases prior to 12.4(16) | 12.4(19)MR2 | | | MR2 are not vulnerable, | | | | releases 12.4(19)MR and | | | | later are vulnerable | | |------------+-----------------------------+------------------------| | 12.4SW | Not Vulnerable | | |------------+-----------------------------+------------------------| | | 12.4(22)T | | | | | 12.4(22)T1 | | 12.4T | 12.4(20)T2 | | | | | 12.4(15)T9; Available | | | Releases prior to 12.4(20)T | on 29-APR-2009 | | | are NOT vulnerable | | |------------+-----------------------------+------------------------| | 12.4XA | Not Vulnerable | | |------------+-----------------------------+------------------------| | 12.4XB | Not Vulnerable | | |------------+-----------------------------+------------------------| | 12.4XC | Not Vulnerable | | |------------+-----------------------------+------------------------| | 12.4XD | Not Vulnerable | | |------------+-----------------------------+------------------------| | 12.4XE | Not Vulnerable | | |------------+-----------------------------+------------------------| | 12.4XF | Not Vulnerable | | |------------+-----------------------------+------------------------| | 12.4XG | Not Vulnerable | | |------------+-----------------------------+------------------------| | 12.4XJ | Not Vulnerable | | |------------+-----------------------------+------------------------| | 12.4XK | Not Vulnerable | | |------------+-----------------------------+------------------------| | 12.4XL | Not Vulnerable | | |------------+-----------------------------+------------------------| | 12.4XM | Not Vulnerable | | |------------+-----------------------------+------------------------| | 12.4XN | Not Vulnerable | | |------------+-----------------------------+------------------------| | 12.4XP | Not Vulnerable | | |------------+-----------------------------+------------------------| | 12.4XQ | 12.4(15)XQ2 | 12.4(15)XQ2 | |------------+-----------------------------+------------------------| | | | 12.4(22)T1 | | 12.4XR | 12.4(15)XR4 | | | | | 12.4(15)T9; Available | | | | on 29-APR-2009 | |------------+-----------------------------+------------------------| | 12.4XT | Not Vulnerable | | |------------+-----------------------------+------------------------| | 12.4XV | Not Vulnerable | | |------------+-----------------------------+------------------------| | 12.4XW | Not Vulnerable | | |------------+-----------------------------+------------------------| | | | 12.4(22)T1 | | 12.4XY | 12.4(15)XY4 | | | | | 12.4(15)T9; Available | | | | on 29-APR-2009 | |------------+-----------------------------+------------------------| | 12.4XZ | 12.4(15)XZ2 | 12.4(15)XZ2 | |------------+-----------------------------+------------------------| | 12.4YA | 12.4(20)YA2 | 12.4(20)YA3 | |------------+-----------------------------+------------------------| | 12.4YB | Not Vulnerable | | |------------+-----------------------------+------------------------| | 12.4YD | Not Vulnerable | | +-------------------------------------------------------------------+ Workarounds =========== The following mitigations have been identified for this vulnerability, which may help protect an infrastructure until an upgrade to a fixed version of Cisco IOS software can be scheduled: Infrastructure Access Control Lists +---------------------------------- Although it is often difficult to block traffic that transits a network, it is possible to identify traffic that should never be allowed to target infrastructure devices and block that traffic at the border of networks. Infrastructure Access Control Lists (iACLs) are a network security best practice and should be considered as a long-term addition to good network security as well as a workaround for these specific vulnerabilities. The iACL example below should be included as part of the deployed infrastructure access-list which will protect all devices with IP addresses in the infrastructure IP address range: !--- !--- Only sections pertaining to features enabled on the device !--- need be configured. !--- !--- Feature: ALPS !--- access-list 150 permit tcp TRUSTED_HOSTS WILDCARD INFRASTRUCTURE_ADDRESSES WILDCARD eq 350 access-list 150 permit tcp TRUSTED_HOSTS WILDCARD INFRASTRUCTURE_ADDRESSES WILDCARD eq 10000 !--- !--- Deny ALPS TCP traffic from all other sources destined !--- to infrastructure addresses. !--- access-list 150 deny tcp any INFRASTRUCTURE_ADDRESSES WILDCARD eq 350 access-list 150 deny tcp any INFRASTRUCTURE_ADDRESSES WILDCARD eq 10000 !--- !--- Feature: STUN !--- access-list 150 permit tcp TRUSTED_HOSTS WILDCARD INFRASTRUCTURE_ADDRESSES WILDCARD eq 1994 access-list 150 permit tcp TRUSTED_HOSTS WILDCARD INFRASTRUCTURE_ADDRESSES WILDCARD range 1990 1992 !--- !--- Deny STUN TCP traffic from all other sources destined !--- to infrastructure addresses. !--- access-list 150 deny tcp any INFRASTRUCTURE_ADDRESSES WILDCARD eq 1994 access-list 150 deny tcp any INFRASTRUCTURE_ADDRESSES WILDCARD range 1990 1992 !--- !--- Feature: BSTUN !--- access-list 150 permit tcp TRUSTED_HOSTS WILDCARD INFRASTRUCTURE_ADDRESSES WILDCARD eq 1963 access-list 150 permit tcp TRUSTED_HOSTS WILDCARD INFRASTRUCTURE_ADDRESSES WILDCARD range 1976 1979 !--- !--- Deny BSTUN TCP traffic from all other sources destined !--- to infrastructure addresses. !--- access-list 150 deny tcp any INFRASTRUCTURE_ADDRESSES WILDCARD eq 1963 access-list 150 deny tcp any INFRASTRUCTURE_ADDRESSES WILDCARD range 1976 1979 !--- !--- Feature: NCIA !--- !--- !--- Leverage the underlying protocols, DLSw, RSRB, etc. !--- !--- !--- Feature: DLSW !--- access-list 150 permit tcp TRUSTED_HOSTS WILDCARD INFRASTRUCTURE_ADDRESSES WILDCARD eq 2065 access-list 150 permit tcp TRUSTED_HOSTS WILDCARD INFRASTRUCTURE_ADDRESSES WILDCARD eq 2067 access-list 150 permit tcp TRUSTED_HOSTS WILDCARD INFRASTRUCTURE_ADDRESSES WILDCARD range 1981 1983 !--- !--- Deny DLSW TCP traffic from all other sources destined !--- to infrastructure addresses. !--- access-list 150 deny tcp any INFRASTRUCTURE_ADDRESSES WILDCARD eq 2065 access-list 150 deny tcp any INFRASTRUCTURE_ADDRESSES WILDCARD eq 2067 access-list 150 deny tcp any INFRASTRUCTURE_ADDRESSES WILDCARD range 1981 1983 !--- !--- Feature: RSRB !--- access-list 150 permit tcp TRUSTED_HOSTS WILDCARD INFRASTRUCTURE_ADDRESSES WILDCARD range 1987 1989 access-list 150 permit tcp TRUSTED_HOSTS WILDCARD INFRASTRUCTURE_ADDRESSES WILDCARD eq 1996 !--- !--- Deny RSRB TCP traffic from all other sources destined !--- to infrastructure addresses. !--- access-list 150 deny tcp any INFRASTRUCTURE_ADDRESSES WILDCARD range 1987 1989 access-list 150 deny tcp any INFRASTRUCTURE_ADDRESSES WILDCARD eq 1996 !--- !--- Feature: PPTP !--- access-list 150 permit tcp TRUSTED_HOSTS WILDCARD INFRASTRUCTURE_ADDRESSES WILDCARD eq 1723 !--- !--- Deny PPTP TCP traffic from all other sources destined !--- to infrastructure addresses. !--- access-list 150 deny tcp any INFRASTRUCTURE_ADDRESSES WILDCARD eq 1723 !--- !--- Feature: RBP !--- !--- RBP will listen for TCP connections on the configured port !--- as per "local port ". The following example !--- uses port 1055 !--- access-list 150 permit tcp TRUSTED_HOSTS WILDCARD INFRASTRUCTURE_ADDRESSES WILDCARD eq 1055 !--- !--- Deny RBP traffic from all other sources destined !--- to infrastructure addresses. !--- access-list 150 deny tcp any INFRASTRUCTURE_ADDRESSES WILDCARD eq 1055 !--- !--- Feature: XOT and X.25 Routing !--- access-list 150 permit tcp TRUSTED_HOSTS WILDCARD INFRASTRUCTURE_ADDRESSES WILDCARD eq 1998 !--- !--- Deny XOT and X25 TCP traffic from all other sources !--- destined to infrastructure addresses. !--- access-list 150 deny tcp any INFRASTRUCTURE_ADDRESSES WILDCARD eq 1998 !--- !--- Permit/deny all other Layer 3 and Layer 4 traffic in !--- accordance with existing security policies and !--- configurations Permit all other traffic to transit the !--- device. !--- access-list 150 permit ip any any !--- !--- Apply access-list to all interfaces (only one example !--- shown) !--- interface serial 2/0 ip access-group 150 in The white paper entitled "Protecting Your Core: Infrastructure Protection Access Control Lists" presents guidelines and recommended deployment techniques for infrastructure protection access lists. This white paper can be obtained at the following link: http://www.cisco.com/en/US/tech/tk648/tk361/technologies_white_paper09186a00801a1a55.shtml Receive ACLs (rACL) +------------------ For distributed platforms, Receive ACLs may be an option starting in Cisco IOS Software Versions 12.0(21)S2 for the 12000 (GSR), 12.0(24)S for the 7500, and 12.0(31)S for the 10720. The Receive ACL protects the device from harmful traffic before the traffic can impact the route processor. Receive ACLs are designed to only protect the device on which it is configured. On the 12000, 7500, and 10720, transit traffic is never affected by a receive ACL. Because of this, the destination IP address "any" used in the example ACL entries below only refer to the router's own physical or virtual IP addresses. Receive ACLs are considered a network security best practice, and should be considered as a long-term addition to good network security, as well as a workaround for this specific vulnerability. The white paper entitled "Protecting Your Core: Infrastructure Protection Access Control Lists" presents guidelines and recommended deployment techniques for infrastructure protection access lists. This white paper can be obtained at the following link http://www.cisco.com/en/US/tech/tk648/tk361/technologies_white_paper09186a00801a0a5e.shtml The following is the receive path ACL written to permit this type of traffic from trusted hosts: !--- !--- Only sections pertaining to features enabled on the device !--- need be configured. !--- !--- !--- Permit ALPS traffic from trusted hosts allowed to the RP. !--- access-list 150 permit tcp TRUSTED_SOURCE_ADDRESSES WILDCARD any eq 350 access-list 150 permit tcp TRUSTED_SOURCE_ADDRESSES WILDCARD any eq 10000 !--- !--- Deny ALPS traffic from all other sources to the RP. !--- access-list 150 deny tcp any any eq 350 access-list 150 deny tcp any any eq 10000 !--- !--- Permit STUN traffic from trusted hosts allowed to the RP. !--- access-list 150 permit tcp TRUSTED_SOURCE_ADDRESSES WILDCARD any eq 1994 access-list 150 permit tcp TRUSTED_SOURCE_ADDRESSES WILDCARD any range 1990 1992 !--- !--- Deny STUN traffic from all other sources to the RP. !--- access-list 150 deny tcp any any eq 1994 access-list 150 deny tcp any any eq range 1990 1992 !--- !--- Permit BSTUN traffic from trusted hosts allowed to the RP. !--- access-list 150 permit tcp TRUSTED_SOURCE_ADDRESSES WILDCARD any eq 1963 access-list 150 permit tcp TRUSTED_SOURCE_ADDRESSES WILDCARD any range 1976 1979 !--- !--- Deny BSTUN traffic from all other sources to the RP. !--- access-list 150 deny tcp any any eq 1963 access-list 150 deny tcp any any eq range 1976 1979 !--- !--- Permit DLSw from trusted hosts allowed to the RP. !--- access-list 150 permit tcp TRUSTED_SOURCE_ADDRESSES WILDCARD any eq 2065 access-list 150 permit tcp TRUSTED_SOURCE_ADDRESSES WILDCARD any eq 2067 access-list 150 permit tcp TRUSTED_SOURCE_ADDRESSES WILDCARD any range 1981 1983 !--- !--- Deny DLSw all other sources to the RP. !--- access-list 150 deny tcp any any eq 2065 access-list 150 deny tcp any any eq 2067 access-list 150 deny tcp any any range 1981 1983 !--- !--- Permit RSRB traffic from trusted hosts allowed to the RP. !--- access-list 150 permit tcp TRUSTED_SOURCE_ADDRESSES WILDCARD any eq 1996 access-list 150 permit tcp TRUSTED_SOURCE_ADDRESSES WILDCARD any range 1987 1989 !--- !--- Deny RSRB traffic from all other sources to the RP. !--- access-list 150 deny tcp any any eq 1996 access-list 150 deny tcp any any range 1987 1989 !--- !--- Permit PPTP traffic from trusted hosts allowed to the RP. !--- access-list 150 permit tcp TRUSTED_SOURCE_ADDRESSES WILDCARD any eq 1723 !--- !--- Deny PPTP traffic from all other sources to the RP. !--- access-list 150 deny tcp any any eq 1723 !--- !--- Permit RBP traffic from trusted hosts allowed to the RP. !--- RBP will listen for TCP connections on the configured port !--- as per "local port ". The following example !--- uses port 1055 !--- access-list 150 permit tcp TRUSTED_SOURCE_ADDRESSES WILDCARD any eq 1055 !--- !--- Deny RBP traffic from all other sources to the RP. !--- access-list 150 deny tcp any any eq 1055 !--- !--- Permit XOT and X.25 Routing traffic from trusted hosts allowed !--- to the RP. !--- access-list 150 permit tcp TRUSTED_SOURCE_ADDRESSES WILDCARD any eq 1998 !--- !--- Deny XOT and X.25 Routing traffic from all other sources to !--- the RP. !--- access-list 150 deny tcp any any eq 1998 !--- Permit all other traffic to the RP. !--- according to security policy and configurations. access-list 150 permit ip any any !--- Apply this access list to the 'receive' path. ip receive access-list 150 Control Plane Policing +--------------------- Control Plane Policing (CoPP) can be used to block the affected features TCP traffic access to the device. Cisco IOS software releases 12.0S, 12.2SX, 12.2S, 12.3T, 12.4, and 12.4T support the CoPP feature. CoPP can be configured on a device to protect the management and control planes and minimize the risk and effectiveness of direct infrastructure attacks by explicitly permitting only authorized traffic that is sent to infrastructure devices in accordance with existing security policies and configurations. The CoPP example below should be included as part of the deployed CoPP that will protect all devices with IP addresses in the infrastructure IP address range. !--- !--- Only sections pertaining to features enabled on the device !--- need be configured. !--- !--- Feature: ALPS !--- access-list 150 deny tcp TRUSTED_HOSTS WILDCARD any eq 350 access-list 150 deny tcp TRUSTED_HOSTS WILDCARD any eq 10000 !--- !--- Permit ALPS traffic sent to all IP addresses !--- configured on all interfaces of the affected device so !--- that it will be policed and dropped by the CoPP feature !--- access-list 150 permit tcp any any eq 350 access-list 150 permit tcp any any eq 10000 !--- !--- Feature: STUN !--- access-list 150 deny tcp TRUSTED_HOSTS WILDCARD any eq 1994 access-list 150 deny tcp TRUSTED_HOSTS WILDCARD any range 1990 1992 !--- !--- Permit STUN traffic sent to all IP addresses !--- configured on all interfaces of the affected device so !--- that it will be policed and dropped by the CoPP feature !--- access-list 150 permit tcp any any eq 1994 access-list 150 permit tcp any any range 1990 1992 !--- !--- Feature: BSTUN !--- access-list 150 deny tcp TRUSTED_HOSTS WILDCARD any eq 1963 access-list 150 deny tcp TRUSTED_HOSTS WILDCARD any range 1976 1979 !--- !--- Permit BSTUN traffic sent to all IP addresses !--- configured on all interfaces of the affected device so !--- that it will be policed and dropped by the CoPP feature !--- access-list 150 permit tcp any any eq 1963 access-list 150 permit tcp any any range 1976 1979 !--- !--- Feature: NCIA !--- !--- Leverage the underlying protocols, DLSw, RSRB, etc. !--- !--- !--- Feature: DLSW !--- access-list 150 deny tcp TRUSTED_HOSTS WILDCARD any eq 2065 access-list 150 deny tcp TRUSTED_HOSTS WILDCARD any eq 2067 access-list 150 deny tcp TRUSTED_HOSTS WILDCARD any range 1981 1983 !--- !--- Permit DLSW traffic sent to all IP addresses !--- configured on all interfaces of the affected device so !--- that it will be policed and dropped by the CoPP feature !--- access-list 150 permit tcp any any eq 2065 access-list 150 permit tcp any any eq 2067 access-list 150 permit tcp any any range 1981 1983 !--- !--- Feature: RSRB !--- access-list 150 deny tcp TRUSTED_HOSTS WILDCARD any range 1987 1989 access-list 150 deny tcp TRUSTED_HOSTS WILDCARD any eq 1996 !--- !--- Permit RSRB traffic sent to all IP addresses !--- configured on all interfaces of the affected device so !--- that it will be policed and dropped by the CoPP feature !--- access-list 150 permit tcp any any range 1987 1989 access-list 150 permit tcp any any eq 1996 !--- !--- Feature: PPTP !--- access-list 150 deny tcp TRUSTED_HOSTS WILDCARD any eq 1723 !--- !--- Permit PPTP traffic sent to all IP addresses !--- configured on all interfaces of the affected device so !--- that it will be policed and dropped by the CoPP feature !--- access-list 150 permit tcp any any eq 1723 !--- !--- Feature: RBP !--- !--- RBP will listen for TCP connections on the configured port !--- as per "local port ". The following example !--- uses port 1055 access-list 150 deny tcp TRUSTED_HOSTS WILDCARD any eq 1055 !--- !--- Permit RBP traffic sent to all IP addresses !--- configured on all interfaces of the affected device so !--- that it will be policed and dropped by the CoPP feature !--- access-list 150 permit tcp any any eq 1055 !--- !--- Feature: XOT and X.25 Routing !--- access-list 150 deny tcp TRUSTED_HOSTS WILDCARD any eq 1998 !--- !--- Permit XOT and X25 traffic sent to all IP addresses !--- configured on all interfaces of the affected device so !--- that it will be policed and dropped by the CoPP feature !--- access-list 150 permit tcp any any eq 1998 !--- !--- Permit (Police or Drop)/Deny (Allow) all other Layer3 and !--- Layer4 traffic in accordance with existing security policies !--- configurations for traffic that is authorized to be sent !--- and to infrastructure devices !--- Create a Class-Map for traffic to be policed by !--- the CoPP feature !--- class-map match-all drop-tcp-class match access-group 150 !--- !--- Create a Policy-Map that will be applied to the !--- Control-Plane of the device. !--- policy-map drop-tcp-traffic class drop-tcp-class drop !--- !--- Apply the Policy-Map to the !--- Control-Plane of the device !--- control-plane service-policy input drop-tcp-traffic In the above CoPP example, the access control list entries (ACEs) that match the potential exploit packets with the "permit" action result in these packets being discarded by the policy-map "drop" function, while packets that match the "deny" action (not shown) are not affected by the policy-map drop function. Please note that the policy-map syntax is different in the 12.2S and 12.0S Cisco IOS trains: policy-map drop-tcp-traffic class drop-tcp-class police 32000 1500 1500 conform-action drop exceed-action drop Additional information on the configuration and use of the CoPP feature can be found in the documents, "Control Plane Policing Implementation Best Practices" and "Cisco IOS Software Releases 12.2S - - Control Plane Policing" at the following links http://www.cisco.com/web/about/security/intelligence/coppwp_gs.html and http://www.cisco.com/en/US/docs/ios/12_3t/12_3t4/feature/guide/gtrtlimt.html Additional mitigations that can be deployed on Cisco devices within the network are available in the "Cisco Applied Mitigation Bulletin" companion document for this advisory, at the following link http://www.cisco.com/warp/public/707/cisco-amb-20090325-tcp-and-ip.shtml Obtaining Fixed Software ======================== Cisco has released free software updates that address these vulnerabilities. Prior to deploying software, customers should consult their maintenance provider or check the software for feature set compatibility and known issues specific to their environment. Customers may only install and expect support for the feature sets they have purchased. By installing, downloading, accessing or otherwise using such software upgrades, customers agree to be bound by the terms of Cisco's software license terms found at http://www.cisco.com/en/US/docs/general/warranty/English/EU1KEN_.html, or as otherwise set forth at Cisco.com Downloads at http://www.cisco.com/public/sw-center/sw-usingswc.shtml Do not contact psirt at cisco.com or security-alert at cisco.com for software upgrades. Customers with Service Contracts +------------------------------- Customers with contracts should obtain upgraded software through their regular update channels. For most customers, this means that upgrades should be obtained through the Software Center on Cisco's worldwide website at http://www.cisco.com Customers using Third Party Support Organizations +------------------------------------------------ Customers whose Cisco products are provided or maintained through prior or existing agreements with third-party support organizations, such as Cisco Partners, authorized resellers, or service providers should contact that support organization for guidance and assistance with the appropriate course of action in regards to this advisory. The effectiveness of any workaround or fix is dependent on specific customer situations, such as product mix, network topology, traffic behavior, and organizational mission. Due to the variety of affected products and releases, customers should consult with their service provider or support organization to ensure any applied workaround or fix is the most appropriate for use in the intended network before it is deployed. Customers without Service Contracts +---------------------------------- Customers who purchase direct from Cisco but do not hold a Cisco service contract, and customers who purchase through third-party vendors but are unsuccessful in obtaining fixed software through their point of sale should acquire upgrades by contacting the Cisco Technical Assistance Center (TAC). TAC contacts are as follows. * +1 800 553 2447 (toll free from within North America) * +1 408 526 7209 (toll call from anywhere in the world) * e-mail: tac at cisco.com Customers should have their product serial number available and be prepared to give the URL of this notice as evidence of entitlement to a free upgrade. Free upgrades for non-contract customers must be requested through the TAC. Refer to http://www.cisco.com/en/US/support/tsd_cisco_worldwide_contacts.html for additional TAC contact information, including localized telephone numbers, and instructions and e-mail addresses for use in various languages. Exploitation and Public Announcements ===================================== The Cisco PSIRT is not aware of any public announcements or malicious use of the vulnerability described in this advisory. This vulnerability was found by Cisco internal testing. Status of this Notice: FINAL ============================ THIS DOCUMENT IS PROVIDED ON AN "AS IS" BASIS AND DOES NOT IMPLY ANY KIND OF GUARANTEE OR WARRANTY, INCLUDING THE WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR USE. YOUR USE OF THE INFORMATION ON THE DOCUMENT OR MATERIALS LINKED FROM THE DOCUMENT IS AT YOUR OWN RISK. CISCO RESERVES THE RIGHT TO CHANGE OR UPDATE THIS DOCUMENT AT ANY TIME. A stand-alone copy or Paraphrase of the text of this document that omits the distribution URL in the following section is an uncontrolled copy, and may lack important information or contain factual errors. Distribution ============ This advisory is posted on Cisco's worldwide website at : http://www.cisco.com/warp/public/707/cisco-sa-20090325-tcp.shtml In addition to worldwide web posting, a text version of this notice is clear-signed with the Cisco PSIRT PGP key and is posted to the following e-mail and Usenet news recipients. * cust-security-announce at cisco.com * first-bulletins at lists.first.org * bugtraq at securityfocus.com * vulnwatch at vulnwatch.org * cisco at spot.colorado.edu * cisco-nsp at puck.nether.net * full-disclosure at lists.grok.org.uk * comp.dcom.sys.cisco at newsgate.cisco.com Future updates of this advisory, if any, will be placed on Cisco's worldwide website, but may or may not be actively announced on mailing lists or newsgroups. Users concerned about this problem are encouraged to check the above URL for any updates. Revision History ================ +---------------------------------------+ | Revision | | Initial | | 1.0 | 2009-March-25 | public | | | | release | +---------------------------------------+ Cisco Security Procedures ========================= Complete information on reporting security vulnerabilities in Cisco products, obtaining assistance with security incidents, and registering to receive security information from Cisco, is available on Cisco's worldwide website at http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html This includes instructions for press inquiries regarding Cisco security notices. All Cisco security advisories are available at http://www.cisco.com/go/psirt -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAknKUb8ACgkQ86n/Gc8U/uCp1gCfS6aMv74rf1bDoby1JcGRFsN3 hpYAn1Oqp7nQxPwBrtptF3WM42HgGdIk =NVYK -----END PGP SIGNATURE----- From psirt at cisco.com Wed Mar 25 11:00:00 2009 From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team) Date: Wed, 25 Mar 2009 17:00:00 +0100 Subject: Cisco Security Advisory: Cisco IOS Software WebVPN and SSLVPN Vulnerabilities Message-ID: <200903251705.webvpn@psirt.cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Cisco Security Advisory: Cisco IOS Software WebVPN and SSLVPN Vulnerabilities Advisory ID: cisco-sa-20090325-webvpn http://www.cisco.com/warp/public/707/cisco-sa-20090325-webvpn.shtml Revision 1.0 For Public Release 2009 March 25 1600 UTC (GMT) - --------------------------------------------------------------------- Summary ======= Cisco IOS software contains two vulnerabilities within the Cisco IOS WebVPN or Cisco IOS SSLVPN feature (SSLVPN) that can be remotely exploited without authentication to cause a denial of service condition. Both vulnerabilities affect both Cisco IOS WebVPN and Cisco IOS SSLVPN features: 1. Crafted HTTPS packet will crash device. 2. SSLVPN sessions cause a memory leak in the device. Cisco has released free software updates that address these vulnerabilities. There are no workarounds that mitigate these vulnerabilities. This advisory is posted at the following link: http://www.cisco.com/warp/public/707/cisco-sa-20090325-webvpn.shtml Note: The March 25, 2009, Cisco IOS Security Advisory bundled publication includes eight Security Advisories. All of the advisories address vulnerabilities in Cisco IOS Software. Each advisory lists the releases that correct the vulnerability or vulnerabilities in the advisory. The following table lists releases that correct all Cisco IOS Software vulnerabilities that have been published in Cisco Security Advisories on March 25, 2009, or earlier. http://www.cisco.com/warp/public/707/cisco-sa-20090325-bundle.shtml Individual publication links are listed below: * Cisco IOS cTCP Denial of Service Vulnerability http://www.cisco.com/warp/public/707/cisco-sa-20090325-ctcp.shtml * Cisco IOS Software Multiple Features IP Sockets Vulnerability http://www.cisco.com/warp/public/707/cisco-sa-20090325-ip.shtml * Cisco IOS Software Mobile IP and Mobile IPv6 Vulnerabilities http://www.cisco.com/warp/public/707/cisco-sa-20090325-mobileip.shtml * Cisco IOS Software Secure Copy Privilege Escalation Vulnerability http://www.cisco.com/warp/public/707/cisco-sa-20090325-scp.shtml * Cisco IOS Software Session Initiation Protocol Denial of Service Vulnerability http://www.cisco.com/warp/public/707/cisco-sa-20090325-sip.shtml * Cisco IOS Software Multiple Features Crafted TCP Sequence Vulnerability http://www.cisco.com/warp/public/707/cisco-sa-20090325-tcp.shtml * Cisco IOS Software Multiple Features Crafted UDP Packet Vulnerability http://www.cisco.com/warp/public/707/cisco-sa-20090325-udp.shtml * Cisco IOS Software WebVPN and SSLVPN Vulnerabilities http://www.cisco.com/warp/public/707/cisco-sa-20090325-webvpn.shtml Affected Products ================= Vulnerable Products +------------------ Devices running affected versions of Cisco IOS software are affected if configured with SSLVPN. To determine the Cisco IOS Software release that is running on a Cisco product, administrators can log in to the device and issue the "show version" command to display the system banner. The system banner confirms that the device is running Cisco IOS Software by displaying text similar to "Cisco Internetwork Operating System Software" or "Cisco IOS Software." The image name displays in parentheses, followed by "Version" and the Cisco IOS Software release name. Other Cisco devices do not have the "show version" command or may provide different output. The following example identifies a Cisco product that is running Cisco IOS Software Release 12.3(26) with an installed image name of C2500-IS-L: Router#show version Cisco Internetwork Operating System Software IOS (tm) 2500 Software (C2500-IS-L), Version 12.3(26), RELEASE SOFTWARE (fc2) Technical Support: http://www.cisco.com/techsupport Copyright (c) 1986-2008 by cisco Systems, Inc. Compiled Mon 17-Mar-08 14:39 by dchih The following example shows a product that is running Cisco IOS Software release 12.4(20)T with an image name of C1841-ADVENTERPRISEK9-M: Router#show version Cisco IOS Software, 1841 Software (C1841-ADVENTERPRISEK9-M), Version 12.4(20)T, RELEASE SOFTWARE (fc3) Technical Support: http://www.cisco.com/techsupport Copyright (c) 1986-2008 by Cisco Systems, Inc. Compiled Thu 10-Jul-08 20:25 by prod_rel_team Additional information about Cisco IOS Software release naming conventions is available in "White Paper: Cisco IOS Reference Guide" at the following link: http://www.cisco.com/warp/public/620/1.html To determine that SSLVPN is enabled on your device, log in to the device and issue the command-line interface (CLI) command "show running-config | include webvpn". If the device returns any output this means that SSLVPN is configured on the device and the device may be vulnerable. Vulnerable configurations vary depending on whether the device is supporting Cisco IOS WebVPN (introduced in Release 12.3 (14)T) or Cisco IOS SSLVPNs (introduced in Release 12.4(6)T). The following methods describe how to confirm if the device is vulnerable: If the output from "show running-config | include webvpn" contains "webvpn enable" then the device is configured with the original Cisco IOS WebVPN. The only way to confirm the device is vulnerable is to examine the output of "show running-config" to confirm that webvpn is enabled via the command "webvpn enable" and that a "ssl trustpoint" has been configured. The following example shows a vulnerable device configured with Cisco IOS WebVPN: webvpn enable ! webvpn ssl trustpoint TP-self-signed-29742012 If the output from "show running-config | include webvpn" contains "webvpn gateway " then the device is supporting the Cisco IOS SSLVPN feature. A device is vulnerable if it has the "inservice" command in at least one of the "webvpn gateway" sections. The following example shows a vulnerable device configured with Cisco IOS SSLVPN: Router# show running | section webvpn webvpn gateway Gateway ip address 10.1.1.1 port 443 ssl trustpoint Gateway-TP inservice ! Router# A device that supports the Cisco IOS SSLVPN is not vulnerable if it has no "webvpn gateways" configured or all the configured "webvpn gateways" contain the "no inservice" "webvpn gateway" command. Products Confirmed Not Vulnerable +-------------------------------- The following products are not affected by this vulnerability: * Cisco ASA 5500 Series Adaptive Security Appliances * Cisco IOS XR Software * Cisco IOS XE Software No other Cisco products are currently known to be affected by these vulnerabilities. Details ======= The Cisco SSLVPN feature provides remote access to enterprise sites by users from anywhere on the Internet. The SSLVPN provides users with secure access to specific enterprise applications, such as e-mail and web browsing, without requiring them to have VPN client software installed on their end-user devices. The WebVPN Enhancements feature (Cisco IOS SSLVPN), released in Cisco IOS Release 12.4(6)T, obsoletes the commands and configurations originally put forward in Cisco IOS WebVPN. Further information about Cisco IOS WebVPN is available in the "Cisco IOS Software Release 12.3T WebVPN feature guide" at the following link: http://www.cisco.com/en/US/docs/ios/12_3t/12_3t14/feature/guide/g_sslvpn.html Further information about Cisco IOS SSLVPN is available in the "Cisco IOS Software Release 12.4T SSLVPN feature guide" at the following link: http://www.cisco.com/en/US/docs/ios/12_4t/12_4t11/htwebvpn.html Details regarding these two vulnerabilities in Cisco IOS devices that are running affected versions of system software are: Crafted HTTPS packet will crash device +-------------------------------------- A device configured for SSLVPN may reload or hang when it receives a specially crafted HTTPS packet. Completion of the 3-way handshake to the associated TCP port number of the SSLVPN feature is required in order for the vulnerability to be successfully exploited, however authentication is "not" required. The default TCP port number for SSLVPN is 443. This vulnerability is documented in Cisco bug ID CSCsk62253 and Common Vulnerabilities and Exposures (CVE) identifier CVE-2009-0626 has been assigned to this vulnerability. SSLVPN sessions cause a memory leak in the device +------------------------------------------------ A device configured for SSLVPN may leak transmission control blocks (TCBs) when processing an abnormally disconnected SSL session. Continued exploitation may result in the device depleting its memory resources and result in a crash of the device. Authentication is "not" required to exploit this vulnerability. The memory leak can be detected by running the command "show tcp brief", like in the following example: Router#show tcp brief TCB Local Address Foreign Address (state) 468BBDC0 192.168.0.22.443 192.168.0.33.19794 CLOSEWAIT 482D4730 192.168.0.22.443 192.168.0.33.22092 CLOSEWAIT 482779A4 192.168.0.22.443 192.168.0.33.16978 CLOSEWAIT 4693DEBC 192.168.0.22.443 192.168.0.33.21580 CLOSEWAIT 482D3418 192.168.0.22.443 192.168.0.33.17244 CLOSEWAIT 482B8ACC 192.168.0.22.443 192.168.0.33.16564 CLOSEWAIT 46954EB0 192.168.0.22.443 192.168.0.33.19532 CLOSEWAIT 468BA9B8 192.168.0.22.443 192.168.0.33.15781 CLOSEWAIT 482908C4 192.168.0.22.443 192.168.0.33.19275 CLOSEWAIT 4829D66C 192.168.0.22.443 192.168.0.33.19314 CLOSEWAIT 468A2D94 192.168.0.22.443 192.168.0.33.14736 CLOSEWAIT 4688F590 192.168.0.22.443 192.168.0.33.18786 CLOSEWAIT 4693CBA4 192.168.0.22.443 192.168.0.33.12176 CLOSEWAIT 4829ABC4 192.168.0.22.443 192.168.0.33.39629 CLOSEWAIT 4691206C 192.168.0.22.443 192.168.0.33.17818 CLOSEWAIT 46868224 192.168.0.22.443 192.168.0.33.16774 CLOSEWAIT 4832BFAC 192.168.0.22.443 192.168.0.33.39883 CLOSEWAIT 482D10CC 192.168.0.22.443 192.168.0.33.13677 CLOSEWAIT 4829B120 192.168.0.22.443 192.168.0.33.20870 CLOSEWAIT 482862FC 192.168.0.22.443 192.168.0.33.17035 CLOSEWAIT 482EC13C 192.168.0.22.443 192.168.0.33.16053 CLOSEWAIT 482901D8 192.168.0.22.443 192.168.0.33.16200 CLOSEWAIT In the output above, those Transmission Control Blocks (TCBs) in the state CLOSEWAIT will not go away and represent memory leaks. Please note that only TCP connections with a local TCP port of 443 (the well-known port for HTTPS) are relevant. This vulnerability is documented in Cisco bug ID CSCsw24700 and Common Vulnerabilities and Exposures (CVE) identifier CVE-2009-0628 has been assigned to this vulnerability. Vulnerability Scoring Details ============================= Cisco has provided scores for the vulnerabilities in this advisory based on the Common Vulnerability Scoring System (CVSS). The CVSS scoring in this Security Advisory is done in accordance with CVSS version 2.0. CVSS is a standards-based scoring method that conveys vulnerability severity and helps determine urgency and priority of response. Cisco has provided a base and temporal score. Customers can then compute environmental scores to assist in determining the impact of the vulnerability in individual networks. Cisco has provided an FAQ to answer additional questions regarding CVSS at http://www.cisco.com/web/about/security/intelligence/cvss-qandas.html Cisco has also provided a CVSS calculator to help compute the environmental impact for individual networks at http://intellishield.cisco.com/security/alertmanager/cvss CSCsk62253 - Crafted HTTPS packet will crash device. CVSS Base Score - 7.8 Access Vector - Network Access Complexity - Low Authentication - None Confidentiality Impact - None Integrity Impact - None Availability Impact - Complete CVSS Temporal Score - 6.4 Exploitability - Functional Remediation Level - Official-Fix Report Confidence - Confirmed CSCsw24700 - SSLVPN sessions cause a memory leak in the device. CVSS Base Score - 7.8 Access Vector - Network Access Complexity - Low Authentication - None Confidentiality Impact - None Integrity Impact - None Availability Impact - Complete CVSS Temporal Score - 6.4 Exploitability - Functional Remediation Level - Official-Fix Report Confidence - Confirmed Impact ====== Successful exploitation of any of the two vulnerabilities may result in the device crashing, not accepting any new SSLVPN sessions or a memory leak. Repeated exploitation may result in an extended denial of service (DoS) condition. Software Versions and Fixes =========================== When considering software upgrades, also consult http://www.cisco.com/go/psirt and any subsequent advisories to determine exposure and a complete upgrade solution. In all cases, customers should exercise caution to be certain the devices to be upgraded contain sufficient memory and that current hardware and software configurations will continue to be supported properly by the new release. If the information is not clear, contact the Cisco Technical Assistance Center (TAC) or your contracted maintenance provider for assistance. Each row of the Cisco IOS software table (below) names a Cisco IOS release train. If a given release train is vulnerable, then the earliest possible releases that contain the fix (along with the anticipated date of availability for each, if applicable) are listed in the "First Fixed Release" column of the table. The "Recommended Release" column indicates the releases which have fixes for all the published vulnerabilities at the time of this Advisory. A device running a release in the given train that is earlier than the release in a specific column (less than the First Fixed Release) is known to be vulnerable. Cisco recommends upgrading to a release equal to or later than the release in the "Recommended Releases" column of the table. +-------------------------------------------------------------------+ | Major | Availability of Repaired Releases | | Release | | |------------+------------------------------------------------------| | Affected | | Recommended | | 12.0-Based | First Fixed Release | Release | | Releases | | | |-------------------------------------------------------------------| | There are no affected 12.0 based releases | |-------------------------------------------------------------------| | Affected | | Recommended | | 12.1-Based | First Fixed Release | Release | | Releases | | | |-------------------------------------------------------------------| | There are no affected 12.1 based releases | |-------------------------------------------------------------------| | Affected | | Recommended | | 12.2-Based | First Fixed Release | Release | | Releases | | | |-------------------------------------------------------------------| | There are no affected 12.2 based releases | |-------------------------------------------------------------------| | Affected | | Recommended | | 12.3-Based | First Fixed Release | Release | | Releases | | | |------------+--------------------------------------+---------------| | 12.3 | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3B | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3BC | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3BW | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3EU | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3JA | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3JEA | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3JEB | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3JEC | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3JK | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3JL | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3JX | Not Vulnerable | | |------------+--------------------------------------+---------------| | | | 12.4(22)T1 | | | | | | 12.3T | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+--------------------------------------+---------------| | 12.3TPC | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3VA | Vulnerable; contact TAC | | |------------+--------------------------------------+---------------| | 12.3XA | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3XB | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3XC | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3XD | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3XE | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3XF | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3XG | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3XI | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3XJ | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3XK | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3XL | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3XQ | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3XR | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3XS | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3XU | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3XW | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3XX | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3XY | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3XZ | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3YA | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3YD | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3YF | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3YG | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3YH | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3YI | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3YJ | Not Vulnerable | | |------------+--------------------------------------+---------------| | | Releases prior to 12.3(11)YK3 are | 12.4(22)T1 | | | vulnerable, release 12.3(11)YK3 and | | | 12.3YK | later are not vulnerable; first | 12.4(15)T9; | | | fixed in 12.4T | Available on | | | | 29-APR-2009 | |------------+--------------------------------------+---------------| | 12.3YM | Not Vulnerable | | |------------+--------------------------------------+---------------| | | | 12.4(22)T1 | | | | | | 12.3YQ | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+--------------------------------------+---------------| | | | 12.4(22)T1 | | | | | | 12.3YS | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+--------------------------------------+---------------| | | | 12.4(22)T1 | | | | | | 12.3YT | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+--------------------------------------+---------------| | | | 12.4(22)T1 | | | | | | 12.3YU | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+--------------------------------------+---------------| | 12.3YX | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3YZ | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3ZA | Not Vulnerable | | |------------+--------------------------------------+---------------| | Affected | | Recommended | | 12.4-Based | First Fixed Release | Release | | Releases | | | |------------+--------------------------------------+---------------| | | | 12.4(18e) | | | 12.4(18e) | | | 12.4 | | 12.4(23a); | | | 12.4(23a); Available on 30-APR-2009 | Available on | | | | 30-APR-2009 | |------------+--------------------------------------+---------------| | 12.4JA | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.4JDA | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.4JK | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.4JL | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.4JMA | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.4JMB | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.4JX | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.4MD | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.4MR | 12.4(16)MR | 12.4(19)MR2 | |------------+--------------------------------------+---------------| | 12.4SW | Not Vulnerable | | |------------+--------------------------------------+---------------| | | 12.4(15)T7 | 12.4(22)T1 | | | | | | 12.4T | 12.4(20)T | 12.4(15)T9; | | | | Available on | | | 12.4(15)T9; Available on 29-APR-2009 | 29-APR-2009 | |------------+--------------------------------------+---------------| | | | 12.4(22)T1 | | | | | | 12.4XA | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+--------------------------------------+---------------| | | | 12.4(22)T1 | | | | | | 12.4XB | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+--------------------------------------+---------------| | | | 12.4(22)T1 | | | | | | 12.4XC | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+--------------------------------------+---------------| | | 12.4(4)XD12; Available on | 12.4(4)XD12; | | 12.4XD | 27-MAR-2009 | Available on | | | | 27-MAR-2009 | |------------+--------------------------------------+---------------| | | | 12.4(22)T1 | | | | | | 12.4XE | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+--------------------------------------+---------------| | 12.4XF | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.4XG | Not Vulnerable | | |------------+--------------------------------------+---------------| | | | 12.4(22)T1 | | | | | | 12.4XJ | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+--------------------------------------+---------------| | 12.4XK | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.4XL | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.4XM | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.4XN | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.4XP | Vulnerable; contact TAC | | |------------+--------------------------------------+---------------| | 12.4XQ | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.4XR | Not Vulnerable | | |------------+--------------------------------------+---------------| | | | 12.4(22)T1 | | | | | | 12.4XT | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+--------------------------------------+---------------| | 12.4XV | Vulnerable; contact TAC | | |------------+--------------------------------------+---------------| | 12.4XW | 12.4(11)XW10 | 12.4(11)XW10 | |------------+--------------------------------------+---------------| | 12.4XY | 12.4(15)XY4 | 12.4(22)T1 | |------------+--------------------------------------+---------------| | 12.4XZ | 12.4(15)XZ1 | 12.4(15)XZ2 | |------------+--------------------------------------+---------------| | 12.4YA | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.4YB | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.4YD | Not Vulnerable | | +-------------------------------------------------------------------+ Workarounds =========== There are no workarounds for the vulnerabilities described in this advisory. Obtaining Fixed Software ======================== Cisco has released free software updates that address these vulnerabilities. Prior to deploying software, customers should consult their maintenance provider or check the software for feature set compatibility and known issues specific to their environment. Customers may only install and expect support for the feature sets they have purchased. By installing, downloading, accessing or otherwise using such software upgrades, customers agree to be bound by the terms of Cisco's software license terms found at http://www.cisco.com/en/US/docs/general/warranty/English/EU1KEN_.html, or as otherwise set forth at Cisco.com Downloads at http://www.cisco.com/public/sw-center/sw-usingswc.shtml Do not contact psirt at cisco.com or security-alert at cisco.com for software upgrades. Customers with Service Contracts +------------------------------- Customers with contracts should obtain upgraded software through their regular update channels. For most customers, this means that upgrades should be obtained through the Software Center on Cisco's worldwide website at http://www.cisco.com Customers using Third Party Support Organizations +------------------------------------------------ Customers whose Cisco products are provided or maintained through prior or existing agreements with third-party support organizations, such as Cisco Partners, authorized resellers, or service providers should contact that support organization for guidance and assistance with the appropriate course of action in regards to this advisory. The effectiveness of any workaround or fix is dependent on specific customer situations, such as product mix, network topology, traffic behavior, and organizational mission. Due to the variety of affected products and releases, customers should consult with their service provider or support organization to ensure any applied workaround or fix is the most appropriate for use in the intended network before it is deployed. Customers without Service Contracts +---------------------------------- Customers who purchase direct from Cisco but do not hold a Cisco service contract, and customers who purchase through third-party vendors but are unsuccessful in obtaining fixed software through their point of sale should acquire upgrades by contacting the Cisco Technical Assistance Center (TAC). TAC contacts are as follows. * +1 800 553 2447 (toll free from within North America) * +1 408 526 7209 (toll call from anywhere in the world) * e-mail: tac at cisco.com Customers should have their product serial number available and be prepared to give the URL of this notice as evidence of entitlement to a free upgrade. Free upgrades for non-contract customers must be requested through the TAC. Refer to http://www.cisco.com/warp/public/687/Directory/DirTAC.shtml for additional TAC contact information, including localized telephone numbers, and instructions and e-mail addresses for use in various languages. Exploitation and Public Announcements ===================================== The Cisco PSIRT is not aware of any public announcements or malicious use of the vulnerabilities described in this advisory. These vulnerabilities were discovered when handling customer support calls. Status of this Notice: FINAL ============================ THIS DOCUMENT IS PROVIDED ON AN "AS IS" BASIS AND DOES NOT IMPLY ANY KIND OF GUARANTEE OR WARRANTY, INCLUDING THE WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR USE. YOUR USE OF THE INFORMATION ON THE DOCUMENT OR MATERIALS LINKED FROM THE DOCUMENT IS AT YOUR OWN RISK. CISCO RESERVES THE RIGHT TO CHANGE OR UPDATE THIS DOCUMENT AT ANY TIME. A stand-alone copy or Paraphrase of the text of this document that omits the distribution URL in the following section is an uncontrolled copy, and may lack important information or contain factual errors. Distribution ============ This advisory is posted on Cisco's worldwide website at : http://www.cisco.com/warp/public/707/cisco-sa-20090325-webvpn.shtml In addition to worldwide web posting, a text version of this notice is clear-signed with the Cisco PSIRT PGP key and is posted to the following e-mail and Usenet news recipients. * cust-security-announce at cisco.com * first-teams at first.org * bugtraq at securityfocus.com * vulnwatch at vulnwatch.org * cisco at spot.colorado.edu * cisco-nsp at puck.nether.net * full-disclosure at lists.grok.org.uk * comp.dcom.sys.cisco at newsgate.cisco.com Future updates of this advisory, if any, will be placed on Cisco's worldwide website, but may or may not be actively announced on mailing lists or newsgroups. Users concerned about this problem are encouraged to check the above URL for any updates. Revision History ================ +---------------------------------------+ | Revision | | Initial | | 1.0 | 2009-March-25 | public | | | | release. | +---------------------------------------+ Cisco Security Procedures ========================= Complete information on reporting security vulnerabilities in Cisco products, obtaining assistance with security incidents, and registering to receive security information from Cisco, is available on Cisco's worldwide website at http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html This includes instructions for press inquiries regarding Cisco security notices. All Cisco security advisories are available at http://www.cisco.com/go/psirt -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAknKUdcACgkQ86n/Gc8U/uALXwCgmcIGTSzRIHpHRbVVmMNqPFT4 +CIAn27HdwwpkhVDgEIWTMsIX6NE4BgR =+f8D -----END PGP SIGNATURE----- From ge at linuxbox.org Wed Mar 25 11:17:19 2009 From: ge at linuxbox.org (Gadi Evron) Date: Wed, 25 Mar 2009 17:17:19 +0100 Subject: phishing attacks against ISPs (also with Google translations) In-Reply-To: <49CA5578.2080008@gmail.com> References: <49CA25C0.70601@linuxbox.org> <620fd17c0903250655u1e9d8170y4fd8eac7aafa54d4@mail.gmail.com> <49CA5578.2080008@gmail.com> Message-ID: <49CA590F.5080408@linuxbox.org> William Allen Simpson wrote: > I've not recently seen an ISP account phish here. The last one I remember > was circa 2003. It was a dictionary attack, arriving at my was@ account > (long since rendered useless by spam volume and terminated). > > However, I don't save phish/spam anymore. I used to save everything -- > providing many of the examples for http://fraudgallery.com/ -- nowadays, > just daily scan for false positives, report monetary phish to the few > ISPs that actually promptly close down bad actors, and delete the rest. One of the responses off NANOG was very interesting. I will attribute after asking for permission to re-post. The guy mentioned the concept of sending warning emails to customers to begin with. His opinion is that it is a mistake, and only causes confusion. On top of that it raises support desk costs as people call in for explanation, as well as to report new fraudulent emails they see while in the past they mostly just ignored them. I hope to get more feedback on the matter, and see if other folks have the same experience. > Good luck, Gadi. I appreciate your feedback, I had no idea ISP phishing goes all the way back to 2003.. although dictionary attacks may not be best defined that way. Definition discussions are boring though. Danke, Gadi. From owen at impulse.net Wed Mar 25 11:22:13 2009 From: owen at impulse.net (Owen Roth) Date: Wed, 25 Mar 2009 09:22:13 -0700 Subject: Remote hands site or list? Message-ID: <49CA5A35.7050001@impulse.net> Hello nanog mailing list, I was curious how one would go about looking for certain types of remote hands by geography (ie coaxial runs in Phoenix, AZ). Is there another mailing list or a web site that recommends itself? -- Owen Roth Network Engineer From Valdis.Kletnieks at vt.edu Wed Mar 25 11:32:16 2009 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 25 Mar 2009 12:32:16 -0400 Subject: phishing attacks against ISPs (also with Google translations) In-Reply-To: Your message of "Wed, 25 Mar 2009 08:55:40 CDT." <620fd17c0903250655u1e9d8170y4fd8eac7aafa54d4@mail.gmail.com> References: <49CA25C0.70601@linuxbox.org> <620fd17c0903250655u1e9d8170y4fd8eac7aafa54d4@mail.gmail.com> Message-ID: <15311.1237998736@turing-police.cc.vt.edu> On Wed, 25 Mar 2009 08:55:40 CDT, Paul Wall said: > Since at the time Google added Hebrew translations, they also added > 7. Latvian, If I see actually *see* one, I'll let you know. Would be a welcome change from all the scams I continually get in languages I *can't* read. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From jcdill.lists at gmail.com Wed Mar 25 11:35:19 2009 From: jcdill.lists at gmail.com (JC Dill) Date: Wed, 25 Mar 2009 09:35:19 -0700 Subject: Akamai wierdness In-Reply-To: <6864f3b00903250044j557495d0q6ff17cd2cef4f9b2@mail.gmail.com> References: <6864f3b00903250044j557495d0q6ff17cd2cef4f9b2@mail.gmail.com> Message-ID: <49CA5D47.3090009@gmail.com> Jeffrey Cohen wrote: > On Wed, Mar 25, 2009 at 1:21 AM, JC Dill wrote: > > | Customers also have/know > | about ccare@ which also works. Non-customers (surprise - not everyone is > an > | Akamai customer, and non-customers do have valid reasons to contact a NOC > | now and then) who don't know about the super sekret[1] ccare@ can use noc@ > . > > the first click off the akamai root page is hardly "super sekret". TIN(Sekret)C. > although > they are really sneaky about it. its called 'support' and it is big and > bright and blue and right where you would expect it. quite the outrage > Customer support is an avenue for customers to receive... wait for it... support. It is not necessarily the right way for non-customers to reach a network operation center for network operations issues between the company's network and other networks. In many (most?) instances when a non-customer uses a customer support channel they encounter a brick wall - because CSRs are trained on how to support customers, not trained or enabled to connect non-customers to other departments. Try using the "customer support" channel as a non-customer to report a networking problem to eBay's NOC or to Google's NOC, and then report back on how well that works for you. It's perfectly reasonable to expect that large company networks operations centers have a NOC-to-NOC contact path that works better/faster than trying to go thru a customer service center to reach the NOC. > | Is there some point you wanted to make that contradicts all of this? > > jcdill, are you eight? this is a mailing list for network professionals. > if you cannot be at, at least act it > I can write in complete sentences, using capitalization and punctuation. I know the difference between its and it's. Skit's law will probably come into play now. Oh well. Enough said. jc From fergdawgster at gmail.com Wed Mar 25 11:47:26 2009 From: fergdawgster at gmail.com (Paul Ferguson) Date: Wed, 25 Mar 2009 09:47:26 -0700 Subject: phishing attacks against ISPs (also with Google translations) In-Reply-To: <49CA5578.2080008@gmail.com> References: <49CA25C0.70601@linuxbox.org> <620fd17c0903250655u1e9d8170y4fd8eac7aafa54d4@mail.gmail.com> <49CA5578.2080008@gmail.com> Message-ID: <6cd462c00903250947v302f4f85w3587af9369c2f318@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, Mar 25, 2009 at 9:02 AM, William Allen Simpson wrote: > > I've not recently seen an ISP account phish here. The last one I > remember was circa 2003. It was a dictionary attack, arriving at my was@ > account (long since rendered useless by spam volume and terminated). > > However, I don't save phish/spam anymore. I used to save everything -- > providing many of the examples for http://fraudgallery.com/ -- nowadays, > just daily scan for false positives, report monetary phish to the few > ISPs that actually promptly close down bad actors, and delete the rest. > The only recently successful scams that I am aware of which specifically targeted ISPs have been to obtain control of domain registrar accounts. Whether that was accomplished via phishing, or via some other nefarious method, is still unclear. - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.3 (Build 5003) wj8DBQFJymASq1pz9mNUZTMRAiE4AKCLBejTuPz2U6fy+Tuw0cKiOoX77ACeMxrz T+OobJm3VwvGRY/337TZrOQ= =IQDP -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/ From jay at west.net Wed Mar 25 11:56:42 2009 From: jay at west.net (Jay Hennigan) Date: Wed, 25 Mar 2009 09:56:42 -0700 Subject: Recommendation for wiring contractor in Scottsdale, AZ Message-ID: <49CA624A.5060008@west.net> We have a need for a DS-3 extension (734 duplex co-ax, 300 foot run, BNC termination) in Scottsdale, AZ. A recommendation for a clueful wiring contractor familiar with this type of work would be greatly appreciated! -- Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV From psirt at cisco.com Wed Mar 25 11:00:00 2009 From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team) Date: Wed, 25 Mar 2009 17:00:00 +0100 Subject: Cisco Security Advisory: Cisco IOS Software Multiple Features IP Sockets Vulnerability Message-ID: <200903251705.ip@psirt.cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Cisco Security Advisory: Cisco IOS Software Multiple Features IP Sockets Vulnerability Advisory ID: cisco-sa-20090325-ip http://www.cisco.com/warp/public/707/cisco-sa-20090325-ip.shtml Revision 1.0 For Public Release 2009 March 25 1600 UTC (GMT) - --------------------------------------------------------------------- Summary ======= A vulnerability in the handling of IP sockets can cause devices to be vulnerable to a denial of service attack when any of several features of Cisco IOS Software are enabled. A sequence of specially crafted TCP/IP packets could cause any of the following results: * The configured feature may stop accepting new connections or sessions. * The memory of the device may be consumed. * The device may experience prolonged high CPU utilization. * The device may reload. Cisco has released free software updates that address this vulnerability. Several mitigation strategies are outlined in the "Workarounds" section of this advisory. This advisory is posted at http://www.cisco.com/warp/public/707/cisco-sa-20090325-ip.shtml Note: The March 25, 2009, Cisco IOS Security Advisory bundled publication includes eight Security Advisories. All of the advisories address vulnerabilities in Cisco IOS Software. Each advisory lists the releases that correct the vulnerability or vulnerabilities in the advisory. The following table lists releases that correct all Cisco IOS Software vulnerabilities that have been published in Cisco Security Advisories on March 25, 2009, or earlier. http://www.cisco.com/warp/public/707/cisco-sa-20090325-bundle.shtml Individual publication links are listed below: * Cisco IOS cTCP Denial of Service Vulnerability http://www.cisco.com/warp/public/707/cisco-sa-20090325-ctcp.shtml * Cisco IOS Software Multiple Features IP Sockets Vulnerability http://www.cisco.com/warp/public/707/cisco-sa-20090325-ip.shtml * Cisco IOS Software Mobile IP and Mobile IPv6 Vulnerabilities http://www.cisco.com/warp/public/707/cisco-sa-20090325-mobileip.shtml * Cisco IOS Software Secure Copy Privilege Escalation Vulnerability http://www.cisco.com/warp/public/707/cisco-sa-20090325-scp.shtml * Cisco IOS Software Session Initiation Protocol Denial of Service Vulnerability http://www.cisco.com/warp/public/707/cisco-sa-20090325-sip.shtml * Cisco IOS Software Multiple Features Crafted TCP Sequence Vulnerability http://www.cisco.com/warp/public/707/cisco-sa-20090325-tcp.shtml * Cisco IOS Software Multiple Features Crafted UDP Packet Vulnerability http://www.cisco.com/warp/public/707/cisco-sa-20090325-udp.shtml * Cisco IOS Software WebVPN and SSLVPN Vulnerabilities http://www.cisco.com/warp/public/707/cisco-sa-20090325-webvpn.shtml Affected Products ================= Vulnerable Products +------------------ Devices that are running affected versions of Cisco IOS Software and Cisco IOS XE Software are affected if they are running any of the following features. Details about confirming whether the affected feature is enabled on a device are in the "Details" section of this advisory. * Cisco Unified Communications Manager Express * SIP Gateway Signaling Support Over Transport Layer Security (TLS) Transport * Secure Signaling and Media Encryption * Blocks Extensible Exchange Protocol (BEEP) * Network Admission Control HTTP Authentication Proxy * Per-user URL Redirect for EAPoUDP, Dot1x, and MAC Authentication Bypass * Distributed Director with HTTP Redirects * DNS (TCP mode only) To determine the Cisco IOS Software release that is running on a Cisco product, administrators can log in to the device and issue the "show version" command to display the system banner. The system banner confirms that the device is running Cisco IOS Software by displaying text similar to "Cisco Internetwork Operating System Software" or "Cisco IOS Software." The image name displays in parentheses, followed by "Version" and the Cisco IOS Software release name. Other Cisco devices do not have the "show version" command or may provide different output. The following example identifies a Cisco product that is running Cisco IOS Software Release 12.3(26) with an installed image name of C2500-IS-L: Router#show version Cisco Internetwork Operating System Software IOS (tm) 2500 Software (C2500-IS-L), Version 12.3(26), RELEASE SOFTWARE (fc2) Technical Support: http://www.cisco.com/techsupport Copyright (c) 1986-2008 by cisco Systems, Inc. Compiled Mon 17-Mar-08 14:39 by dchih The following example shows a product that is running Cisco IOS Software Release 12.4(20)T with an image name of C1841-ADVENTERPRISEK9-M: Router#show version Cisco IOS Software, 1841 Software (C1841-ADVENTERPRISEK9-M), Version 12.4(20)T, RELEASE SOFTWARE (fc3) Technical Support: http://www.cisco.com/techsupport Copyright (c) 1986-2008 by Cisco Systems, Inc. Compiled Thu 10-Jul-08 20:25 by prod_rel_team Additional information about Cisco IOS Software release naming conventions is available in "White Paper: Cisco IOS Reference Guide" at the following link: http://www.cisco.com/warp/public/620/1.html Products Confirmed Not Vulnerable +-------------------------------- The following product is not affected by this vulnerability: * Cisco IOS XR Software No other Cisco products or features configured in Cisco IOS or Cisco IOS XE Software are currently known to be affected by this vulnerability. Details ======== For successful exploitation of this vulnerability, the TCP three-way handshake must be completed to the associated TCP port number(s) for any of the features described in this section. Cisco Unified Communications Manager Express +------------------------------------------- The following configurations are vulnerable for different Cisco Unified Communications Manager Express services: A certificate authority proxy function (CAPF) server has been configured. The following example shows a vulnerable CAPF server configuration: capf-server auth-mode null-string cert-enroll-trustpoint root password 1 104D000A061843595F trustpoint-label cme_cert source-addr 10.0.0.1 The default TCP port used for CAPF server is 3804. Further information about CAPF-server is in the Cisco Unified Communications Manager Express System Administrator Guide at http://www.cisco.com/en/US/docs/voice_ip_comm/cucme/admin/configuration/guide/cmeauth.html#wp1085744 Telephony-service security parameters have been configured. If the telephony-service security parameters have been configured with "device-security-mode", the device is vulnerable. The following example shows three vulnerable configurations for telephony-service security parameters: ephone 1 device-security-mode encrypted ephone 2 device-security-mode authenticated ephone 3 device-security-mode none The TCP port used is defined with the "ip source-address
port " telephony-service configuration command. Further information about Telephony-service security parameters is in the Cisco Unified Communications Manager Express System Administrator Guide at http://www.cisco.com/en/US/docs/voice_ip_comm/cucme/admin/configuration/guide/cmeauth.html#wp1080079 The global telephony-service or call-manager-fallback command has been configured. Any Cisco IOS configuration with the global "telephony-service" or "call-manager-fallback" command is vulnerable if any subcommands are in the telephony-service or call-manager-fallback configuration mode. The following examples show vulnerable configurations: telephony-service ip source-address 192.168.0.1 port 2011 or call-manager-fallback ip source-address 192.168.0.1 port 2011 The TCP port used is defined with the "ip source-address
port " configuration command. Further information about telephony service and call-manager-fallback is in the Cisco Unified Communications Manager Express System Administrator Guide at http://www.cisco.com/en/US/docs/voice_ip_comm/cucme/admin/configuration/guide/cmesystm.html SIP Gateway Signaling Support over TLS Transport +---------------------------------------------- Note: For customers with devices enabled with SIP, also consult the document "Cisco Security Advisory: Cisco IOS Session Initiation Protocol Denial of Service Vulnerability" at the following link http://www.cisco.com/warp/public/707/cisco-sa-20090325-sip.html Devices that are configured for SIP gateway signaling support over TLS transport are vulnerable. The following examples show vulnerable configurations: voice service voip sip session transport tcp tls url sips - -- or -- dial-peer voice 3456 voip voice-class sip url sips session protocol sipv2 session transport tcp tls For the SIP gateway signaling support over TLS transport to function correctly, administrators must first configure a trustpoint using the following configuration: sip-ua crypto signaling default trustpoint example_trustpoint_name The default TCP port used for the SIP gateway signaling support over TLS transport feature is 5061. Further information about Cisco IOS SIP gateway signaling support over TLS transport is in the Cisco IOS Software Release 12.4T feature guide at http://www.cisco.com/en/US/docs/ios/12_4t/12_4t11/FeatTLS.html Secure Signaling and Media Encryption +------------------------------------ A device is vulnerable if it is configured with the Media and Signaling Encryption (SRTP/TLS) on DSP Farm Conferencing feature or with Secure Signaling and Media Encryption for analog phones with Skinny Call Control Protocol (SCCP). The following examples show three different vulnerable secure DSP farm configurations. Several other parts are required for a full configuration, such as certificates and SCCP configuration, but these parts have been excluded for brevity. dspfarm profile 2 transcode security trustpoint 2851ClientMina codec g711ulaw codec g711alaw codec g729ar8 codec g729abr8 codec gsmfr codec g729r8 codec g729br8 maximum sessions 3 associate application SCCP dspfarm profile 3 conference security trustpoint sec2800-cfb codec g711ulaw codec g711alaw codec g729ar8 codec g729abr8 codec g729r8 codec g729br8 maximum sessions 2 associate application SCCP dspfarm profile 5 mtp security trustpoint 2851ClientMina codec g711alaw maximum sessions hardware 1 associate application SCCP The default TCP port used for the Media and Signaling Encryption on DSP Farm Conferencing feature is 2443. Further information about the Media and Signaling Encryption on DSP Farm Conferencing feature is in the "Cisco IOS Software Release 12.4 Special and Early Deployments feature guide" at the following link http://www.cisco.com/en/US/docs/ios/12_4t/12_4t15/itsdsp.html The following output shows the relevant section of Secure Signaling and Media Encryption for analog phones and is a vulnerable configuration (Several other parts are required for a full configuration, such as certificates, SCCP configuration, and dial peers): !--- The following lines show SCCP Telephony Control Application !--- (STCAPP) security enabled at the system level: stcapp ccm-group 1 stcapp security trustpoint analog stcapp security mode encrypted stcapp <-- output removed for brevity --> dial-peer voice 5002 pots service stcapp !--- The following line shows the security mode configured on the !--- dial peer. security mode authenticated port 2/1 The default TCP port used for Media and Signaling Encryption for analog phones is 2443. Further information about Media and Signaling Encryption for analog phones is in the "Supplementary Services Features for FXS Ports on Cisco IOS Voice Gateways Configuration Guide, Release 12.4T" at the following link http://www.cisco.com/en/US/docs/ios/voice/fxs/configuration/guide/fsxsecur.html Blocks Extensible Exchange Protocol +---------------------------------- Any configuration or executable command that leverages Blocks Extensible Exchange Protocol (BEEP) as a transport protocol is vulnerable. The following example shows the vulnerable configuration of the feature NETCONF over BEEP. NETCONF over BEEP using SASL is also vulnerable. crypto key generate rsa general-keys crypto pki trustpoint my_trustpoint enrollment url http://10.2.3.3:80 subject-name CN=dns_name_of_host.com revocation-check none crypto pki authenticate my_trustpoint crypto pki enroll my_trustpoint line vty 0 15 netconf lock-time 60 netconf max-sessions 16 netconf beep initiator host1 23 user my_user password my_password encrypt my_trustpoint reconnect-time 60 netconf beep listener 23 sasl user1 encrypt my_trustpoint The TCP port used is defined with the "netconf beep initiator" and "netconf beep listener" configuration commands. Further information about NETCONF over BEEP is in the "Cisco IOS Software Release 12.4T feature guide" at the following link http://www.cisco.com/en/US/docs/ios/12_4t/12_4t11/htnetbe.html#wp1049404 The BEEP executable commands "bingd" and "bingng" could cause this vulnerability to be triggered when they are invoked. The following shows an example of these commands being executed: bingng device 192.168.0.1 23 bingd device 23 Network Admission Control HTTP Authentication Proxy +-------------------------------------------------- Devices configured with Network Admission Control HTTP Authentication Proxy are vulnerable. For the device to be vulnerable the authentication proxy rule must exist and be applied to an interface. The following configuration creates an authentication proxy rule. ip admission name example-ap-rule-name proxy http The following configuration attaches the authentication proxy rule (created in the previous example) to an interface. interface GigabitEthernet 0/0 ip admission example-ap-rule-name The default TCP port used for Network Admission Control HTTP Authentication Proxy is 80. Further information about Network Admission Control HTTP Authentication Proxy is in the "Cisco IOS Security Configuration Guide, Release 12.4" at the following link http://www.cisco.com/en/US/docs/ios/security/configuration/guide/sec_net_admssn_ctrl_ps6350_TSD_Products_Configuration_Guide_Chapter.html#wp1053957 Per-user URL Redirect for EAPoUDP, Dot1x, and MAC Authentication Bypass +---------------------------------------------------------------------- Devices that have URL redirect feature configured are vulnerable. URL redirect is supported for EAP over UDP (EAPoUDP), Dot1x and MAC Authentication Bypass (MAB) authentication mechanisms. The URL redirect configuration can either be on the server or set up as part of a locally defined profile or policy. Both configurations are vulnerable. A device is vulnerable with either of the following configurations. URL Redirect Feature Enabled for EAPoUDP +--------------------------------------- The URL redirect feature is enabled for EAPoUDP with the following global configuration command: ip admission name eapoudp The following configuration attaches the EAPoUDP rule (created in the previous example) to an interface. ip admission name URL Redirect Feature Enabled for Dot1x and MAB +--------------------------------------------- The URL redirect feature for both Dot1x and MAB are vulnerable and will have a URL redirect AV pair on the RADIUS server defined in a method that is similar to the following: url-redirect="http://example.com" url-redirect="urlacl" For the Dot1x and MAB URL redirect feature to work successfully on the switch, the minimum following configuration would also be required. There is no interface-specific configuration for URL redirect. Basically the interface has to be configured for Dot1x/MAB. ip http {server | secure-server} ip device tracking The default TCP port used for per-user URL redirect for EAPoUDP, Dot1x, and MAB is 80 and 443. Further information about per-user URL redirect for EAPoUDP, Dot1x, and MAB is in the "Catalyst 4500 Series Switch Software Configuration Guide, 12.2(50)SG" at the following link http://www.cisco.com/en/US/docs/switches/lan/catalyst4500/12.2/50sg/configuration/guide/dot1x.html#wp1311079 Distributed Director with HTTP Redirects +--------------------------------------- A device is vulnerable if Distributed Director is configured with HTTP redirects. The following example shows a vulnerable configuration: ip director ip-address 192.168.0.1 The default TCP port used for distributed director with HTTP redirect is 53. Further information about Distributed Director with HTTP redirects is in "Distributed Director Configuration Example Overview" at the following link http://www.cisco.com/en/US/products/hw/contnetw/ps813/products_tech_note09186a00801fa9dd.shtml#topic8b DNS +-- Devices that are configured with the Cisco IOS DNS feature are vulnerable. A pure DNS over UDP implementation is not vulnerable. See the "Workarounds" section of this advisory for information about filtering DNS over TCP traffic to the device. If any of the commands in the following example appear in the device configuration, the device is vulnerable: ip dns server ip dns primary example.com soa www.example.com admin at example.com ip dns spoofing 192.168.0.1 The default TCP port used for DNS is 53. Further information about Cisco IOS DNS is in the "Cisco IOS IP Addressing Services Configuration Guide, Release 12.4" at the following link http://www.cisco.com/en/US/docs/ios/ipaddr/configuration/guide/iad_config_dns_ps6350_TSD_Products_Configuration_Guide_Chapter.html This vulnerability is documented in the following Cisco Bug ID: CSCsm27071 and has been assigned the Common Vulnerabilities and Exposures (CVE) identifiers CVE-2009-0630. Vulnerability Scoring Details ============================= Cisco has provided scores for the vulnerabilities in this advisory based on the Common Vulnerability Scoring System (CVSS). The CVSS scoring in this Security Advisory is done in accordance with CVSS version 2.0. CVSS is a standards-based scoring method that conveys vulnerability severity and helps determine urgency and priority of response. Cisco has provided a base and temporal score. Customers can then compute environmental scores to assist in determining the impact of the vulnerability in individual networks. Cisco has provided an FAQ to answer additional questions regarding CVSS at http://www.cisco.com/web/about/security/intelligence/cvss-qandas.html Cisco has also provided a CVSS calculator to help compute the environmental impact for individual networks at http://intellishield.cisco.com/security/alertmanager/cvss CSCsm27071: Cisco IOS Software Multiple Features IP Sockets CVSS Base Score - 7.8 Access Vector - Network Access Complexity - Low Authentication - None Confidentiality Impact - None Integrity Impact - None Availability Impact - Complete CVSS Temporal Score - 6.4 Exploitability - Functional Remediation Level - Official-Fix Report Confidence - Confirmed Impact ====== Successful exploitation of the vulnerability may result in the any of the following occurring: * The configured feature may stop accepting new connections or sessions. * The memory of the device may be consumed. * The device may experience prolonged high CPU utilization. * The device may reload. Repeated attempts to exploit this vulnerability could result in a sustained DoS condition. Software Versions and Fixes =========================== When considering software upgrades, also consult http://www.cisco.com/go/psirt and any subsequent advisories to determine exposure and a complete upgrade solution. In all cases, customers should exercise caution to be certain the devices to be upgraded contain sufficient memory and that current hardware and software configurations will continue to be supported properly by the new release. If the information is not clear, contact the Cisco Technical Assistance Center (TAC) or your contracted maintenance provider for assistance. Each row of the Cisco IOS software table (below) names a Cisco IOS release train. If a given release train is vulnerable, then the earliest possible releases that contain the fix (along with the anticipated date of availability for each, if applicable) are listed in the "First Fixed Release" column of the table. The "Recommended Release" column indicates the releases which have fixes for all the published vulnerabilities at the time of this Advisory. A device running a release in the given train that is earlier than the release in a specific column (less than the First Fixed Release) is known to be vulnerable. Cisco recommends upgrading to a release equal to or later than the release in the "Recommended Releases" column of the table. +-------------------------------------------------------------------+ | Major | Availability of Repaired Releases | | Release | | |------------+------------------------------------------------------| | Affected | | Recommended | | 12.0-Based | First Fixed Release | Release | | Releases | | | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.0 | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.0DA | Vulnerable; first fixed in 12.2DA | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.0DB | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.0DC | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | 12.0S | 12.0(32)S12 | 12.0(32)S12 | |------------+-------------------------------------+----------------| | 12.0SC | Vulnerable; first fixed in 12.0S | 12.0(32)S12 | |------------+-------------------------------------+----------------| | 12.0SL | Vulnerable; first fixed in 12.0S | 12.0(32)S12 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.0SP | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | 12.0ST | Vulnerable; first fixed in 12.0S | 12.0(32)S12 | |------------+-------------------------------------+----------------| | 12.0SX | Vulnerable; first fixed in 12.0S | 12.0(32)S12 | |------------+-------------------------------------+----------------| | 12.0SY | 12.0(32)SY8 | 12.0(32)SY8 | |------------+-------------------------------------+----------------| | 12.0SZ | Vulnerable; first fixed in 12.0S | 12.0(32)S12 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.0T | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | 12.0W | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.0WC | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.0WT | Not Vulnerable | | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.0XA | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.0XB | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.0XC | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.0XD | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.0XE | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | 12.0XF | Not Vulnerable | | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.0XG | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.0XH | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | Releases prior to 12.0(4)XI2 are | 12.4(18e) | | | vulnerable, release 12.0(4)XI2 and | | | 12.0XI | later are not vulnerable; first | 12.4(23a); | | | fixed in 12.4 | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.0XJ | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.0XK | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.0XL | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.0XM | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.0XN | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.0XQ | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.0XR | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.0XS | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.0XT | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.0XV | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | Affected | | Recommended | | 12.1-Based | First Fixed Release | Release | | Releases | | | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.1 | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | 12.1AA | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.1AX | Vulnerable; first fixed in 12.2SE | 12.2(44)SE6 | |------------+-------------------------------------+----------------| | | | 12.1(22)EA13 | | 12.1AY | Vulnerable; first fixed in 12.1EA | | | | | 12.2(44)SE6 | |------------+-------------------------------------+----------------| | | | 12.1(22)EA13 | | 12.1AZ | Vulnerable; first fixed in 12.1EA | | | | | 12.2(44)SE6 | |------------+-------------------------------------+----------------| | 12.1CX | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.1DA | Vulnerable; first fixed in 12.2DA | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | 12.1DB | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.1DC | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.1E | Vulnerable; first fixed in 12.2SXF | 12.2(18)SXF16 | |------------+-------------------------------------+----------------| | 12.1EA | 12.1(22)EA13 | 12.1(22)EA13 | |------------+-------------------------------------+----------------| | 12.1EB | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | | | 12.2(33)SCB1 | | 12.1EC | Vulnerable; first fixed in 12.3BC | | | | | 12.3(23)BC6 | |------------+-------------------------------------+----------------| | 12.1EO | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.1EU | Vulnerable; first fixed in 12.2SG | 12.2(31)SGA9 | |------------+-------------------------------------+----------------| | 12.1EV | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.1EW | Vulnerable; migrate to 12.2SGA | | |------------+-------------------------------------+----------------| | 12.1EX | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.1EY | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.1EZ | Vulnerable; first fixed in 12.2SXF | 12.2(18)SXF16 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.1GA | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.1GB | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.1T | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.1XA | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.1XB | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.1XC | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.1XD | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.1XE | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.1XF | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.1XG | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.1XH | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.1XI | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.1XJ | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.1XL | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.1XM | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.1XP | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.1XQ | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.1XR | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.1XS | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.1XT | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.1XU | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.1XV | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.1XW | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.1XX | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.1XY | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.1XZ | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.1YA | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.1YB | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.1YC | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.1YD | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | Releases prior to 12.1(5)YE6 are | 12.4(18e) | | | vulnerable, release 12.1(5)YE6 and | | | 12.1YE | later are not vulnerable; first | 12.4(23a); | | | fixed in 12.4 | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.1YF | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.1YH | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | 12.1YI | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | | | 12.1(22)EA13 | | 12.1YJ | Vulnerable; first fixed in 12.1EA | | | | | 12.2(44)SE6 | |------------+-------------------------------------+----------------| | Affected | | Recommended | | 12.2-Based | First Fixed Release | Release | | Releases | | | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.2 | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.2B | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | | Vulnerable; migrate to 12.2SCB1 or | 12.2(33)SCB1 | | 12.2BC | 12.3BC | | | | | 12.3(23)BC6 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.2BW | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | 12.2BX | Vulnerable; migrate to 12.2SB4 | 12.2(33)SB4 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.2BY | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.2BZ | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | Vulnerable; migrate to 12.2SCB or | 12.2(33)SCB1 | | 12.2CX | 12.3BC | | | | | 12.3(23)BC6 | |------------+-------------------------------------+----------------| | | Vulnerable; migrate to 12.2SCB or | 12.2(33)SCB1 | | 12.2CY | 12.3BC | | | | | 12.3(23)BC6 | |------------+-------------------------------------+----------------| | 12.2CZ | Vulnerable; first fixed in 12.2SB | 12.2(33)SB4 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | 12.2(12)DA14; Available on | | | 12.2DA | 30-JUL-2009 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.2DD | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.2DX | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | 12.2EW | Vulnerable; first fixed in 12.2SG | 12.2(31)SGA9 | |------------+-------------------------------------+----------------| | 12.2EWA | Vulnerable; first fixed in 12.2SG | 12.2(31)SGA9 | |------------+-------------------------------------+----------------| | 12.2EX | Vulnerable; first fixed in 12.2SE | 12.2(44)SE6 | |------------+-------------------------------------+----------------| | 12.2EY | 12.2(44)EY | 12.2(44)SE6 | |------------+-------------------------------------+----------------| | 12.2EZ | Vulnerable; first fixed in 12.2SE | 12.2(44)SE6 | |------------+-------------------------------------+----------------| | 12.2FX | Vulnerable; first fixed in 12.2SE | 12.2(44)SE6 | |------------+-------------------------------------+----------------| | 12.2FY | Vulnerable; first fixed in 12.2SE | 12.2(44)SE6 | |------------+-------------------------------------+----------------| | 12.2FZ | Vulnerable; first fixed in 12.2SE | 12.2(44)SE6 | |------------+-------------------------------------+----------------| | | | 12.2(33)SRC4; | | 12.2IRA | Vulnerable; first fixed in 12.2SRC | Available on | | | | 18-MAY-2009 | |------------+-------------------------------------+----------------| | | | 12.2(33)SRC4; | | 12.2IRB | Vulnerable; first fixed in 12.2SRC | Available on | | | | 18-MAY-2009 | |------------+-------------------------------------+----------------| | | Vulnerable; migrate to any release | 12.2(18)IXH; | | 12.2IXA | in 12.2IXH | Available on | | | | 31-MAR-2009 | |------------+-------------------------------------+----------------| | | Vulnerable; migrate to any release | 12.2(18)IXH; | | 12.2IXB | in 12.2IXH | Available on | | | | 31-MAR-2009 | |------------+-------------------------------------+----------------| | | Vulnerable; migrate to any release | 12.2(18)IXH; | | 12.2IXC | in 12.2IXH | Available on | | | | 31-MAR-2009 | |------------+-------------------------------------+----------------| | | Vulnerable; migrate to any release | 12.2(18)IXH; | | 12.2IXD | in 12.2IXH | Available on | | | | 31-MAR-2009 | |------------+-------------------------------------+----------------| | | Vulnerable; migrate to any release | 12.2(18)IXH; | | 12.2IXE | in 12.2IXH | Available on | | | | 31-MAR-2009 | |------------+-------------------------------------+----------------| | | Vulnerable; migrate to any release | 12.2(18)IXH; | | 12.2IXF | in 12.2IXH | Available on | | | | 31-MAR-2009 | |------------+-------------------------------------+----------------| | | Vulnerable; migrate to any release | 12.2(18)IXH; | | 12.2IXG | in 12.2IXH | Available on | | | | 31-MAR-2009 | |------------+-------------------------------------+----------------| | 12.2JA | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.2JK | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.2MB | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | 12.2MC | 12.2(15)MC2m | 12.2(15)MC2m | |------------+-------------------------------------+----------------| | 12.2S | Vulnerable; first fixed in 12.2SB | 12.2(33)SB4 | |------------+-------------------------------------+----------------| | | 12.2(31)SB14 | | | | | | | 12.2SB | 12.2(33)SB1 | 12.2(33)SB4 | | | | | | | 12.2(28)SB13 | | |------------+-------------------------------------+----------------| | 12.2SBC | Vulnerable; first fixed in 12.2SB | 12.2(33)SB4 | |------------+-------------------------------------+----------------| | 12.2SCA | 12.2(33)SCA2 | 12.2(33)SCB1 | |------------+-------------------------------------+----------------| | 12.2SCB | Not Vulnerable | | |------------+-------------------------------------+----------------| | | 12.2(50)SE | | | | | | | 12.2SE | 12.2(46)SE2 | 12.2(44)SE6 | | | | | | | 12.2(44)SE5 | | |------------+-------------------------------------+----------------| | 12.2SEA | Vulnerable; first fixed in 12.2SE | 12.2(44)SE6 | |------------+-------------------------------------+----------------| | 12.2SEB | Vulnerable; first fixed in 12.2SE | 12.2(44)SE6 | |------------+-------------------------------------+----------------| | 12.2SEC | Vulnerable; first fixed in 12.2SE | 12.2(44)SE6 | |------------+-------------------------------------+----------------| | 12.2SED | Vulnerable; first fixed in 12.2SE | 12.2(44)SE6 | |------------+-------------------------------------+----------------| | 12.2SEE | Vulnerable; first fixed in 12.2SE | 12.2(44)SE6 | |------------+-------------------------------------+----------------| | 12.2SEF | Vulnerable; first fixed in 12.2SE | 12.2(44)SE6 | |------------+-------------------------------------+----------------| | 12.2SEG | Vulnerable; first fixed in 12.2SE | 12.2(44)SE6 | |------------+-------------------------------------+----------------| | | | 12.2(52)SG; | | 12.2SG | 12.2(50)SG | Available on | | | | 15-MAY-2009 | |------------+-------------------------------------+----------------| | 12.2SGA | 12.2(31)SGA9 | 12.2(31)SGA9 | |------------+-------------------------------------+----------------| | 12.2SL | Not Vulnerable | | |------------+-------------------------------------+----------------| | 12.2SM | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.2SO | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.2SQ | Not Vulnerable | | |------------+-------------------------------------+----------------| | | | 12.2(33)SRC4; | | 12.2SRA | Vulnerable; first fixed in 12.2SRC | Available on | | | | 18-MAY-2009 | |------------+-------------------------------------+----------------| | | | 12.2(33)SRB5a; | | | | Available on | | | | 3-April-2009 | | 12.2SRB | Vulnerable; first fixed in 12.2SRC | | | | | 12.2(33)SRC4; | | | | Available on | | | | 18-MAY-2009 | |------------+-------------------------------------+----------------| | | | 12.2(33)SRC4; | | 12.2SRC | 12.2(33)SRC1 | Available on | | | | 18-MAY-2009 | |------------+-------------------------------------+----------------| | 12.2SRD | Not Vulnerable | | |------------+-------------------------------------+----------------| | 12.2STE | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.2SU | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | 12.2SV | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.2SVA | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.2SVC | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.2SVD | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.2SVE | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.2SW | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.2SX | Vulnerable; first fixed in 12.2SXF | 12.2(18)SXF16 | |------------+-------------------------------------+----------------| | 12.2SXA | Vulnerable; first fixed in 12.2SXF | 12.2(18)SXF16 | |------------+-------------------------------------+----------------| | 12.2SXB | Vulnerable; first fixed in 12.2SXF | 12.2(18)SXF16 | |------------+-------------------------------------+----------------| | 12.2SXD | Vulnerable; first fixed in 12.2SXF | 12.2(18)SXF16 | |------------+-------------------------------------+----------------| | 12.2SXE | Vulnerable; first fixed in 12.2SXF | 12.2(18)SXF16 | |------------+-------------------------------------+----------------| | 12.2SXF | 12.2(18)SXF16 | 12.2(18)SXF16 | |------------+-------------------------------------+----------------| | | 12.2(33)SXH5; Available on | 12.2(33)SXH5; | | 12.2SXH | 20-APR-2009 | Available on | | | | 20-APR-2009 | |------------+-------------------------------------+----------------| | 12.2SXI | Not Vulnerable | | |------------+-------------------------------------+----------------| | 12.2SY | Vulnerable; first fixed in 12.2SB | 12.2(33)SB4 | |------------+-------------------------------------+----------------| | 12.2SZ | Vulnerable; first fixed in 12.2SB | 12.2(33)SB4 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.2T | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | 12.2TPC | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.2XA | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.2XB | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.2XC | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.2XD | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.2XE | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | Vulnerable; migrate to 12.2SCB or | 12.2(33)SCB1 | | 12.2XF | 12.3BC | | | | | 12.3(23)BC6 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.2XG | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.2XH | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.2XI | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.2XJ | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.2XK | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.2XL | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.2XM | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.2(33)SB4 | | 12.2XN | Vulnerable; first fixed in 12.2SRC | | | | | 12.2(33)SRD1 | |------------+-------------------------------------+----------------| | 12.2XNA | Vulnerable; migrate to any release | 12.2(33)SRD1 | | | in 12.2SRD | | |------------+-------------------------------------+----------------| | 12.2XNB | Not Vulnerable | | |------------+-------------------------------------+----------------| | 12.2XNC | Not Vulnerable | | |------------+-------------------------------------+----------------| | 12.2XO | 12.2(46)XO | 12.2(46)XO | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.2XQ | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.2XR | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.2XS | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.2XT | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.2XU | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.2XV | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.2XW | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.2YA | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | 12.2YB | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.2YC | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.2YD | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.2YE | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.2YF | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.2YG | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.2YH | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.2YJ | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.2YK | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.2YL | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.2YM | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | 12.2YN | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.2YO | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.2YP | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | 12.2YQ | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.2YR | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.2YS | Not Vulnerable | | |------------+-------------------------------------+----------------| | 12.2YT | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.2YU | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.2YV | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.2YW | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.2YX | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.2YY | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.2YZ | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.2ZA | Vulnerable; first fixed in 12.2SXF | 12.2(18)SXF16 | |------------+-------------------------------------+----------------| | 12.2ZB | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.2ZC | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.2ZD | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.2ZE | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.2ZF | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.2ZG | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.2ZH | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | 12.2ZJ | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.2ZL | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.2ZP | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | | | 12.2(33)SXH5; | | 12.2ZU | Vulnerable; first fixed in 12.2SXH | Available on | | | | 20-APR-2009 | |------------+-------------------------------------+----------------| | 12.2ZX | Vulnerable; first fixed in 12.2SB | 12.2(33)SB4 | |------------+-------------------------------------+----------------| | 12.2ZY | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.2ZYA | 12.2(18)ZYA1 | 12.2(18)ZYA1 | |------------+-------------------------------------+----------------| | Affected | | Recommended | | 12.3-Based | First Fixed Release | Release | | Releases | | | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.3 | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.3B | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | 12.3BC | 12.3(23)BC6 | 12.3(23)BC6 | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.3BW | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | 12.3EU | Not Vulnerable | | |------------+-------------------------------------+----------------| | 12.3JA | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.3JEA | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.3JEB | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.3JEC | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.3JK | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | 12.3JL | Vulnerable; first fixed in 12.4JK | | |------------+-------------------------------------+----------------| | 12.3JX | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.3T | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | 12.3TPC | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.3VA | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.3XA | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | 12.3XB | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.3XC | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.3XD | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.3XE | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | 12.3XF | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.3XG | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | 12.3XI | Vulnerable; first fixed in 12.2SB | 12.2(33)SB4 | |------------+-------------------------------------+----------------| | 12.3XJ | Vulnerable; first fixed in 12.3YX | 12.3(14)YX14 | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.3XK | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.3XL | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.3XQ | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.3XR | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.3XS | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.3XU | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | 12.3XW | Vulnerable; first fixed in 12.3YX | 12.3(14)YX14 | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.3XX | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.3XY | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.3XZ | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.3YA | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.3YD | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | 12.3YF | Vulnerable; first fixed in 12.3YX | 12.3(14)YX14 | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.3YG | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.3YH | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.3YI | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.3YJ | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.3YK | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | 12.3YM | 12.3(14)YM13 | 12.3(14)YM13 | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.3YQ | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.3YS | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.3YT | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.3YU | Vulnerable; first fixed in 12.4XB | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | 12.3YX | 12.3(14)YX14 | 12.3(14)YX14 | |------------+-------------------------------------+----------------| | 12.3YZ | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.3ZA | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | Affected | | Recommended | | 12.4-Based | First Fixed Release | Release | | Releases | | | |------------+-------------------------------------+----------------| | | 12.4(19) | 12.4(18e) | | | | | | 12.4 | 12.4(18a) | 12.4(23a); | | | | Available on | | | 12.4(23a); Available on 30-APR-2009 | 30-APR-2009 | |------------+-------------------------------------+----------------| | 12.4JA | 12.4(16b)JA1 | | |------------+-------------------------------------+----------------| | 12.4JDA | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.4JK | 12.4(3)JK4 | | |------------+-------------------------------------+----------------| | 12.4JL | 12.4(3)JL1 | | |------------+-------------------------------------+----------------| | 12.4JMA | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.4JMB | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.4JX | Vulnerable; first fixed in 12.4JA | | |------------+-------------------------------------+----------------| | 12.4MD | 12.4(11)MD7 | 12.4(11)MD7 | |------------+-------------------------------------+----------------| | 12.4MR | 12.4(19)MR | 12.4(19)MR2 | |------------+-------------------------------------+----------------| | 12.4SW | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | | 12.4(20)T | 12.4(22)T1 | | | | | | 12.4T | 12.4(15)T8 | 12.4(15)T9; | | | | Available on | | | 12.4(15)T9; Available on | 29-APR-2009 | | | 29-APR-2009 | | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.4XA | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | 12.4(15)T8 | | | 12.4XB | | 12.4(15)T9; | | | 12.4(20)T | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.4XC | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | | 12.4(4)XD12; Available on | 12.4(4)XD12; | | 12.4XD | 27-MAR-2009 | Available on | | | | 27-MAR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.4XE | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.4XF | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.4XG | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.4XJ | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.4XK | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | 12.4XL | 12.4(15)XL4 | 12.4(15)XL4 | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.4XM | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | 12.4XN | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.4XP | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.4XQ | 12.4(15)XQ2 | 12.4(15)XQ2 | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.4XR | 12.4(15)XR4 | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.4XT | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | 12.4XV | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.4XW | 12.4(11)XW10 | 12.4(11)XW10 | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.4XY | 12.4(15)XY4 | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | 12.4XZ | Not Vulnerable | | |------------+-------------------------------------+----------------| | 12.4YA | Not Vulnerable | | |------------+-------------------------------------+----------------| | 12.4YB | Not Vulnerable | | |------------+-------------------------------------+----------------| | 12.4YD | Not Vulnerable | | +-------------------------------------------------------------------+ Workarounds =========== The following mitigations have been identified for this vulnerability: Infrastructure Access Control Lists +---------------------------------- Although it is often difficult to block traffic that transits a network, it is possible to identify traffic that should never be allowed to target infrastructure devices and block that traffic at the border of networks. Infrastructure Access Control Lists (iACLs) are a network security best practice and should be considered as a long-term addition to good network security as well as a workaround for these specific vulnerabilities. The iACL example below should be included as part of the deployed infrastructure access-list which will protect all devices with IP addresses in the infrastructure IP address range: !--- Only sections pertaining to features enabled on the device !--- need be configured. !--- !--- Feature: Cisco Unified Communications Manager Express !--- !--- CAPF server configuration !--- access-list 150 permit tcp TRUSTED_SOURCE_ADDRESSES WILDCARD INFRASTRUCTURE_ADDRESSES WILDCARD eq 3804 !--- !--- Telephony-Service configuration !--- The TCP port is as per the ip source-address !--- port telephony !--- service configuration command. Example below 2999 !--- access-list 150 permit tcp TRUSTED_SOURCE_ADDRESSES WILDCARD INFRASTRUCTURE_ADDRESSES WILDCARD eq 2999 !--- !--- Deny Cisco Unified Communications Manager Express traffic !--- from all other sources destined to infrastructure addresses. !--- access-list 150 deny tcp any INFRASTRUCTURE_ADDRESSES WILDCARD eq 3804 access-list 150 deny tcp any INFRASTRUCTURE_ADDRESSES WILDCARD eq 2999 !--- !--- Feature: SIP Gateway Signaling Support Over TLS Transport !--- access-list 150 permit tcp TRUSTED_SOURCE_ADDRESSES WILDCARD INFRASTRUCTURE_ADDRESSES WILDCARD eq 5061 !--- Deny SIP Gateway Signaling Support Over TLS Transport !--- traffic from all other sources destined to infrastructure !--- addresses. access-list 150 deny tcp any INFRASTRUCTURE_ADDRESSES WILDCARD eq 5061 !--- !--- Feature: Secure Signaling and Media Encryption !--- access-list 150 permit tcp TRUSTED_SOURCE_ADDRESSES WILDCARD INFRASTRUCTURE_ADDRESSES WILDCARD eq 2443 !--- Deny Secure Signaling and Media Encryption traffic from all !--- other sources destined to infrastructure addresses. access-list 150 deny tcp any INFRASTRUCTURE_ADDRESSES WILDCARD eq 2443 !--- !--- Feature: Blocks Extensible Exchange Protocol (BEEP) !--- The TCP port used is defined with the netconf beep initiator !--- and netconf beep listener configuration !--- commands. This example uses 3001 !--- access-list 150 permit tcp TRUSTED_SOURCE_ADDRESSES WILDCARD INFRASTRUCTURE_ADDRESSES WILDCARD eq 3001 !--- Deny BEEP traffic from all other sources destined to !--- infrastructure addresses. access-list 150 deny tcp any INFRASTRUCTURE_ADDRESSES WILDCARD eq 3001 !--- !--- Feature: Network Admission Control HTTP Authentication Proxy !--- and !--- Per-user URL Redirect for EAP over UDP, Dot1x and MAC !--- Authentication Bybass !--- access-list 150 permit tcp TRUSTED_SOURCE_ADDRESSES WILDCARD INFRASTRUCTURE_ADDRESSES WILDCARD eq 80 access-list 150 permit tcp TRUSTED_SOURCE_ADDRESSES WILDCARD INFRASTRUCTURE_ADDRESSES WILDCARD eq 443 !--- !--- Deny Network Admission Control HTTP Authentication Proxy !--- and !--- Per-user URL Redirect for EAP over UDP, Dot1x and MAC !--- Authentication Bybass traffic to infrastructue !--- access-list 150 deny tcp any INFRASTRUCTURE_ADDRESSES WILDCARD eq 80 access-list 150 deny tcp any INFRASTRUCTURE_ADDRESSES WILDCARD eq 443 !--- !--- Features: Distributed Director with HTTP Redirects and DNS !--- access-list 150 permit tcp TRUSTED_SOURCE_ADDRESSES WILDCARD INFRASTRUCTURE_ADDRESSES WILDCARD eq 53 !--- Deny Distributed Director with HTTP Redirects traffic and DNS !--- from all other sources destined to infrastructure addresses. access-list 150 deny tcp any INFRASTRUCTURE_ADDRESSES WILDCARD eq 53 !--- Permit/deny all other Layer 3 and Layer 4 traffic in !--- accordance with existing security policies and configurations !--- Permit all other traffic to transit the device. access-list 150 permit ip any any !--- Apply access-list to all interfaces (only one example shown) interface serial 2/0 ip access-group 150 in The white paper entitled "Protecting Your Core: Infrastructure Protection Access Control Lists" presents guidelines and recommended deployment techniques for infrastructure protection access lists. This white paper can be obtained at the following link http://www.cisco.com/en/US/tech/tk648/tk361/technologies_white_paper09186a00801a1a55.shtml Receive ACLs (rACL) +------------------ For distributed platforms, Receive ACLs may be an option starting in Cisco IOS Software Versions 12.0(21)S2 for the 12000 (GSR), 12.0(24)S for the 7500, and 12.0(31)S for the 10720. The Receive ACL protects the device from harmful traffic before the traffic can impact the route processor. Receive ACLs are designed to only protect the device on which it is configured. On the 12000, 7500, and 10720, transit traffic is never affected by a receive ACL. Because of this, the destination IP address "any" used in the example ACL entries below only refer to the router's own physical or virtual IP addresses. Receive ACLs are considered a network security best practice, and should be considered as a long-term addition to good network security, as well as a workaround for this specific vulnerability. The white paper entitled "GSR: Receive Access Control Lists" will help you identify and allow legitimate traffic to your device and deny all unwanted packets. This white paper is available at the following link http://www.cisco.com/en/US/tech/tk648/tk361/technologies_white_paper09186a00801a0a5e.shtml The following is the receive path ACL written to permit this type of traffic from trusted hosts: !--- !--- Only sections pertaining to features enabled on the device !--- need be configured. !--- !--- !--- Feature: Cisco Unified Communications Manager Express !--- !--- !--- !--- Permit CAPF server traffic from trusted hosts allowed to !--- the RP. !--- access-list 150 permit tcp TRUSTED_SOURCE_ADDRESSES WILDCARD any eq 3804 !--- !--- Telephony-Service configuration !--- !--- !--- The TCP port is as per the ip source-address !---
port telephony-service !--- configuration command. Example below 2999 !--- !--- Permit Telephony-Service traffic from trusted hosts allowed !--- to the RP. access-list 150 permit tcp TRUSTED_SOURCE_ADDRESSES WILDCARD any eq 2999 !--- !--- Deny Cisco Unified Communications Manager Express !--- traffic from all other sources to the RP. !--- access-list 150 deny tcp any any eq 3804 access-list 150 deny tcp any any eq 2999 !--- !--- Permit SIP Gateway Signaling Support Over TLS Transport !--- traffic from trusted hosts allowed to the RP. !--- access-list 150 permit tcp TRUSTED_SOURCE_ADDRESSES WILDCARD any eq 5061 !--- !--- Deny SIP Gateway Signaling Support Over TLS Transport !--- traffic from all other sources to the RP. !--- access-list 150 deny tcp any any eq 5061 !--- !--- Permit Secure Signaling and Media Encryption traffic !--- from trusted hosts allowed to the RP. !--- access-list 150 permit tcp TRUSTED_SOURCE_ADDRESSES WILDCARD any eq 2443 !--- !--- Deny Secure Signaling and Media Encryption traffic from !--- all other sources to the RP. !--- access-list 150 deny tcp any any eq 2443 !--- !--- Feature: Blocks Extensible Exchange Protocol (BEEP) !--- The TCP port used is defined with the netconf beep initiator !--- and netconf beep listener configuration commands. !--- This example uses 3001 !--- !--- !--- Permit BEEP traffic from trusted hosts allowed to the RP. !--- access-list 150 permit tcp TRUSTED_SOURCE_ADDRESSES WILDCARD any eq 3001 !--- !--- Deny BEEP traffic from all other sources to the RP. !--- access-list 150 deny tcp any any eq 3001 !--- !--- Feature: Network Admission Control HTTP Authentication Proxy !--- and !--- Per-user URL Redirect for EAP over UDP, Dot1x and MAC !--- Authentication Bybass !--- !--- !--- Permit Per-user URL Redirect for EAP over UDP, Dot1x and MAC !--- Authentication Bybass traffic from trusted hosts allowed to !--- the RP. !--- access-list 150 permit tcp TRUSTED_SOURCE_ADDRESSES WILDCARD any eq 80 access-list 150 permit tcp TRUSTED_SOURCE_ADDRESSES WILDCARD any eq 443 !--- !--- Deny Network Admission Control HTTP Authentication Proxy !--- and !--- Per-user URL Redirect for EAP over UDP, Dot1x and MAC !--- Authentication Bybass traffic from all other sources to !--- the RP. !--- access-list 150 deny tcp any any eq 80 access-list 150 deny tcp any any eq 443 !--- !--- Features: Distributed Director with HTTP Redirects and DNS !--- !--- !--- Permit Distribute Director and DNS traffic from trusted hosts !--- allowed to the RP. !--- access-list 150 permit tcp TRUSTED_SOURCE_ADDRESSES WILDCARD any eq 53 !--- !--- Deny distributed director and DNS traffic from all other !--- sources to the RP. !--- access-list 150 deny tcp any any eq 53 !--- !--- Permit all other traffic to the RP. !--- according to security policy and configurations. !--- access-list 150 permit ip any any !--- !--- Apply this access list to the 'receive' path. !--- ip receive access-list 150 Control Plane Policing +--------------------- Control Plane Policing (CoPP) can be used to block the affected features TCP traffic access to the device. Cisco IOS software releases 12.0S, 12.2SX, 12.2S, 12.3T, 12.4, and 12.4T support the CoPP feature. CoPP can be configured on a device to protect the management and control planes and minimize the risk and effectiveness of direct infrastructure attacks by explicitly permitting only authorized traffic that is sent to infrastructure devices in accordance with existing security policies and configurations. The CoPP example below should be included as part of the deployed CoPP which will protect all devices with IP addresses in the infrastructure IP address range. !--- !--- Only sections pertaining to features enabled on the device !--- need be configured. !--- !--- Feature: Cisco Unified Communications Manager Express !--- !--- CAPF Server configuration !--- access-list 150 deny tcp TRUSTED_SOURCE_ADDRESSES WILDCARD any eq 3804 !--- !--- Telephony-Service configuration !--- The TCP port is as per the ip source-address !---
port telephony-service !--- configuration command. Example below 2999 !--- access-list 150 deny tcp TRUSTED_SOURCE_ADDRESSES WILDCARD any eq 2999 !--- !--- Permit Cisco Unified Communications Manager Express traffic !--- sent to all IP addresses configured on all interfaces of !--- the affected device so that it will be policed and dropped !--- by the CoPP feature !--- !--- CAPF server configuration !--- access-list 150 permit tcp any any eq 3804 !--- !--- Telephony-Service configuration !--- access-list 150 permit tcp any any eq 2999 !--- !--- Feature: SIP Gateway Signaling Support Over TLS Transport !--- access-list 150 deny tcp TRUSTED_SOURCE_ADDRESSES WILDCARD any eq 5061 !--- !--- Permit SIP Gateway Signaling Support Over TLS Transport !--- traffic sent to all IP addresses configured on all interfaces !--- of the affected device so that it will be policed and !--- dropped by the CoPP feature !--- access-list 150 permit tcp any any eq 5061 !--- !--- Feature: Secure Signaling and Media Encryption !--- access-list 150 deny tcp TRUSTED_SOURCE_ADDRESSES WILDCARD any eq 2443 !--- !--- Permit Secure Signaling and Media Encryption traffic sent to !--- all IP addresses configured on all interfaces of the affected !--- device so that it will be policed and dropped by the CoPP !--- feature !--- access-list 150 permit tcp any any eq 2443 !--- !--- Feature: Blocks Extensible Exchange Protocol (BEEP) !--- The TCP port used is defined with the netconf beep initiator !--- and netconf beep listener configuration commands. !--- This example uses 3001 !--- access-list 150 deny tcp TRUSTED_SOURCE_ADDRESSES WILDCARD any eq 3001 !--- !--- Permit BEEP traffic sent to all IP addresses configured !--- on all interfaces of the affected device so that it !--- will be policed and dropped by the CoPP feature !--- access-list 150 permit tcp any any eq 3001 !--- !--- Feature: Network Admission Control HTTP Authentication Proxy !--- and !--- Per-user URL Redirect for EAP over UDP, Dot1x and MAC !--- Authentication Bybass !--- access-list 150 deny tcp TRUSTED_SOURCE_ADDRESSES WILDCARD any eq 80 access-list 150 deny tcp TRUSTED_SOURCE_ADDRESSES WILDCARD any eq 443 !--- !--- Permit Network Admission Control HTTP Authentication Proxy !--- and Per-user URL Redirect for EAP over UDP, Dot1x and MAC !--- Authentication Bybass traffic sent to all IP addresses !--- configured on all interfaces of the affected device so that it !--- will be policed and dropped by the CoPP feature !--- access-list 150 permit tcp any any eq 80 access-list 150 permit tcp any any eq 443 !--- !--- Features: Distributed Director with HTTP Redirects and DNS !--- access-list 150 deny tcp TRUSTED_SOURCE_ADDRESSES WILDCARD any eq 53 !--- !--- Permit Distributed Director with HTTP Redirects and DNS !--- traffic sent to all IP addresses configured on all interfaces !--- of the affected device so that it will be policed and dropped !--- by the CoPP feature !--- access-list 150 permit tcp any any eq 53 !--- !--- Permit (Police or Drop)/Deny (Allow) all other Layer3 and !--- Layer4 traffic in accordance with existing security policies !--- and configurations for traffic that is authorized to be sent !--- to infrastructure devices !--- !--- !--- Create a Class-Map for traffic to be policed by !--- the CoPP feature !--- class-map match-all drop-tcpip-class match access-group 150 !--- !--- Create a Policy-Map that will be applied to the !--- Control-Plane of the device. !--- policy-map drop-tcpip-traffic class drop-tcpip-class drop !--- !--- Apply the Policy-Map to the !--- Control-Plane of the device !--- control-plane service-policy input drop-tcpip-traffic In the above CoPP example, the access control list entries (ACEs) that match the potential exploit packets with the "permit" action result in these packets being discarded by the policy-map "drop" function, while packets that match the "deny" action (not shown) are not affected by the policy-map drop function. Please note that the policy-map syntax is different in the 12.2S and 12.0S Cisco IOS trains: policy-map drop-tcpip-traffic class drop-tcpip-class police 32000 1500 1500 conform-action drop exceed-action drop Additional information on the configuration and use of the CoPP feature can be found in the documents, "Control Plane Policing Implementation Best Practices" and "Cisco IOS Software Releases 12.2 S - Control Plane Policing" at the following links http://www.cisco.com/web/about/security/intelligence/coppwp_gs.html and http://www.cisco.com/en/US/docs/ios/12_3t/12_3t4/feature/guide/gtrtlimt.html Additional mitigations that can be deployed on Cisco devices within the network are available in the "Cisco Applied Mitigation Bulletin" companion document for this advisory at the following link http://www.cisco.com/warp/public/707/cisco-amb-20090325-tcp-and-ip.shtml Obtaining Fixed Software ======================== Cisco has released free software updates that address these vulnerabilities. Prior to deploying software, customers should consult their maintenance provider or check the software for feature set compatibility and known issues specific to their environment. Customers may only install and expect support for the feature sets they have purchased. By installing, downloading, accessing or otherwise using such software upgrades, customers agree to be bound by the terms of Cisco's software license terms found at http://www.cisco.com/en/US/docs/general/warranty/English/EU1KEN_.html, or as otherwise set forth at Cisco.com Downloads at http://www.cisco.com/public/sw-center/sw-usingswc.shtml Do not contact psirt at cisco.com or security-alert at cisco.com for software upgrades. Customers with Service Contracts +------------------------------- Customers with contracts should obtain upgraded software through their regular update channels. For most customers, this means that upgrades should be obtained through the Software Center on Cisco's worldwide website at http://www.cisco.com Customers using Third Party Support Organizations +------------------------------------------------ Customers whose Cisco products are provided or maintained through prior or existing agreements with third-party support organizations, such as Cisco Partners, authorized resellers, or service providers should contact that support organization for guidance and assistance with the appropriate course of action in regards to this advisory. The effectiveness of any workaround or fix is dependent on specific customer situations, such as product mix, network topology, traffic behavior, and organizational mission. Due to the variety of affected products and releases, customers should consult with their service provider or support organization to ensure any applied workaround or fix is the most appropriate for use in the intended network before it is deployed. Customers without Service Contracts +---------------------------------- Customers who purchase direct from Cisco but do not hold a Cisco service contract, and customers who purchase through third-party vendors but are unsuccessful in obtaining fixed software through their point of sale should acquire upgrades by contacting the Cisco Technical Assistance Center (TAC). TAC contacts are as follows. * +1 800 553 2447 (toll free from within North America) * +1 408 526 7209 (toll call from anywhere in the world) * e-mail: tac at cisco.com Customers should have their product serial number available and be prepared to give the URL of this notice as evidence of entitlement to a free upgrade. Free upgrades for non-contract customers must be requested through the TAC. Refer to http://www.cisco.com/en/US/support/tsd_cisco_worldwide_contacts.html for additional TAC contact information, including localized telephone numbers, and instructions and e-mail addresses for use in various languages. Exploitation and Public Announcements ===================================== The Cisco PSIRT is not aware of any public announcements or malicious use of the vulnerability described in this advisory. This vulnerability was discovered by Cisco when performing internal vulnerability testing. We would also like to thank Jens Link, freelance consultant, for also reporting this vulnerability to us. Status of this Notice: FINAL ============================ THIS DOCUMENT IS PROVIDED ON AN "AS IS" BASIS AND DOES NOT IMPLY ANY KIND OF GUARANTEE OR WARRANTY, INCLUDING THE WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR USE. YOUR USE OF THE INFORMATION ON THE DOCUMENT OR MATERIALS LINKED FROM THE DOCUMENT IS AT YOUR OWN RISK. CISCO RESERVES THE RIGHT TO CHANGE OR UPDATE THIS DOCUMENT AT ANY TIME. A stand-alone copy or Paraphrase of the text of this document that omits the distribution URL in the following section is an uncontrolled copy, and may lack important information or contain factual errors. Distribution ============ This advisory is posted on Cisco's worldwide website at : http://www.cisco.com/warp/public/707/cisco-sa-20090325-tcpip.shtml In addition to worldwide web posting, a text version of this notice is clear-signed with the Cisco PSIRT PGP key and is posted to the following e-mail and Usenet news recipients. * cust-security-announce at cisco.com * first-bulletins at lists.first.org * bugtraq at securityfocus.com * vulnwatch at vulnwatch.org * cisco at spot.colorado.edu * cisco-nsp at puck.nether.net * full-disclosure at lists.grok.org.uk * comp.dcom.sys.cisco at newsgate.cisco.com Future updates of this advisory, if any, will be placed on Cisco's worldwide website, but may or may not be actively announced on mailing lists or newsgroups. Users concerned about this problem are encouraged to check the above URL for any updates. Revision History ================ +---------------------------------------+ | Revision | | Initial | | 1.0 | 2009-March-25 | public | | | | release. | +---------------------------------------+ Cisco Security Procedures ========================= Complete information on reporting security vulnerabilities in Cisco products, obtaining assistance with security incidents, and registering to receive security information from Cisco, is available on Cisco's worldwide website at http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html This includes instructions for press inquiries regarding Cisco security notices. All Cisco security advisories are available at http://www.cisco.com/go/psirt -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAknKUasACgkQ86n/Gc8U/uBbjACeIwNWs1Rt18l5RAnnaMCvg4GA kK0AnjoeX6PBI/y6tro0tjJUCfrAAr30 =Ijff -----END PGP SIGNATURE----- From psirt at cisco.com Wed Mar 25 11:00:00 2009 From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team) Date: Wed, 25 Mar 2009 17:00:00 +0100 Subject: Cisco Security Advisory: Cisco IOS Software Session Initiation Protocol Denial of Service Vulnerability Message-ID: <200903251705.sip@psirt.cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Cisco Security Advisory: Cisco IOS Software Session Initiation Protocol Denial of Service Vulnerability Advisory ID: cisco-sa-20090325-sip http://www.cisco.com/warp/public/707/cisco-sa-20090325-sip.shtml Revision 1.0 For Public Release 2009 March 25 1600 UTC (GMT) - --------------------------------------------------------------------- Summary ======= A vulnerability exists in the Session Initiation Protocol (SIP) implementation in Cisco IOS Software that can be exploited remotely to cause a reload of the Cisco IOS device. Cisco has released free software updates that address this vulnerability. There are no workarounds available to mitigate the vulnerability apart from disabling SIP, if the Cisco IOS device does not need to run SIP for VoIP services. However, mitigation techniques are available to help limit exposure to the vulnerability. This advisory is posted at the following link: http://www.cisco.com/warp/public/707/cisco-sa-20090325-sip.shtml Note: The March 25, 2009, Cisco IOS Security Advisory bundled publication includes eight Security Advisories. All of the advisories address vulnerabilities in Cisco IOS Software. Each advisory lists the releases that correct the vulnerability or vulnerabilities in the advisory. The following table lists releases that correct all Cisco IOS Software vulnerabilities that have been published in Cisco Security Advisories on March 25, 2009, or earlier. http://www.cisco.com/warp/public/707/cisco-sa-20090325-bundle.shtml Individual publication links are listed below: * Cisco IOS cTCP Denial of Service Vulnerability http://www.cisco.com/warp/public/707/cisco-sa-20090325-ctcp.shtml * Cisco IOS Software Multiple Features IP Sockets Vulnerability http://www.cisco.com/warp/public/707/cisco-sa-20090325-ip.shtml * Cisco IOS Software Mobile IP and Mobile IPv6 Vulnerabilities http://www.cisco.com/warp/public/707/cisco-sa-20090325-mobileip.shtml * Cisco IOS Software Secure Copy Privilege Escalation Vulnerability http://www.cisco.com/warp/public/707/cisco-sa-20090325-scp.shtml * Cisco IOS Software Session Initiation Protocol Denial of Service Vulnerability http://www.cisco.com/warp/public/707/cisco-sa-20090325-sip.shtml * Cisco IOS Software Multiple Features Crafted TCP Sequence Vulnerability http://www.cisco.com/warp/public/707/cisco-sa-20090325-tcp.shtml * Cisco IOS Software Multiple Features Crafted UDP Packet Vulnerability http://www.cisco.com/warp/public/707/cisco-sa-20090325-udp.shtml * Cisco IOS Software WebVPN and SSLVPN Vulnerabilities http://www.cisco.com/warp/public/707/cisco-sa-20090325-webvpn.shtml Affected Products ================= This vulnerability only affects devices running Cisco IOS Software with SIP voice services enabled. Vulnerable Products +------------------ Cisco devices running affected Cisco IOS Software versions that process SIP messages are affected. The only requirement for this vulnerability is that the Cisco IOS device process SIP messages as part of configured VoIP functionality. Note that this does not apply to the processing of SIP messages as part of the NAT and firewall feature sets. Recent versions of Cisco IOS Software do not process SIP messages by default. Creating a dial peer by way of the command dial-peer voice will start the SIP processes and cause the Cisco IOS device to start processing SIP messages. In addition, several features within Cisco Unified Communications Manager Express, such as ePhones, once configured will also automatically start the SIP process, which will cause the device to start processing SIP messages. An example of an affected configuration is as follows: dial-peer voice voip ... ! Note: Older versions of Cisco IOS Software were affected by a bug that caused Cisco IOS Software to process SIP messages without being configured for SIP operation. Refer to http://www.cisco.com/warp/ public/707/cisco-sa-20070131-sip.shtml for additional information on Cisco bug ID CSCsb25337. In addition to inspecting the Cisco IOS device configuration for a dial-peer command that causes the device to process SIP messages, administrators can also use the command show processes | include SIP to determine whether Cisco IOS Software is running the processes that handle SIP messages. In the following example, the presence of the processes CCSIP_UDP_SOCKET and CCSIP_TCP_SOCKET indicates that the Cisco IOS device is processing SIP messages: Router#show processes | include SIP 147 Mwe 40F46DF4 12 2 600023468/24000 0 CCSIP_SPI_CONTRO 148 Mwe 40F21244 0 1 0 5524/6000 0 CCSIP_DNS 149 Mwe 40F48254 4 1 400023108/24000 0 CCSIP_UDP_SOCKET 150 Mwe 40F48034 4 1 400023388/24000 0 CCSIP_TCP_SOCKET Warning: Since there are several ways a device running Cisco IOS Software can start processing SIP messages, it is recommended that the show processes | include SIP command be used to determine whether the device is processing SIP messages instead of relying on the presence of specific configuration commands. To determine the Cisco IOS Software release that is running on a Cisco product, administrators can log in to the device and issue the show version command to display the system banner. The system banner confirms that the device is running Cisco IOS Software by displaying text similar to "Cisco Internetwork Operating System Software" or "Cisco IOS Software." The image name displays in parentheses, followed by "Version" and the Cisco IOS Software release name. Other Cisco devices do not have the show version command or may provide different output. The following example identifies a Cisco product that is running Cisco IOS Software Release 12.3(26) with an installed image name of C2500-IS-L: Router#show version Cisco Internetwork Operating System Software IOS (tm) 2500 Software (C2500-IS-L), Version 12.3(26), RELEASE SOFTWARE (fc2) Technical Support: http://www.cisco.com/techsupport Copyright (c) 1986-2008 by cisco Systems, Inc. Compiled Mon 17-Mar-08 14:39 by dchih !--- output truncated The following example identifies a Cisco product that is running Cisco IOS Software Release 12.4(20)T with an installed image name of C1841-ADVENTERPRISEK9-M: Router#show version Cisco IOS Software, 1841 Software (C1841-ADVENTERPRISEK9-M), Version 12.4(20)T, RELEASE SOFTWARE (fc3) Technical Support: http://www.cisco.com/techsupport Copyright (c) 1986-2008 by Cisco Systems, Inc. Compiled Thu 10-Jul-08 20:25 by prod_rel_team !--- output truncated Additional information about Cisco IOS Software release naming conventions is available in "White Paper: Cisco IOS Reference Guide" at the following link: http://www.cisco.com/warp/public/620/1.html Products Confirmed Not Vulnerable +-------------------------------- The SIP Application Layer Gateway (ALG), which is used by the Cisco IOS NAT and firewall features of Cisco IOS Software, is not affected by this vulnerability. Cisco devices that are running Cisco IOS XE Software and Cisco IOS XR Software are not affected. No other Cisco products are currently known to be affected by this vulnerability. Details ======= SIP is a popular signaling protocol that is used to manage voice and video calls across IP networks such as the Internet. SIP is responsible for handling all aspects of call setup and termination. Voice and video are the most popular types of sessions that SIP handles, but the protocol has the flexibility to accommodate other applications that require call setup and termination. SIP call signaling can use UDP (port 5060), TCP (port 5060), or TLS (TCP port 5061) as the underlying transport protocol. A denial of service (DoS) vulnerability exists in the SIP implementation in Cisco IOS Software. This vulnerability is triggered by processing a specific and valid SIP message. This vulnerability is documented in Cisco Bug ID CSCsu11522 and has been assigned Common Vulnerabilities and Exposures (CVE) ID CVE-2009-0636. Note: The vulnerabilities described in the advisories Cisco IOS Software Multiple Features IP Sockets Vulnerability and Cisco IOS Software Multiple Features Crafted UDP Packet Vulnerability, both part of this bundle of Cisco IOS advisories, may also impact SIP operations. Vulnerability Scoring Details ============================= Cisco has provided scores for the vulnerabilities in this advisory based on the Common Vulnerability Scoring System (CVSS). The CVSS scoring in this Security Advisory is done in accordance with CVSS version 2.0. CVSS is a standards-based scoring method that conveys vulnerability severity and helps determine urgency and priority of response. Cisco has provided a base and temporal score. Customers can then compute environmental scores to assist in determining the impact of the vulnerability in individual networks. Cisco has provided an FAQ to answer additional questions regarding CVSS at http://www.cisco.com/web/about/security/intelligence/cvss-qandas.html Cisco has also provided a CVSS calculator to help compute the environmental impact for individual networks at http://intellishield.cisco.com/security/alertmanager/cvss CSCsu11522 - A voice gateway may crash when processing valid SIP CVSS Base Score - 7.8 Access Vector - Network Access Complexity - Low Authentication - None Confidentiality Impact - None Integrity Impact - None Availability Impact - Complete CVSS Temporal Score - 6.4 Exploitability - Functional Remediation Level - Official-Fix Report Confidence - Confirmed Impact ====== Successful exploitation of the vulnerability described in this document may result in a reload of the device. The issue could be repeatedly exploited to cause an extended DoS condition. Software Versions and Fixes =========================== When considering software upgrades, also consult http://www.cisco.com/go/psirt and any subsequent advisories to determine exposure and a complete upgrade solution. In all cases, customers should exercise caution to be certain the devices to be upgraded contain sufficient memory and that current hardware and software configurations will continue to be supported properly by the new release. If the information is not clear, contact the Cisco Technical Assistance Center (TAC) or your contracted maintenance provider for assistance. Each row of the Cisco IOS software table (below) names a Cisco IOS release train. If a given release train is vulnerable, then the earliest possible releases that contain the fix (along with the anticipated date of availability for each, if applicable) are listed in the "First Fixed Release" column of the table. The "Recommended Release" column indicates the releases which have fixes for all the published vulnerabilities at the time of this Advisory. A device running a release in the given train that is earlier than the release in a specific column (less than the First Fixed Release) is known to be vulnerable. Cisco recommends upgrading to a release equal to or later than the release in the "Recommended Releases" column of the table. Note: In addition to CSCsu11522 and because of its impact on SIP operation, this table of fixed software takes into consideration the vulnerability tracked by Cisco Bug CSCsk64158 , from "Cisco Security Advisory: Crafted UDP Packet Affects Multiple Cisco IOS Features" (http://www.cisco.com/warp/public/707/cisco-sa-20090325-udp.shtml) The table does not take into consideration the vulnerability disclosed by "Cisco Security Advisory: Cisco IOS IP Sockets Vulnerability Affecting Multiple Cisco IOS Features", which may impact SIP over TLS. +-------------------------------------------------------------------+ | Major | Availability of Repaired Releases | | Release | | |------------+------------------------------------------------------| | Affected | | Recommended | | 12.0-Based | First Fixed Release | Release | | Releases | | | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.0 | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.0DA | Vulnerable; first fixed in 12.2DA | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.0DB | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.0DC | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | 12.0S | 12.0(32)S12 | 12.0(32)S12 | |------------+-------------------------------------+----------------| | 12.0SC | Vulnerable; first fixed in 12.0S | 12.0(32)S12 | |------------+-------------------------------------+----------------| | 12.0SL | Vulnerable; first fixed in 12.0S | 12.0(32)S12 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.0SP | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | 12.0ST | Vulnerable; first fixed in 12.0S | 12.0(32)S12 | |------------+-------------------------------------+----------------| | 12.0SX | Vulnerable; first fixed in 12.0S | 12.0(32)S12 | |------------+-------------------------------------+----------------| | 12.0SY | 12.0(32)SY8 | 12.0(32)SY8 | |------------+-------------------------------------+----------------| | 12.0SZ | Vulnerable; first fixed in 12.0S | 12.0(32)S12 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.0T | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | 12.0W | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.0WC | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.0WT | Not Vulnerable | | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.0XA | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.0XB | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.0XC | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.0XD | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.0XE | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | 12.0XF | Not Vulnerable | | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.0XG | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.0XH | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | Releases prior to 12.0(4)XI2 are | 12.4(18e) | | | vulnerable, release 12.0(4)XI2 and | | | 12.0XI | later are not vulnerable; first | 12.4(23a); | | | fixed in 12.4 | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.0XJ | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.0XK | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.0XL | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.0XM | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.0XN | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.0XQ | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.0XR | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.0XS | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.0XT | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.0XV | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | Affected | | Recommended | | 12.1-Based | First Fixed Release | Release | | Releases | | | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.1 | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | 12.1AA | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.1AX | Vulnerable; first fixed in 12.2SE | 12.2(44)SE6 | |------------+-------------------------------------+----------------| | | | 12.1(22)EA13 | | 12.1AY | Vulnerable; first fixed in 12.1EA | | | | | 12.2(44)SE6 | |------------+-------------------------------------+----------------| | | | 12.1(22)EA13 | | 12.1AZ | Vulnerable; first fixed in 12.1EA | | | | | 12.2(44)SE6 | |------------+-------------------------------------+----------------| | 12.1CX | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.1DA | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.1DB | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.1DC | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.1E | Vulnerable; first fixed in 12.2SXF | 12.2(18)SXF16 | |------------+-------------------------------------+----------------| | 12.1EA | 12.1(22)EA13 | 12.1(22)EA13 | |------------+-------------------------------------+----------------| | 12.1EB | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | | | 12.2(33)SCB1 | | 12.1EC | Vulnerable; first fixed in 12.3BC | | | | | 12.3(23)BC6 | |------------+-------------------------------------+----------------| | 12.1EO | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.1EU | Vulnerable; first fixed in 12.2SG | 12.2(31)SGA9 | |------------+-------------------------------------+----------------| | 12.1EV | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.1EW | Vulnerable; migrate to 12.2SGA | 12.2(31)SGA9 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.1EX | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | 12.1EY | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.1EZ | Vulnerable; first fixed in 12.2SXF | 12.2(18)SXF16 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.1GA | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.1GB | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.1T | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.1XA | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.1XB | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.1XC | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.1XD | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.1XE | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.1XF | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.1XG | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.1XH | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.1XI | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.1XJ | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.1XL | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.1XM | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.1XP | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.1XQ | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.1XR | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.1XS | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.1XT | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.1XU | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.1XV | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.1XW | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.1XX | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.1XY | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.1XZ | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.1YA | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.1YB | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.1YC | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.1YD | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | Releases prior to 12.1(5)YE6 are | 12.4(18e) | | | vulnerable, release 12.1(5)YE6 and | | | 12.1YE | later are not vulnerable; first | 12.4(23a); | | | fixed in 12.4 | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.1YF | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.1YH | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | 12.1YI | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | | | 12.1(22)EA13 | | 12.1YJ | Vulnerable; first fixed in 12.1EA | | | | | 12.2(44)SE6 | |------------+-------------------------------------+----------------| | Affected | | Recommended | | 12.2-Based | First Fixed Release | Release | | Releases | | | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.2 | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.2B | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | | Vulnerable; migrate to 12.2SCB or | 12.2(33)SCB1 | | 12.2BC | 12.3BC | | | | | 12.3(23)BC6 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.2BW | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | 12.2BX | Vulnerable; migrate to 12.2SB | 12.2(33)SB4 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.2BY | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.2BZ | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | Vulnerable; migrate to 12.2SCB or | 12.2(33)SCB1 | | 12.2CX | 12.3BC | | | | | 12.3(23)BC6 | |------------+-------------------------------------+----------------| | | Vulnerable; migrate to 12.2SCB or | 12.2(33)SCB1 | | 12.2CY | 12.3BC | | | | | 12.3(23)BC6 | |------------+-------------------------------------+----------------| | 12.2CZ | Vulnerable; first fixed in 12.2SB | 12.2(33)SB4 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | 12.2(12)DA14; Available on | | | 12.2DA | 30-JUL-2009 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.2DD | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.2DX | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | 12.2EW | Vulnerable; first fixed in 12.2SG | 12.2(31)SGA9 | |------------+-------------------------------------+----------------| | 12.2EWA | Vulnerable; first fixed in 12.2SG | 12.2(31)SGA9 | |------------+-------------------------------------+----------------| | 12.2EX | Vulnerable; first fixed in 12.2SE | 12.2(44)SE6 | |------------+-------------------------------------+----------------| | 12.2EY | 12.2(44)EY | 12.2(44)SE6 | |------------+-------------------------------------+----------------| | 12.2EZ | Vulnerable; first fixed in 12.2SE | 12.2(44)SE6 | |------------+-------------------------------------+----------------| | 12.2FX | Vulnerable; first fixed in 12.2SE | 12.2(44)SE6 | |------------+-------------------------------------+----------------| | 12.2FY | Vulnerable; first fixed in 12.2SE | 12.2(44)SE6 | |------------+-------------------------------------+----------------| | 12.2FZ | Vulnerable; first fixed in 12.2SE | 12.2(44)SE6 | |------------+-------------------------------------+----------------| | | | 12.2(33)SRC4; | | 12.2IRA | Vulnerable; first fixed in 12.2SRC | Available on | | | | 18-MAY-2009 | |------------+-------------------------------------+----------------| | | | 12.2(33)SRC4; | | 12.2IRB | Vulnerable; first fixed in 12.2SRC | Available on | | | | 18-MAY-2009 | |------------+-------------------------------------+----------------| | | Vulnerable; migrate to any release | 12.2(18)IXH; | | 12.2IXA | in 12.2IXH | Available on | | | | 31-MAR-2009 | |------------+-------------------------------------+----------------| | | Vulnerable; migrate to any release | 12.2(18)IXH; | | 12.2IXB | in 12.2IXH | Available on | | | | 31-MAR-2009 | |------------+-------------------------------------+----------------| | | Vulnerable; migrate to any release | 12.2(18)IXH; | | 12.2IXC | in 12.2IXH | Available on | | | | 31-MAR-2009 | |------------+-------------------------------------+----------------| | | Vulnerable; migrate to any release | 12.2(18)IXH; | | 12.2IXD | in 12.2IXH | Available on | | | | 31-MAR-2009 | |------------+-------------------------------------+----------------| | | Vulnerable; migrate to any release | 12.2(18)IXH; | | 12.2IXE | in 12.2IXH | Available on | | | | 31-MAR-2009 | |------------+-------------------------------------+----------------| | | Vulnerable; migrate to any release | 12.2(18)IXH; | | 12.2IXF | in 12.2IXH | Available on | | | | 31-MAR-2009 | |------------+-------------------------------------+----------------| | | Vulnerable; migrate to any release | 12.2(18)IXH; | | 12.2IXG | in 12.2IXH | Available on | | | | 31-MAR-2009 | |------------+-------------------------------------+----------------| | 12.2JA | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.2JK | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.2MB | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | 12.2MC | 12.2(15)MC2m | 12.2(15)MC2m | |------------+-------------------------------------+----------------| | 12.2S | Vulnerable; first fixed in 12.2SB | 12.2(33)SB4 | |------------+-------------------------------------+----------------| | | 12.2(28)SB13 | | | | | | | 12.2SB | 12.2(31)SB14 | 12.2(33)SB4 | | | | | | | 12.2(33)SB3 | | |------------+-------------------------------------+----------------| | 12.2SBC | Vulnerable; first fixed in 12.2SB | 12.2(33)SB4 | |------------+-------------------------------------+----------------| | 12.2SCA | Vulnerable; first fixed in 12.2SCB | 12.2(33)SCB1 | |------------+-------------------------------------+----------------| | 12.2SCB | 12.2(33)SCB1 | 12.2(33)SCB1 | |------------+-------------------------------------+----------------| | | 12.2(50)SE | | | | | | | 12.2SE | 12.2(46)SE2 | 12.2(44)SE6 | | | | | | | 12.2(44)SE5 | | |------------+-------------------------------------+----------------| | 12.2SEA | Vulnerable; first fixed in 12.2SE | 12.2(44)SE6 | |------------+-------------------------------------+----------------| | 12.2SEB | Vulnerable; first fixed in 12.2SE | 12.2(44)SE6 | |------------+-------------------------------------+----------------| | 12.2SEC | Vulnerable; first fixed in 12.2SE | 12.2(44)SE6 | |------------+-------------------------------------+----------------| | 12.2SED | Vulnerable; first fixed in 12.2SE | 12.2(44)SE6 | |------------+-------------------------------------+----------------| | 12.2SEE | Vulnerable; first fixed in 12.2SE | 12.2(44)SE6 | |------------+-------------------------------------+----------------| | 12.2SEF | Vulnerable; first fixed in 12.2SE | 12.2(44)SE6 | |------------+-------------------------------------+----------------| | 12.2SEG | Vulnerable; first fixed in 12.2SE | 12.2(44)SE6 | |------------+-------------------------------------+----------------| | | | 12.2(52)SG; | | 12.2SG | 12.2(50)SG | Available on | | | | 15-MAY-2009 | |------------+-------------------------------------+----------------| | 12.2SGA | 12.2(31)SGA9 | 12.2(31)SGA9 | |------------+-------------------------------------+----------------| | 12.2SL | Not Vulnerable | | |------------+-------------------------------------+----------------| | 12.2SM | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.2SO | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.2SQ | 12.2(44)SQ1 | | |------------+-------------------------------------+----------------| | | | 12.2(33)SRD1 | | | | | | 12.2SRA | Vulnerable; first fixed in 12.2SRC | 12.2(33)SRC4; | | | | Available on | | | | 18-MAY-2009 | |------------+-------------------------------------+----------------| | | | 12.2(33)SRC4; | | | | Available on | | | | 18-MAY-2009 | | | | | | 12.2SRB | Vulnerable; first fixed in 12.2SRC | 12.2(33)SRD1 | | | | | | | | 12.2(33)SRB5a; | | | | Available on | | | | 3-April-2009 | |------------+-------------------------------------+----------------| | | 12.2(33)SRC4; Available on | 12.2(33)SRC4; | | 12.2SRC | 18-MAY-2009 | Available on | | | | 18-MAY-2009 | |------------+-------------------------------------+----------------| | 12.2SRD | Not Vulnerable | | |------------+-------------------------------------+----------------| | 12.2STE | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.2SU | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | 12.2SV | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.2SVA | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.2SVC | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.2SVD | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.2SVE | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.2SW | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.2SX | Vulnerable; first fixed in 12.2SXF | 12.2(18)SXF16 | |------------+-------------------------------------+----------------| | 12.2SXA | Vulnerable; first fixed in 12.2SXF | 12.2(18)SXF16 | |------------+-------------------------------------+----------------| | 12.2SXB | Vulnerable; first fixed in 12.2SXF | 12.2(18)SXF16 | |------------+-------------------------------------+----------------| | 12.2SXD | Vulnerable; first fixed in 12.2SXF | 12.2(18)SXF16 | |------------+-------------------------------------+----------------| | 12.2SXE | Vulnerable; first fixed in 12.2SXF | 12.2(18)SXF16 | |------------+-------------------------------------+----------------| | 12.2SXF | 12.2(18)SXF16 | 12.2(18)SXF16 | |------------+-------------------------------------+----------------| | | 12.2(33)SXH5; Available on | 12.2(33)SXH5; | | 12.2SXH | 20-APR-2009 | Available on | | | | 20-APR-2009 | |------------+-------------------------------------+----------------| | 12.2SXI | Not Vulnerable | | |------------+-------------------------------------+----------------| | 12.2SY | Vulnerable; first fixed in 12.2SB | 12.2(33)SB4 | |------------+-------------------------------------+----------------| | 12.2SZ | Vulnerable; first fixed in 12.2SB | 12.2(33)SB4 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.2T | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | 12.2TPC | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.2XA | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.2XB | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.2XC | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.2XD | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.2XE | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | Vulnerable; migrate to 12.2SCB or | 12.2(33)SCB1 | | 12.2XF | 12.3BC | | | | | 12.3(23)BC6 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.2XG | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.2XH | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.2XI | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.2XJ | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.2XK | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.2XL | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.2XM | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.2(33)SB4 | | 12.2XN | Vulnerable; first fixed in 12.2SRC | | | | | 12.2(33)SRD1 | |------------+-------------------------------------+----------------| | 12.2XNA | Vulnerable; migrate to any release | 12.2(33)SRD1 | | | in 12.2SRD | | |------------+-------------------------------------+----------------| | 12.2XNB | 12.2(33)XNB1 | 12.2(33)XNB3 | |------------+-------------------------------------+----------------| | 12.2XNC | Not Vulnerable | | |------------+-------------------------------------+----------------| | 12.2XO | 12.2(46)XO | 12.2(46)XO | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.2XQ | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.2XR | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.2XS | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.2XT | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.2XU | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.2XV | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.2XW | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.2YA | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | 12.2YB | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.2YC | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.2YD | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.2YE | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.2YF | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.2YG | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.2YH | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.2YJ | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.2YK | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.2YL | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.2YM | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | 12.2YN | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.2YO | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.2YP | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | 12.2YQ | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.2YR | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.2YS | Not Vulnerable | | |------------+-------------------------------------+----------------| | 12.2YT | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.2YU | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.2YV | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.2YW | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.2YX | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.2YY | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.2YZ | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.2ZA | Vulnerable; first fixed in 12.2SXF | 12.2(18)SXF16 | |------------+-------------------------------------+----------------| | 12.2ZB | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.2ZC | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.2ZD | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.2ZE | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.2ZF | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.2ZG | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.2ZH | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | 12.2ZJ | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.2ZL | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.2ZP | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | | | 12.2(33)SXH5; | | 12.2ZU | Vulnerable; first fixed in 12.2SXH | Available on | | | | 20-APR-2009 | |------------+-------------------------------------+----------------| | 12.2ZX | Vulnerable; first fixed in 12.2SB | 12.2(33)SB4 | |------------+-------------------------------------+----------------| | 12.2ZY | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.2ZYA | 12.2(18)ZYA1 | 12.2(18)ZYA1 | |------------+-------------------------------------+----------------| | Affected | | Recommended | | 12.3-Based | First Fixed Release | Release | | Releases | | | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.3 | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.3B | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | 12.3BC | 12.3(23)BC6 | 12.3(23)BC6 | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.3BW | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | 12.3EU | Not Vulnerable | | |------------+-------------------------------------+----------------| | 12.3JA | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.3JEA | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.3JEB | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.3JEC | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.3JK | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | 12.3JL | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.3JX | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.3T | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | 12.3TPC | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.3VA | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.3XA | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | 12.3XB | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.3XC | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.3XD | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.3XE | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | 12.3XF | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.3XG | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | 12.3XI | Vulnerable; first fixed in 12.2SB | 12.2(33)SB4 | |------------+-------------------------------------+----------------| | 12.3XJ | Vulnerable; first fixed in 12.3YX | 12.3(14)YX14 | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.3XK | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.3XL | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.3XQ | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.3XR | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.3XS | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.3XU | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | 12.3XW | Vulnerable; first fixed in 12.3YX | 12.3(14)YX14 | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.3XX | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.3XY | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.3XZ | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.3YA | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.3YD | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | 12.3YF | Vulnerable; first fixed in 12.3YX | 12.3(14)YX14 | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.3YG | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.3YH | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.3YI | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.3YJ | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.3YK | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | 12.3YM | 12.3(14)YM13 | 12.3(14)YM13 | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.3YQ | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.3YS | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.3YT | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.3YU | Vulnerable; first fixed in 12.4XB | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | 12.3YX | 12.3(14)YX14 | 12.3(14)YX14 | |------------+-------------------------------------+----------------| | 12.3YZ | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.3ZA | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | Affected | | Recommended | | 12.4-Based | First Fixed Release | Release | | Releases | | | |------------+-------------------------------------+----------------| | | 12.4(18e) | 12.4(18e) | | | | | | 12.4 | 12.4(23) | 12.4(23a); | | | | Available on | | | 12.4(23a); Available on 30-APR-2009 | 30-APR-2009 | |------------+-------------------------------------+----------------| | 12.4JA | 12.4(16b)JA1 | | |------------+-------------------------------------+----------------| | 12.4JDA | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.4JK | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.4JL | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.4JMA | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.4JMB | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.4JX | Vulnerable; first fixed in 12.4JA | | |------------+-------------------------------------+----------------| | 12.4MD | 12.4(11)MD7 | 12.4(11)MD7 | |------------+-------------------------------------+----------------| | 12.4MR | 12.4(19)MR1 | 12.4(19)MR2 | |------------+-------------------------------------+----------------| | 12.4SW | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | | 12.4(20)T2 | | | | | 12.4(22)T1 | | | 12.4(15)T8 | | | 12.4T | | 12.4(15)T9; | | | 12.4(22)T | Available on | | | | 29-APR-2009 | | | 12.4(15)T9; Available on | | | | 29-APR-2009 | | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.4XA | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | | 12.4(15)T8 | 12.4(22)T1 | | | | | | 12.4XB | 12.4(20)T2 | 12.4(15)T9; | | | | Available on | | | 12.4(15)T9; Available on | 29-APR-2009 | | | 29-APR-2009 | | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.4XC | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | | 12.4(4)XD12; Available on | 12.4(4)XD12; | | 12.4XD | 27-MAR-2009 | Available on | | | | 27-MAR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.4XE | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.4XF | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | 12.4(15)T8 | | | 12.4XG | | 12.4(15)T9; | | | 12.4(20)T2 | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.4XJ | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.4XK | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | 12.4XL | 12.4(15)XL4 | 12.4(15)XL4 | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.4XM | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | 12.4XN | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.4XP | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.4XQ | 12.4(15)XQ2 | 12.4(15)XQ2 | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.4XR | 12.4(15)XR4 | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.4XT | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | 12.4XV | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.4XW | 12.4(11)XW10 | 12.4(11)XW10 | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.4XY | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | 12.4XZ | 12.4(15)XZ2 | 12.4(15)XZ2 | |------------+-------------------------------------+----------------| | 12.4YA | 12.4(20)YA2 | 12.4(20)YA3 | |------------+-------------------------------------+----------------| | 12.4YB | Not Vulnerable | | |------------+-------------------------------------+----------------| | 12.4YD | Not Vulnerable | | +-------------------------------------------------------------------+ Workarounds =========== If the affected Cisco IOS device requires SIP for VoIP services, SIP cannot be disabled, and therefore, no workarounds are available. Users are advised to apply mitigation techniques to help limit exposure to the vulnerability. Mitigation consists of allowing only legitimate devices to connect to the routers. To increase effectiveness, the mitigation must be coupled with anti-spoofing measures on the network edge. This action is required because SIP can use UDP as the transport protocol. Additional mitigations that can be deployed on Cisco devices within the network are available in the companion document "Cisco Applied Mitigation Bulletin: Identifying and Mitigating Exploitation of the Cisco IOS SIP and Crafted UDP Vulnerabilities", which is available at the following location: http://www.cisco.com/warp/public/707/cisco-amb-20090325-sip-and-udp.shtml Disable SIP Listening Ports +-------------------------- For devices that do not require SIP to be enabled, the simplest and most effective workaround is to disable SIP processing on the device. Some versions of Cisco IOS Software allow administrators to accomplish this with the following commands: sip-ua no transport udp no transport tcp Warning: When applying this workaround to devices that are processing Media Gateway Control Protocol (MGCP) or H.323 calls, the device will not stop SIP processing while active calls are being processed. Under these circumstances, this workaround should be implemented during a maintenance window when active calls can be briefly stopped. After applying this workaround, administrators are advised to use the show commands, as discussed in the Affected Products section of this advisory, to confirm that the Cisco IOS device is no longer processing SIP messages. Control Plane Policing +--------------------- For devices that need to offer SIP services it is possible to use Control Plane Policing (CoPP) to block SIP traffic to the device from untrusted sources. Cisco IOS Releases 12.0S, 12.2SX, 12.2S, 12.3T, 12.4, and 12.4T support the CoPP feature. CoPP may be configured on a device to protect the management and control planes to minimize the risk and effectiveness of direct infrastructure attacks by explicitly permitting only authorized traffic sent to infrastructure devices in accordance with existing security policies and configurations. The following example can be adapted to the network: !-- The 192.168.1.0/24 network and the 172.16.1.1 host are trusted. !-- Everything else is not trusted. The following access list is used !-- to determine what traffic needs to be dropped by a control plane !-- policy (the CoPP feature.) If the access list matches (permit) !-- then traffic will be dropped and if the access list does not !-- match (deny) then traffic will be processed by the router. access-list 100 deny udp 192.168.1.0 0.0.0.255 any eq 5060 access-list 100 deny tcp 192.168.1.0 0.0.0.255 any eq 5060 access-list 100 deny tcp 192.168.1.0 0.0.0.255 any eq 5061 access-list 100 deny udp host 172.16.1.1 any eq 5060 access-list 100 deny tcp host 172.16.1.1 any eq 5060 access-list 100 deny tcp host 172.16.1.1 any eq 5061 access-list 100 permit udp any any eq 5060 access-list 100 permit tcp any any eq 5060 access-list 100 permit tcp any any eq 5061 !-- Permit (Police or Drop)/Deny (Allow) all other Layer3 and Layer4 !-- traffic in accordance with existing security policies and !-- configurations for traffic that is authorized to be sent !-- to infrastructure devices. !-- Create a Class-Map for traffic to be policed by !-- the CoPP feature. class-map match-all drop-sip-class match access-group 100 !-- Create a Policy-Map that will be applied to the !-- Control-Plane of the device. policy-map drop-sip-traffic class drop-sip-class drop !-- Apply the Policy-Map to the Control-Plane of the !-- device. control-plane service-policy input drop-sip-traffic Warning: Because SIP can use UDP as a transport protocol, it is possible to easily spoof the IP address of the sender, which may defeat access control lists that permit communication to these ports from trusted IP addresses. In the above CoPP example, the access control entries (ACEs) that match the potential exploit packets with the "permit" action result in these packets being discarded by the policy-map "drop" function, while packets that match the "deny" action (not shown) are not affected by the policy-map drop function. Additional information on the configuration and use of the CoPP feature can be found at http://www.cisco.com/web/about/security/intelligence/coppwp_gs.html and http://www.cisco.com/en/US/docs/ios/12_3t/12_3t4/feature/guide/gtrtlimt.html Obtaining Fixed Software ======================== Cisco has released free software updates that address these vulnerabilities. Prior to deploying software, customers should consult their maintenance provider or check the software for feature set compatibility and known issues specific to their environment. Customers may only install and expect support for the feature sets they have purchased. By installing, downloading, accessing or otherwise using such software upgrades, customers agree to be bound by the terms of Cisco's software license terms found at http://www.cisco.com/en/US/docs/general/warranty/English/EU1KEN_.html, or as otherwise set forth at Cisco.com Downloads at http://www.cisco.com/public/sw-center/sw-usingswc.shtml Do not contact psirt at cisco.com or security-alert at cisco.com for software upgrades. Customers with Service Contracts +------------------------------- Customers with contracts should obtain upgraded software through their regular update channels. For most customers, this means that upgrades should be obtained through the Software Center on Cisco's worldwide website at http://www.cisco.com Customers using Third Party Support Organizations +------------------------------------------------ Customers whose Cisco products are provided or maintained through prior or existing agreements with third-party support organizations, such as Cisco Partners, authorized resellers, or service providers should contact that support organization for guidance and assistance with the appropriate course of action in regards to this advisory. The effectiveness of any workaround or fix is dependent on specific customer situations, such as product mix, network topology, traffic behavior, and organizational mission. Due to the variety of affected products and releases, customers should consult with their service provider or support organization to ensure any applied workaround or fix is the most appropriate for use in the intended network before it is deployed. Customers without Service Contracts +---------------------------------- Customers who purchase direct from Cisco but do not hold a Cisco service contract, and customers who purchase through third-party vendors but are unsuccessful in obtaining fixed software through their point of sale should acquire upgrades by contacting the Cisco Technical Assistance Center (TAC). TAC contacts are as follows. * +1 800 553 2447 (toll free from within North America) * +1 408 526 7209 (toll call from anywhere in the world) * e-mail: tac at cisco.com Customers should have their product serial number available and be prepared to give the URL of this notice as evidence of entitlement to a free upgrade. Free upgrades for non-contract customers must be requested through the TAC. Refer to http://www.cisco.com/en/US/support/tsd_cisco_worldwide_contacts.html for additional TAC contact information, including localized telephone numbers, and instructions and e-mail addresses for use in various languages. Exploitation and Public Announcements ===================================== The Cisco PSIRT is not aware of any public announcements or malicious use of the vulnerability described in this advisory. This vulnerability was discovered during handling of customer service requests. Status of this Notice: FINAL ============================ THIS DOCUMENT IS PROVIDED ON AN "AS IS" BASIS AND DOES NOT IMPLY ANY KIND OF GUARANTEE OR WARRANTY, INCLUDING THE WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR USE. YOUR USE OF THE INFORMATION ON THE DOCUMENT OR MATERIALS LINKED FROM THE DOCUMENT IS AT YOUR OWN RISK. CISCO RESERVES THE RIGHT TO CHANGE OR UPDATE THIS DOCUMENT AT ANY TIME. A stand-alone copy or Paraphrase of the text of this document that omits the distribution URL in the following section is an uncontrolled copy, and may lack important information or contain factual errors. Distribution ============ This advisory is posted on Cisco's worldwide website at : http://www.cisco.com/warp/public/707/cisco-sa-20090325-sip.shtml In addition to worldwide web posting, a text version of this notice is clear-signed with the Cisco PSIRT PGP key and is posted to the following e-mail and Usenet news recipients. * cust-security-announce at cisco.com * first-bulletins at lists.first.org * bugtraq at securityfocus.com * vulnwatch at vulnwatch.org * cisco at spot.colorado.edu * cisco-nsp at puck.nether.net * full-disclosure at lists.grok.org.uk * comp.dcom.sys.cisco at newsgate.cisco.com Future updates of this advisory, if any, will be placed on Cisco's worldwide website, but may or may not be actively announced on mailing lists or newsgroups. Users concerned about this problem are encouraged to check the above URL for any updates. Revision History ================ +---------------------------------------+ | Revision | | Initial | | 1.0 | 2009-March-25 | public | | | | release | +---------------------------------------+ Cisco Security Procedures ========================= Complete information on reporting security vulnerabilities in Cisco products, obtaining assistance with security incidents, and registering to receive security information from Cisco, is available on Cisco's worldwide website at http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html This includes instructions for press inquiries regarding Cisco security notices. All Cisco security advisories are available at http://www.cisco.com/go/psirt -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAknKUboACgkQ86n/Gc8U/uCi+gCfZaAw0PuDJWKg2K42vzfdJe+h XHwAnRRdQQTeuhmW0liolMtU1ZzKg+Ke =VvxT -----END PGP SIGNATURE----- From psirt at cisco.com Wed Mar 25 11:00:00 2009 From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team) Date: Wed, 25 Mar 2009 17:00:00 +0100 Subject: Cisco Security Advisory: Cisco IOS Software Multiple Features Crafted UDP Packet Vulnerability Message-ID: <200903251705.udp@psirt.cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Cisco Security Advisory: Cisco IOS Software Multiple Features Crafted UDP Packet Vulnerability Advisory ID: cisco-sa-20090325-udp http://www.cisco.com/warp/public/707/cisco-sa-20090325-udp.shtml Revision 1.0 For Public Release 2009 March 25 1600 UTC (GMT) - --------------------------------------------------------------------- Summary ======= Several features within Cisco IOS Software are affected by a crafted UDP packet vulnerability. If any of the affected features are enabled, a successful attack will result in a blocked input queue on the inbound interface. Only crafted UDP packets destined for the device could result in the interface being blocked, transit traffic will not block the interface. Cisco has released free software updates that address this vulnerability. Workarounds that mitigate this vulnerability are available. This advisory is posted at the following link: http://www.cisco.com/warp/public/707/cisco-sa-20090325-udp.shtml Note: The March 25, 2009, Cisco IOS Security Advisory bundled publication includes eight Security Advisories. All of the advisories address vulnerabilities in Cisco IOS Software. Each advisory lists the releases that correct the vulnerability or vulnerabilities in the advisory. The following table lists releases that correct all Cisco IOS Software vulnerabilities that have been published in Cisco Security Advisories on March 25, 2009, or earlier. http://www.cisco.com/warp/public/707/cisco-sa-20090325-bundle.shtml Individual publication links are listed below: * Cisco IOS cTCP Denial of Service Vulnerability http://www.cisco.com/warp/public/707/cisco-sa-20090325-ctcp.shtml * Cisco IOS Software Multiple Features IP Sockets Vulnerability http://www.cisco.com/warp/public/707/cisco-sa-20090325-ip.shtml * Cisco IOS Software Mobile IP and Mobile IPv6 Vulnerabilities http://www.cisco.com/warp/public/707/ cisco-sa-20090325-mobileip.shtml * Cisco IOS Software Secure Copy Privilege Escalation Vulnerability http://www.cisco.com/warp/public/707/cisco-sa-20090325-scp.shtml * Cisco IOS Software Session Initiation Protocol Denial of Service Vulnerability http://www.cisco.com/warp/public/707/cisco-sa-20090325-sip.shtml * Cisco IOS Software Multiple Features Crafted TCP Sequence Vulnerability http://www.cisco.com/warp/public/707/cisco-sa-20090325-tcp.shtml * Cisco IOS Software Multiple Features Crafted UDP Packet Vulnerability http://www.cisco.com/warp/public/707/cisco-sa-20090325-udp.shtml * Cisco IOS Software WebVPN and SSLVPN Vulnerabilities http://www.cisco.com/warp/public/707/cisco-sa-20090325-webvpn.shtml Affected Products ================= Vulnerable Products +------------------ Devices running affected versions of Cisco IOS Software and Cisco IOS XE Software are affected when running any of the following features: * IP Service Level Agreements (SLA) Responder * Session Initiation Protocol (SIP) * H.323 Annex E Call Signaling Transport * Media Gateway Control Protocol (MGCP) Details on how to see if the affected feature is enabled on a device, is provided within the details section of this advisory. To determine the Cisco IOS Software release that is running on a Cisco product, administrators can log in to the device and issue the "show version" command to display the system banner. The system banner confirms that the device is running Cisco IOS Software by displaying text similar to "Cisco Internetwork Operating System Software" or "Cisco IOS Software." The image name displays in parentheses, followed by "Version" and the Cisco IOS Software release name. Other Cisco devices do not have the "show version" command or may provide different output. The following example identifies a Cisco product that is running Cisco IOS Software Release 12.3(26) with an installed image name of C2500-IS-L: Router#show version Cisco Internetwork Operating System Software IOS (tm) 2500 Software (C2500-IS-L), Version 12.3(26), RELEASE SOFTWARE (fc2) Technical Support: http://www.cisco.com/techsupport Copyright (c) 1986-2008 by cisco Systems, Inc. Compiled Mon 17-Mar-08 14:39 by dchih The following example shows a product that is running Cisco IOS Software release 12.4(20)T with an image name of C1841-ADVENTERPRISEK9-M: Router#show version Cisco IOS Software, 1841 Software (C1841-ADVENTERPRISEK9-M), Version 12.4(20)T, RELEASE SOFTWARE (fc3) Technical Support: http://www.cisco.com/techsupport Copyright (c) 1986-2008 by Cisco Systems, Inc. Compiled Thu 10-Jul-08 20:25 by prod_rel_team Additional information about Cisco IOS Software release naming conventions is available in "White Paper: Cisco IOS Reference Guide" at the following link: http://www.cisco.com/warp/public/620/1.html Products Confirmed Not Vulnerable +-------------------------------- The following products and features are not affected by this vulnerability: * Cisco IOS XR Software * Service Assurance Agent (SAA) * Response Time Reporter (RTR) * No other feature or protocol on Cisco IOS is known to be affected No other Cisco products are currently known to be affected by this vulnerability. Details ======= A device is vulnerable if any of the features outlined below is configured and their associated UDP port number accessible. For each feature, in addition to inspecting the Cisco IOS device for vulnerable configurations, administrators can also use some show commands to determine if the Cisco IOS device is running processes that handle the UDP service, or if the device is listening on the affected UDP ports. Different versions of Cisco IOS Software have different methods of showing the UDP ports on which the Cisco IOS Software device is listening. The "show ip sockets" or "show udp" commands can be used to determine these ports. For each feature, one example is given using the above commands to show the affected UDP port number. Successful exploitation of this vulnerability can block an interface on the device. The interface type is not relevant for this vulnerability so all Ethernet based interfaces, ATM, Serial, POS and other types of interfaces can be affected. All defined sub interfaces under a main physical interface are affected if the main interface is blocked. If the attack originates over a sub interface, the main interface will block. A blocked interface will stop receiving any subsequent packets until it is unblocked. All other interfaces are not affected and they will continue receiving and transmitting packets. Only packets destined for a reachable configured IP address on any interface of the device can exploit this vulnerability. Transit traffic will not exploit this vulnerability. A symptom of this type of blocked queue is the failure of control-plane protocols such as routing protocols (OSPF, EIGRP, BGP, ISIS, etc.) and MPLS TDP/LDP to properly establish connections over an affected interface. Transit traffic may be affected once protocol timers expire on the affected device. In order to identify a blocked input interface, issue the "show interfaces" command, and search for the Input Queue line. The size of the input queue can continue to increase. If the current size, which is 76 in the example below, is equal or larger than the maximum size (default being 75), the input queue may be blocked. It is possible that a device receives a high rate of traffic destined to the control plane, and the full queue is only a transient event. In order to verify if the interface is actually blocked, shut down the interface with the shutdown interface configuration command and examine the input queue. If the input queue does not display 0 packets, the interface is blocked. Router#show interface ethernet 0/0 Ethernet0/0 is up, line protocol is up Hardware is AmdP2, address is 0050.500e.f1e0 (bia 0050.500e.f1e0) Internet address is 192.168.0.1/24 MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec, rely 255/255, load 1/255 Encapsulation ARPA, loopback not set, keepalive set (10 sec) ARP type: ARPA, ARP Timeout 04:00:00 Last input 00:00:41, output 00:00:07, output hang never Last clearing of "show interface" counters 00:07:18 Input queue: 76/75/1091/0 (size/max/drops/flushes); Total output drops: 0 IP Service Level Agreements (SLAs) Responder +------------------------------------------- Devices configured with the Cisco IOS IP Service Level Agreements (SLAs) Responder for User Datagram Protocol (UDP) echo or jitter operations feature are vulnerable. Any device configured to act as a responder is vulnerable. The following shows two different vulnerable configurations. The first being a generic IP SLA responder: ip sla responder or ip sla monitor responder The following shows this second configuration with a more specific UDP responder configured: ip sla responder ip sla responder udp-echo ipaddress 10.10.10.10 port 1025 Service Assurance Agent (SAA) and Response Time Reporter (RTR) feature are "not" affected and use the "rtr" CLI command syntax. The following example shows a configuration, which is not vulnerable: rtr responder The following example shows a device listening on the default IP SLA control channel with the affected UDP port 1967. Router#show udp Proto Remote Port Local Port In Out Stat TTY OutputIF 17 0.0.0.0 0 10.2.6.1 1967 0 0 211 0 Further information about Cisco IOS IP SLAs is available in "Cisco IOS IP SLAs Configuration Guide, Release 12.4 - Cisco IOS IP SLAs Overview" at the following link: http://www.cisco.com/en/US/docs/ios/12_4/ip_sla/configuration/guide/hsoverv.html Session Initiation Protocol (SIP) +-------------------------------- Note: For customers with devices enabled with SIP, please also consult the document "Cisco Security Advisory: Cisco IOS Session Initiation Protocol Denial of Service Vulnerability" at the following link: http://www.cisco.com/warp/public/707/cisco-sa-20090325-sip.html Cisco devices that process SIP messages are affected. Recent versions of Cisco IOS Software do not process SIP messages by default. Creating a "dial peer" via the command "dial-peer voice" with any option will start the SIP processes and cause Cisco IOS Software to begin processing SIP messages. Several features within Cisco Call Manager Express, such as ePhones, once configured will also automatically start the SIP process and the device will begin processing SIP messages. It is recommended if the device is running any voice configurations to confirm the existence of the SIP process with the "show ip socket" or "show udp" command. The following is one example of an affected configuration: dial-peer voice voip ... ! Note: Older versions of Cisco IOS Software were affected by a bug that caused Cisco IOS Software to process SIP messages even without being configured for SIP operation. Please refer to "Cisco Security Advisory: SIP Packets Reload IOS Devices with support for SIP" at the following link: http://www.cisco.com/warp/public/707/cisco-sa-20070131-sip.shtml The following example shows a device that will process SIP messages, on the default affected UDP port 5060: Router#show ip socket Proto Remote Port Local Port In Out Stat TTY OutputIF 17 0.0.0.0 0 192.168.0.2 5060 0 0 211 0 Further information about SIP, is available in the "Cisco IOS SIP Configuration Guide" at the following link: http://www.cisco.com/univercd/cc/td/doc/product/software/ios123/123cgcr/vvfax_c/callc_c/sip_c/sipc1_c/index.htm H.323 Annex E Call Signaling Transport +------------------------------------- Cisco devices that are configured to support H.323 are affected. The affected protocol is H.323 Annex E Call Signaling Transport over UDP. ITU-T recommendation H.323 Annex E describes the signaling framework and wire-protocol for transporting H.225.0 call signaling messages over UDP. Recent versions of Cisco IOS Software do not open H.225.0 UDP port by default. Creating a "dial peer" via the command "dial-peer voice" with any option will open the H.225.0 UDP port. Several features within Cisco Call Manager Express, such as ePhones, once configured will also automatically start the H.323 process and the device will begin processing H.323 packets. It is recommended if the device is running any voice configurations to confirm the existence of the H.323 process with the "show ip socket" or "show udp" command. The following is one example of an affected configuration: dial-peer voice voip ... ! Note: Older versions of Cisco IOS Software were affected by a bug that caused Cisco IOS Software to listen on H.323 ports without being configured for H.323 operation. Please refer to Cisco bug ID: CSCsb25337 The following example shows a device that will process H.225.0 packets, on the default affected UDP port 2517: Router#show ip socket Proto Remote Port Local Port In Out Stat TTY OutputIF 17 0.0.0.0 0 192.168.0.2 2517 0 0 211 0 Further information about H.323, is available in the "Cisco IOS H.323 Configuration Guide" at the following link: http://www.cisco.com/en/US/docs/ios/12_3/vvf_c/cisco_ios_h323_configuration_guide/old_archives_h323/323confg.html Media Gateway Control Protocol (MGCP) +------------------------------------ Devices configured with the MGCP feature are vulnerable. MGCP is enabled globally with the command "mgcp". The default listening port for MGCP is UDP 2427. The following example shows a vulnerable configuration: mgcp The following example shows a device that will process MGCP packets on the affected UDP ports: Router#show ip socket Proto Remote Port Local Port In Out Stat TTY OutputIF 17 192.168.0.1 2427 10.66.91.138 2427 0 0 211 0 Further information about MGCP is available in the "Configuring the Cisco IOS MGCP Gateway reference" at the following link: http://www.cisco.com/en/US/products/sw/voicesw/ps556/products_tech_note09186a008017787b.shtml This vulnerability is documented in the following Cisco Bug ID: CSCsk64158 and has been assigned the Common Vulnerabilities and Exposures (CVE) identifiers CVE-2009-0631. Vulnerability Scoring Details ============================= Cisco has provided scores for the vulnerability in this advisory based on the Common Vulnerability Scoring System (CVSS). The CVSS scoring in this Security Advisory is done in accordance with CVSS version 2.0. CVSS is a standards-based scoring method that conveys vulnerability severity and helps determine urgency and priority of response. Cisco has provided a base and temporal score. Customers can then compute environmental scores to assist in determining the impact of the vulnerability in individual networks. Cisco has provided an FAQ to answer additional questions regarding CVSS at http://www.cisco.com/web/about/security/intelligence/cvss-qandas.html Cisco has also provided a CVSS calculator to help compute the environmental impact for individual networks at http://intellishield.cisco.com/security/alertmanager/cvss CSCsk64158: Cisco IOS Software Multiple Features Crafted UDP Packet Vulnerability CVSS Base Score - 7.8 Access Vector - Network Access Complexity - Low Authentication - None Confidentiality Impact - None Integrity Impact - None Availability Impact - Complete CVSS Temporal Score - 6.4 Exploitability - Functional Remediation Level - Official-Fix Report Confidence - Confirmed Impact ====== Successful exploitation of this vulnerability may cause the inbound interface to be blocked and will silently drop any received traffic. A reload of the device is required to restore normal functionality. Software Versions and Fixes =========================== When considering software upgrades, also consult http://www.cisco.com/go/psirt and any subsequent advisories to determine exposure and a complete upgrade solution. In all cases, customers should exercise caution to be certain the devices to be upgraded contain sufficient memory and that current hardware and software configurations will continue to be supported properly by the new release. If the information is not clear, contact the Cisco Technical Assistance Center (TAC) or your contracted maintenance provider for assistance. Each row of the Cisco IOS software table (below) names a Cisco IOS release train. If a given release train is vulnerable, then the earliest possible releases that contain the fix (along with the anticipated date of availability for each, if applicable) are listed in the "First Fixed Release" column of the table. The "Recommended Release" column indicates the releases which have fixes for all the published vulnerabilities at the time of this Advisory. A device running a release in the given train that is earlier than the release in a specific column (less than the First Fixed Release) is known to be vulnerable. Cisco recommends upgrading to a release equal to or later than the release in the "Recommended Releases" column of the table. +-------------------------------------------------------------------+ | Major | Availability of Repaired Releases | | Release | | |------------+------------------------------------------------------| | Affected | | Recommended | | 12.0-Based | First Fixed Release | Release | | Releases | | | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.0 | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.0DA | Vulnerable; first fixed in 12.2DA | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.0DB | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.0DC | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | 12.0S | 12.0(32)S12 | 12.0(32)S12 | |------------+-------------------------------------+----------------| | 12.0SC | Vulnerable; first fixed in 12.0S | 12.0(32)S12 | |------------+-------------------------------------+----------------| | 12.0SL | Vulnerable; first fixed in 12.0S | 12.0(32)S12 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.0SP | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | 12.0ST | Vulnerable; first fixed in 12.0S | 12.0(32)S12 | |------------+-------------------------------------+----------------| | 12.0SX | Vulnerable; first fixed in 12.0S | 12.0(32)S12 | |------------+-------------------------------------+----------------| | 12.0SY | 12.0(32)SY8 | 12.0(32)SY8 | |------------+-------------------------------------+----------------| | 12.0SZ | Vulnerable; first fixed in 12.0S | 12.0(32)S12 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.0T | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | 12.0W | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.0WC | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.0WT | Not Vulnerable | | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.0XA | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.0XB | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.0XC | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.0XD | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.0XE | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | 12.0XF | Not Vulnerable | | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.0XG | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.0XH | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | Releases prior to 12.0(4)XI2 are | 12.4(18e) | | | vulnerable, release 12.0(4)XI2 and | | | 12.0XI | later are not vulnerable; first | 12.4(23a); | | | fixed in 12.4 | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.0XJ | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.0XK | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.0XL | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.0XM | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.0XN | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.0XQ | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.0XR | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.0XS | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.0XT | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.0XV | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | Affected | | Recommended | | 12.1-Based | First Fixed Release | Release | | Releases | | | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.1 | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | 12.1AA | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.1AX | Vulnerable; first fixed in 12.2SE | 12.2(44)SE6 | |------------+-------------------------------------+----------------| | | | 12.1(22)EA13 | | 12.1AY | Vulnerable; first fixed in 12.1EA | | | | | 12.2(44)SE6 | |------------+-------------------------------------+----------------| | | | 12.1(22)EA13 | | 12.1AZ | Vulnerable; first fixed in 12.1EA | | | | | 12.2(44)SE6 | |------------+-------------------------------------+----------------| | 12.1CX | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.1DA | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.1DB | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.1DC | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.1E | Vulnerable; first fixed in 12.2SXF | 12.2(18)SXF16 | |------------+-------------------------------------+----------------| | 12.1EA | 12.1(22)EA13 | 12.1(22)EA13 | |------------+-------------------------------------+----------------| | 12.1EB | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | | | 12.2(33)SCB1 | | 12.1EC | Vulnerable; first fixed in 12.3BC | | | | | 12.3(23)BC6 | |------------+-------------------------------------+----------------| | 12.1EO | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.1EU | Vulnerable; first fixed in 12.2SG | 12.2(31)SGA9 | |------------+-------------------------------------+----------------| | 12.1EV | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.1EW | Vulnerable; migrate to 12.2SGA | 12.2(31)SGA9 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.1EX | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | 12.1EY | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.1EZ | Vulnerable; first fixed in 12.2SXF | 12.2(18)SXF16 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.1GA | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.1GB | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.1T | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.1XA | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.1XB | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.1XC | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.1XD | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.1XE | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.1XF | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.1XG | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.1XH | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.1XI | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.1XJ | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.1XL | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.1XM | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.1XP | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.1XQ | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.1XR | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.1XS | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.1XT | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.1XU | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.1XV | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.1XW | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.1XX | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.1XY | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.1XZ | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.1YA | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.1YB | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.1YC | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.1YD | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | Releases prior to 12.1(5)YE6 are | 12.4(18e) | | | vulnerable, release 12.1(5)YE6 and | | | 12.1YE | later are not vulnerable; first | 12.4(23a); | | | fixed in 12.4 | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.1YF | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.1YH | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | 12.1YI | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | | | 12.1(22)EA13 | | 12.1YJ | Vulnerable; first fixed in 12.1EA | | | | | 12.2(44)SE6 | |------------+-------------------------------------+----------------| | Affected | | Recommended | | 12.2-Based | First Fixed Release | Release | | Releases | | | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.2 | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.2B | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | | Vulnerable; migrate to 12.2SCB or | 12.2(33)SCB1 | | 12.2BC | 12.3BC | | | | | 12.3(23)BC6 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.2BW | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | 12.2BX | Vulnerable; migrate to 12.2SB | 12.2(33)SB4 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.2BY | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.2BZ | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | Vulnerable; migrate to 12.2SCB or | 12.2(33)SCB1 | | 12.2CX | 12.3BC | | | | | 12.3(23)BC6 | |------------+-------------------------------------+----------------| | | Vulnerable; migrate to 12.2SCB or | 12.2(33)SCB1 | | 12.2CY | 12.3BC | | | | | 12.3(23)BC6 | |------------+-------------------------------------+----------------| | 12.2CZ | Vulnerable; first fixed in 12.2SB | 12.2(33)SB4 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | 12.2(12)DA14; Available on | | | 12.2DA | 30-JUL-2009 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.2DD | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.2DX | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | 12.2EW | Vulnerable; first fixed in 12.2SG | 12.2(31)SGA9 | |------------+-------------------------------------+----------------| | 12.2EWA | Vulnerable; first fixed in 12.2SG | 12.2(31)SGA9 | |------------+-------------------------------------+----------------| | 12.2EX | Vulnerable; first fixed in 12.2SE | 12.2(44)SE6 | |------------+-------------------------------------+----------------| | 12.2EY | 12.2(44)EY | 12.2(44)SE6 | |------------+-------------------------------------+----------------| | 12.2EZ | Vulnerable; first fixed in 12.2SE | 12.2(44)SE6 | |------------+-------------------------------------+----------------| | 12.2FX | Vulnerable; first fixed in 12.2SE | 12.2(44)SE6 | |------------+-------------------------------------+----------------| | 12.2FY | Vulnerable; first fixed in 12.2SE | 12.2(44)SE6 | |------------+-------------------------------------+----------------| | 12.2FZ | Vulnerable; first fixed in 12.2SE | 12.2(44)SE6 | |------------+-------------------------------------+----------------| | | | 12.2(33)SRC4; | | 12.2IRA | Vulnerable; first fixed in 12.2SRC | Available on | | | | 18-MAY-2009 | |------------+-------------------------------------+----------------| | | | 12.2(33)SRC4; | | 12.2IRB | Vulnerable; first fixed in 12.2SRC | Available on | | | | 18-MAY-2009 | |------------+-------------------------------------+----------------| | | Vulnerable; migrate to any release | 12.2(18)IXH; | | 12.2IXA | in 12.2IXH | Available on | | | | 31-MAR-2009 | |------------+-------------------------------------+----------------| | | Vulnerable; migrate to any release | 12.2(18)IXH; | | 12.2IXB | in 12.2IXH | Available on | | | | 31-MAR-2009 | |------------+-------------------------------------+----------------| | | Vulnerable; migrate to any release | 12.2(18)IXH; | | 12.2IXC | in 12.2IXH | Available on | | | | 31-MAR-2009 | |------------+-------------------------------------+----------------| | | Vulnerable; migrate to any release | 12.2(18)IXH; | | 12.2IXD | in 12.2IXH | Available on | | | | 31-MAR-2009 | |------------+-------------------------------------+----------------| | | Vulnerable; migrate to any release | 12.2(18)IXH; | | 12.2IXE | in 12.2IXH | Available on | | | | 31-MAR-2009 | |------------+-------------------------------------+----------------| | | Vulnerable; migrate to any release | 12.2(18)IXH; | | 12.2IXF | in 12.2IXH | Available on | | | | 31-MAR-2009 | |------------+-------------------------------------+----------------| | | Vulnerable; migrate to any release | 12.2(18)IXH; | | 12.2IXG | in 12.2IXH | Available on | | | | 31-MAR-2009 | |------------+-------------------------------------+----------------| | 12.2JA | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.2JK | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.2MB | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | 12.2MC | 12.2(15)MC2m | 12.2(15)MC2m | |------------+-------------------------------------+----------------| | 12.2S | Vulnerable; first fixed in 12.2SB | 12.2(33)SB4 | |------------+-------------------------------------+----------------| | | 12.2(31)SB14 | | | | | | | 12.2SB | 12.2(33)SB3 | 12.2(33)SB4 | | | | | | | 12.2(28)SB13 | | |------------+-------------------------------------+----------------| | 12.2SBC | Vulnerable; first fixed in 12.2SB | 12.2(33)SB4 | |------------+-------------------------------------+----------------| | 12.2SCA | Vulnerable; first fixed in 12.2SCB | 12.2(33)SCB1 | |------------+-------------------------------------+----------------| | 12.2SCB | 12.2(33)SCB1 | 12.2(33)SCB1 | |------------+-------------------------------------+----------------| | | 12.2(46)SE2 | | | | | | | 12.2SE | 12.2(44)SE5 | 12.2(44)SE6 | | | | | | | 12.2(50)SE | | |------------+-------------------------------------+----------------| | 12.2SEA | Vulnerable; first fixed in 12.2SE | 12.2(44)SE6 | |------------+-------------------------------------+----------------| | 12.2SEB | Vulnerable; first fixed in 12.2SE | 12.2(44)SE6 | |------------+-------------------------------------+----------------| | 12.2SEC | Vulnerable; first fixed in 12.2SE | 12.2(44)SE6 | |------------+-------------------------------------+----------------| | 12.2SED | Vulnerable; first fixed in 12.2SE | 12.2(44)SE6 | |------------+-------------------------------------+----------------| | 12.2SEE | Vulnerable; first fixed in 12.2SE | 12.2(44)SE6 | |------------+-------------------------------------+----------------| | 12.2SEF | Vulnerable; first fixed in 12.2SE | 12.2(44)SE6 | |------------+-------------------------------------+----------------| | 12.2SEG | Vulnerable; first fixed in 12.2SE | 12.2(44)SE6 | |------------+-------------------------------------+----------------| | | | 12.2(52)SG; | | 12.2SG | 12.2(50)SG | Available on | | | | 15-MAY-2009 | |------------+-------------------------------------+----------------| | 12.2SGA | 12.2(31)SGA9 | 12.2(31)SGA9 | |------------+-------------------------------------+----------------| | 12.2SL | Not Vulnerable | | |------------+-------------------------------------+----------------| | 12.2SM | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.2SO | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.2SQ | 12.2(44)SQ1 | | |------------+-------------------------------------+----------------| | | | 12.2(33)SRC4; | | 12.2SRA | Vulnerable; first fixed in 12.2SRC | Available on | | | | 18-MAY-2009 | |------------+-------------------------------------+----------------| | | | 12.2(33)SRC4; | | | | Available on | | | | 18-MAY-2009 | | 12.2SRB | Vulnerable; first fixed in 12.2SRC | | | | | 12.2(33)SRB5a; | | | | Available on | | | | 3-April-2009 | |------------+-------------------------------------+----------------| | | | 12.2(33)SRC4; | | 12.2SRC | 12.2(33)SRC3 | Available on | | | | 18-MAY-2009 | |------------+-------------------------------------+----------------| | 12.2SRD | Not Vulnerable | | |------------+-------------------------------------+----------------| | 12.2STE | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.2SU | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | 12.2SV | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.2SVA | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.2SVC | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.2SVD | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.2SVE | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.2SW | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.2SX | Vulnerable; first fixed in 12.2SXF | 12.2(18)SXF16 | |------------+-------------------------------------+----------------| | 12.2SXA | Vulnerable; first fixed in 12.2SXF | 12.2(18)SXF16 | |------------+-------------------------------------+----------------| | 12.2SXB | Vulnerable; first fixed in 12.2SXF | 12.2(18)SXF16 | |------------+-------------------------------------+----------------| | 12.2SXD | Vulnerable; first fixed in 12.2SXF | 12.2(18)SXF16 | |------------+-------------------------------------+----------------| | 12.2SXE | Vulnerable; first fixed in 12.2SXF | 12.2(18)SXF16 | |------------+-------------------------------------+----------------| | 12.2SXF | 12.2(18)SXF16 | 12.2(18)SXF16 | |------------+-------------------------------------+----------------| | | 12.2(33)SXH5; Available on | 12.2(33)SXH5; | | 12.2SXH | 20-APR-2009 | Available on | | | | 20-APR-2009 | |------------+-------------------------------------+----------------| | 12.2SXI | Not Vulnerable | | |------------+-------------------------------------+----------------| | 12.2SY | Vulnerable; first fixed in 12.2SB | 12.2(33)SB4 | |------------+-------------------------------------+----------------| | 12.2SZ | Vulnerable; first fixed in 12.2SB | 12.2(33)SB4 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.2T | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | 12.2TPC | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.2XA | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.2XB | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.2XC | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.2XD | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.2XE | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | Vulnerable; migrate to 12.2SCB or | 12.2(33)SCB1 | | 12.2XF | 12.3BC | | | | | 12.3(23)BC6 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.2XG | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.2XH | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.2XI | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.2XJ | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.2XK | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.2XL | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.2XM | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.2(33)SB4 | | 12.2XN | Vulnerable; first fixed in 12.2SRC | | | | | 12.2(33)SRD1 | |------------+-------------------------------------+----------------| | 12.2XNA | Vulnerable; migrate to any release | 12.2(33)SRD1 | | | in 12.2SRD | | |------------+-------------------------------------+----------------| | 12.2XNB | 12.2(33)XNB1 | 12.2(33)XNB3 | |------------+-------------------------------------+----------------| | 12.2XNC | Not Vulnerable | | |------------+-------------------------------------+----------------| | 12.2XO | 12.2(46)XO | 12.2(46)XO | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.2XQ | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.2XR | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.2XS | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.2XT | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.2XU | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.2XV | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.2XW | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.2YA | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | 12.2YB | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.2YC | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.2YD | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.2YE | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.2YF | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.2YG | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.2YH | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.2YJ | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.2YK | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.2YL | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.2YM | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | 12.2YN | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.2YO | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.2YP | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | 12.2YQ | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.2YR | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.2YS | Not Vulnerable | | |------------+-------------------------------------+----------------| | 12.2YT | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.2YU | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.2YV | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.2YW | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.2YX | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.2YY | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.2YZ | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.2ZA | Vulnerable; first fixed in 12.2SXF | 12.2(18)SXF16 | |------------+-------------------------------------+----------------| | 12.2ZB | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.2ZC | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.2ZD | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.2ZE | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.2ZF | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.2ZG | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.2ZH | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | 12.2ZJ | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.2ZL | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.2ZP | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | | | 12.2(33)SRC4; | | 12.2ZU | Vulnerable; first fixed in 12.2SXH | Available on | | | | 18-MAY-2009 | |------------+-------------------------------------+----------------| | 12.2ZX | Vulnerable; first fixed in 12.2SB | 12.2(33)SB4 | |------------+-------------------------------------+----------------| | 12.2ZY | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.2ZYA | 12.2(18)ZYA1 | 12.2(18)ZYA1 | |------------+-------------------------------------+----------------| | Affected | | Recommended | | 12.3-Based | First Fixed Release | Release | | Releases | | | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.3 | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.3B | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | 12.3BC | 12.3(23)BC6 | 12.3(23)BC6 | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.3BW | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | 12.3EU | Not Vulnerable | | |------------+-------------------------------------+----------------| | 12.3JA | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.3JEA | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.3JEB | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.3JEC | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.3JK | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | 12.3JL | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.3JX | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.3T | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | 12.3TPC | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.3VA | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.3XA | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | 12.3XB | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.3XC | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.3XD | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.3XE | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | 12.3XF | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.3XG | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | 12.3XI | Vulnerable; first fixed in 12.2SB | 12.2(33)SB4 | |------------+-------------------------------------+----------------| | 12.3XJ | Vulnerable; first fixed in 12.3YX | 12.3(14)YX14 | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.3XK | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.3XL | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.3XQ | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(18e) | | | | | | 12.3XR | Vulnerable; first fixed in 12.4 | 12.4(23a); | | | | Available on | | | | 30-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.3XS | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.3XU | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | 12.3XW | Vulnerable; first fixed in 12.3YX | 12.3(14)YX14 | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.3XX | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.3XY | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.3XZ | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.3YA | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.3YD | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | 12.3YF | Vulnerable; first fixed in 12.3YX | 12.3(14)YX14 | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.3YG | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.3YH | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.3YI | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.3YJ | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.3YK | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | 12.3YM | 12.3(14)YM13 | 12.3(14)YM13 | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.3YQ | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.3YS | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.3YT | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | 12.3YU | Vulnerable; first fixed in 12.4XB | 12.4(22)T1 | |------------+-------------------------------------+----------------| | 12.3YX | 12.3(14)YX14 | 12.3(14)YX14 | |------------+-------------------------------------+----------------| | 12.3YZ | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.3ZA | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | Affected | | Recommended | | 12.4-Based | First Fixed Release | Release | | Releases | | | |------------+-------------------------------------+----------------| | | 12.4(23) | 12.4(18e) | | | | | | 12.4 | 12.4(18e) | 12.4(23a); | | | | Available on | | | 12.4(23a); Available on 30-APR-2009 | 30-APR-2009 | |------------+-------------------------------------+----------------| | 12.4JA | 12.4(16b)JA1 | | |------------+-------------------------------------+----------------| | 12.4JDA | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.4JK | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.4JL | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.4JMA | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.4JMB | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.4JX | Vulnerable; first fixed in 12.4JA | | |------------+-------------------------------------+----------------| | 12.4MD | 12.4(11)MD7 | 12.4(11)MD7 | |------------+-------------------------------------+----------------| | 12.4MR | 12.4(19)MR1 | 12.4(19)MR2 | |------------+-------------------------------------+----------------| | 12.4SW | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | | 12.4(15)T8 | | | | | 12.4(22)T1 | | | 12.4(20)T2 | | | 12.4T | | 12.4(15)T9; | | | 12.4(22)T | Available on | | | | 29-APR-2009 | | | 12.4(15)T9; Available on | | | | 29-APR-2009 | | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.4XA | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | 12.4(15)T8 | | | 12.4XB | | 12.4(15)T9; | | | 12.4(20)T2 | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.4XC | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | | 12.4(4)XD12; Available on | 12.4(4)XD12; | | 12.4XD | 27-MAR-2009 | Available on | | | | 27-MAR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.4XE | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.4XF | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | | 12.4(15)T8 | 12.4(22)T1 | | | | | | 12.4XG | 12.4(20)T2 | 12.4(15)T9; | | | | Available on | | | 12.4(22)T1 | 29-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.4XJ | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.4XK | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | 12.4XL | 12.4(15)XL4 | 12.4(15)XL4 | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.4XM | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | 12.4XN | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.4XP | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.4XQ | 12.4(15)XQ2 | 12.4(15)XQ2 | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.4XR | 12.4(15)XR4 | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.4XT | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | 12.4XV | Vulnerable; contact TAC | | |------------+-------------------------------------+----------------| | 12.4XW | 12.4(11)XW10 | 12.4(11)XW10 | |------------+-------------------------------------+----------------| | | | 12.4(22)T1 | | | | | | 12.4XY | Vulnerable; first fixed in 12.4T | 12.4(15)T9; | | | | Available on | | | | 29-APR-2009 | |------------+-------------------------------------+----------------| | 12.4XZ | 12.4(15)XZ2 | 12.4(15)XZ2 | |------------+-------------------------------------+----------------| | 12.4YA | 12.4(20)YA2 | 12.4(20)YA3 | |------------+-------------------------------------+----------------| | 12.4YB | Not Vulnerable | | |------------+-------------------------------------+----------------| | 12.4YD | Not Vulnerable | | +-------------------------------------------------------------------+ Workarounds =========== The following mitigations have been identified for this vulnerability; only packets destined for any configured IP address on the device can exploit this vulnerability. Transit traffic will not exploit this vulnerability. Disable Affected Listening Ports +------------------------------- If an affected feature is not required it can be explicitly disabled. Once disabled confirm the listening UDP port has been closed by entering the CLI command "show udp" or "show ip socket". Some features may require a reload of the device after disabling the feature in order to close the listening UDP port. For SIP it is possible to disable UDP listening if only TCP services are required. The following example shows how to disable SIP from listening on its associated UDP port. Warning: When applying this workaround to devices that are processing MGCP or H.323 calls, the device will not allow the stopping SIP processing while active calls are being processed. When possible, this workaround should be implemented during a maintenance window when active calls can be briefly stopped. Enter configuration commands, one per line. End with CNTL/Z. Router(config)#sip-ua Router(config-sip-ua)#no transport udp Router(config-sip-ua)#end For SIP it is possible to bind the process to a privately-addressed interface, with the command below. This will cause SIP to only listen on the internal interface, which may assist in limiting the exposure of this vulnerability: voice service voip sip bind control source-interface bind media source-interface Infrastructure Access Control Lists +---------------------------------- Warning: Because the features in this vulnerability utilize UDP as a transport, it is possible to spoof the sender's IP address, which may defeat ACLs that permit communication to these ports from trusted IP addresses. Unicast RPF should be considered to be used in conjunction to offer a better mitigation solution. Although it is often difficult to block traffic that transits a network, it is possible to identify traffic that should never be allowed to target infrastructure devices and block that traffic at the border of networks. Infrastructure Access Control Lists (iACLs) are a network security best practice and should be considered as a long-term addition to good network security as well as a workaround for this specific vulnerability. The iACL example below should be included as part of the deployed infrastructure access-list which will protect all devices with IP addresses in the infrastructure IP address range: !--- Only sections pertaining to features enabled on the device !--- need be configured. !--- !--- !--- Feature: IP SLAs UDP Responder !--- access-list 150 permit udp TRUSTED_SOURCE_ADDRESSES WILDCARD INFRASTRUCTURE_ADDRESSES WILDCARD eq 1967 !--- Deny IP SLAs UDP Responder traffic from all other sources !--- destined to infrastructure addresses. access-list 150 deny udp any INFRASTRUCTURE_ADDRESSES WILDCARD eq 1967 !--- !--- Feature: Session Initiation Protocol (SIP) !--- access-list 150 permit udp TRUSTED_SOURCE_ADDRESSES WILDCARD INFRASTRUCTURE_ADDRESSES WILDCARD eq 5060 !--- Deny SIP traffic from all other sources destined !--- to infrastructure addresses. access-list 150 deny udp any INFRASTRUCTURE_ADDRESSES WILDCARD eq 5060 !--- !--- Feature: H.323 Call Signaling !--- access-list 150 permit udp TRUSTED_SOURCE_ADDRESSES WILDCARD INFRASTRUCTURE_ADDRESSES WILDCARD eq 2517 !--- Deny H.323 Call Signaling traffic from all other sources !--- destined to infrastructure addresses. access-list 150 deny udp any INFRASTRUCTURE_ADDRESSES WILDCARD eq 2517 !--- !--- Feature: Media Gateway Control Protocol (MGCP) !--- access-list 150 permit udp TRUSTED_SOURCE_ADDRESSES WILDCARD INFRASTRUCTURE_ADDRESSES WILDCARD eq 2427 !--- Deny MGCP traffic from all other sources destined !--- to infrastructure addresses. access-list 150 deny udp any INFRASTRUCTURE_ADDRESSES WILDCARD eq 2427 !--- Permit/deny all other Layer 3 and Layer 4 traffic in !--- accordance with existing security policies and !--- configurations. Permit all other traffic to transit the !--- device. access-list 150 permit ip any any !--- Apply access-list to all interfaces (only one example !--- shown) interface serial 2/0 ip access-group 150 in The white paper entitled "Protecting Your Core: Infrastructure Protection Access Control Lists" presents guidelines and recommended deployment techniques for infrastructure protection access lists and is available at the following link http://www.cisco.com/en/US/tech/tk648/tk361/technologies_white_paper09186a00801a1a55.shtml Control Plane Policing +--------------------- Warning: Because the features in this vulnerability utilizes UDP as a transport, it is possible to spoof the sender's IP address, which may defeat ACLs that permit communication to these ports from trusted IP addresses. Unicast RPF should be considered to be used in conjunction to offer better mitigation solution. Control Plane Policing (CoPP) can be used to block untrusted UDP traffic to the device. Cisco IOS software releases 12.0S, 12.2SX, 12.2S, 12.3T, 12.4, and 12.4T support the CoPP feature. CoPP can be configured on a device to protect the management and control planes and minimize the risk and effectiveness of direct infrastructure attacks by explicitly permitting only authorized traffic that is sent to infrastructure devices in accordance with existing security policies and configurations. The CoPP example below should be included as part of the deployed CoPP which will protect all devices with IP addresses in the infrastructure IP address range. !--- !--- Only sections pertaining to features enabled on the device !--- need be configured. !--- !--- !--- Feature: IP SLAs UDP Responder !--- access-list 150 deny udp TRUSTED_SOURCE_ADDRESSES WILDCARD any eq 1967 !--- !--- Deny IP SLAs UDP Responder traffic from all other sources !--- destined to the device control plane. !--- access-list 150 permit udp any any eq 1967 !--- !--- Feature: Session Initiation Protocol (SIP) !--- access-list 150 deny udp TRUSTED_SOURCE_ADDRESSES WILDCARD any eq 5060 !--- !--- Deny SIP traffic from all other sources destined !--- to the device control plane. !--- access-list 150 permit udp any any eq 5060 !--- !--- Feature: H.323 Call Signaling !--- access-list 150 deny udp TRUSTED_SOURCE_ADDRESSES WILDCARD any eq 2517 !--- !--- Deny H.323 call signaling traffic from all other sources !--- destined to the device control plane. !--- access-list 150 permit udp any any eq 2517 !--- !--- Feature: Media Gateway Control Protocol (MGCP) !--- access-list 150 deny udp TRUSTED_SOURCE_ADDRESSES WILDCARD any eq 2427 !--- !--- Deny MGCP traffic from all other sources destined !--- to the device control plane. !--- access-list 150 permit udp any any eq 2427 !--- !--- Permit (Police or Drop)/Deny (Allow) all other Layer3 and !--- Layer4 traffic in accordance with existing security policies !--- and configurations for traffic that is authorized to be sent !--- to infrastructure devices !--- Create a Class-Map for traffic to be policed by !--- the CoPP feature !--- class-map match-all drop-udp-class match access-group 150 !--- !--- Create a Policy-Map that will be applied to the !--- Control-Plane of the device. !--- policy-map drop-udp-traffic class drop-udp-class drop !--- !--- Apply the Policy-Map to the !--- Control-Plane of the device !--- control-plane service-policy input drop-udp-traffic In the above CoPP example, the access control list entries (ACEs) that match the potential exploit packets with the "permit" action result in these packets being discarded by the policy-map "drop" function, while packets that match the "deny" action (not shown) are not affected by the policy-map drop function. Please note that the policy-map syntax is different in the 12.2S and 12.0S Cisco IOS trains: policy-map drop-udp-traffic class drop-udp-class police 32000 1500 1500 conform-action drop exceed-action drop Additional information on the configuration and use of the CoPP feature can be found in the documents, "Control Plane Policing Implementation Best Practices" and "Cisco IOS Software Releases 12.2S - Control Plane Policing" at the following links: http://www.cisco.com/web/about/security/intelligence/coppwp_gs.html and http://www.cisco.com/en/US/docs/ios/12_3t/12_3t4/feature/guide/gtrtlimt.html Additional mitigations that can be deployed on Cisco devices within the network are available in the "Cisco Applied Mitigation Bulletin" companion document for this advisory at the following link: http://www.cisco.com/warp/public/707/cisco-amb-20090325-sip-and-udp.shtml Exploit Detection +---------------- It is possible to detect blocked interface queues with an Cisco IOS Embedded Event Manager (EEM) policy. EEM provides event detection and reaction capabilities on a Cisco IOS device. EEM can alert administrators of blocked interfaces with email, a syslog message, or a Simple Network Management Protocol (SNMP) trap. A sample EEM policy that uses syslog to alert administrators of blocked interfaces is available at Cisco Beyond, an online community dedicated to EEM. A sample script is available at the following link: http://forums.cisco.com/eforum/servlet/EEM?page=eem&fn=script&scriptId=981 Further information about EEM is available from Cisco.com at the following link: http://www.cisco.com/en/US/products/ps6815/products_ios_protocol_group_home.htm Obtaining Fixed Software ======================== Cisco has released free software updates that address this vulnerability. Prior to deploying software, customers should consult their maintenance provider or check the software for feature set compatibility and known issues specific to their environment. Customers may only install and expect support for the feature sets they have purchased. By installing, downloading, accessing or otherwise using such software upgrades, customers agree to be bound by the terms of Cisco's software license terms found at http://www.cisco.com/en/US/docs/general/warranty/English/EU1KEN_.html, or as otherwise set forth at Cisco.com Downloads at http://www.cisco.com/public/sw-center/sw-usingswc.shtml Do not contact psirt at cisco.com or security-alert at cisco.com for software upgrades. Customers with Service Contracts +------------------------------- Customers with contracts should obtain upgraded software through their regular update channels. For most customers, this means that upgrades should be obtained through the Software Center on Cisco's worldwide website at http://www.cisco.com. Customers using Third Party Support Organizations +------------------------------------------------ Customers whose Cisco products are provided or maintained through prior or existing agreements with third-party support organizations, such as Cisco Partners, authorized resellers, or service providers should contact that support organization for guidance and assistance with the appropriate course of action in regards to this advisory. The effectiveness of any workaround or fix is dependent on specific customer situations, such as product mix, network topology, traffic behavior, and organizational mission. Due to the variety of affected products and releases, customers should consult with their service provider or support organization to ensure any applied workaround or fix is the most appropriate for use in the intended network before it is deployed. Customers without Service Contracts +---------------------------------- Customers who purchase direct from Cisco but do not hold a Cisco service contract, and customers who purchase through third-party vendors but are unsuccessful in obtaining fixed software through their point of sale should acquire upgrades by contacting the Cisco Technical Assistance Center (TAC). TAC contacts are as follows. * +1 800 553 2447 (toll free from within North America) * +1 408 526 7209 (toll call from anywhere in the world) * e-mail: tac at cisco.com Customers should have their product serial number available and be prepared to give the URL of this notice as evidence of entitlement to a free upgrade. Free upgrades for non-contract customers must be requested through the TAC. Refer to http://www.cisco.com/en/US/support/tsd_cisco_worldwide_contacts.html for additional TAC contact information, including localized telephone numbers, and instructions and e-mail addresses for use in various languages. Exploitation and Public Announcements ===================================== The Cisco PSIRT is not aware of any public announcements or malicious use of the vulnerability described in this advisory. This vulnerability was discovered by Cisco during routine internal testing. Status of this Notice: FINAL ============================ THIS DOCUMENT IS PROVIDED ON AN "AS IS" BASIS AND DOES NOT IMPLY ANY KIND OF GUARANTEE OR WARRANTY, INCLUDING THE WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR USE. YOUR USE OF THE INFORMATION ON THE DOCUMENT OR MATERIALS LINKED FROM THE DOCUMENT IS AT YOUR OWN RISK. CISCO RESERVES THE RIGHT TO CHANGE OR UPDATE THIS DOCUMENT AT ANY TIME. A stand-alone copy or Paraphrase of the text of this document that omits the distribution URL in the following section is an uncontrolled copy, and may lack important information or contain factual errors. Distribution ============ This advisory is posted on Cisco's worldwide website at : http://www.cisco.com/warp/public/707/cisco-sa-20090325-udp.shtml In addition to worldwide web posting, a text version of this notice is clear-signed with the Cisco PSIRT PGP key and is posted to the following e-mail and Usenet news recipients. * cust-security-announce at cisco.com * first-bulletins at lists.first.org * bugtraq at securityfocus.com * vulnwatch at vulnwatch.org * cisco at spot.colorado.edu * cisco-nsp at puck.nether.net * full-disclosure at lists.grok.org.uk * comp.dcom.sys.cisco at newsgate.cisco.com Future updates of this advisory, if any, will be placed on Cisco's worldwide website, but may or may not be actively announced on mailing lists or newsgroups. Users concerned about this problem are encouraged to check the above URL for any updates. Revision History ================ +---------------------------------------+ | Revision | | Initial | | 1.0 | 2009-March-25 | public | | | | release. | +---------------------------------------+ Cisco Security Procedures ========================= Complete information on reporting security vulnerabilities in Cisco products, obtaining assistance with security incidents, and registering to receive security information from Cisco, is available on Cisco's worldwide website at http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html This includes instructions for press inquiries regarding Cisco security notices. All Cisco security advisories are available at http://www.cisco.com/go/psirt -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAknKUdAACgkQ86n/Gc8U/uB5UACfTuBFTIs6/V/FKPdLnLYCvGXF CyIAn3XqDhmEqM24yznj0IHjMPpGQ7Y2 =mpQF -----END PGP SIGNATURE----- From virendra.rode at gmail.com Wed Mar 25 12:58:26 2009 From: virendra.rode at gmail.com (virendra rode) Date: Wed, 25 Mar 2009 10:58:26 -0700 Subject: Remote hands site or list? In-Reply-To: <49CA5A35.7050001@impulse.net> References: <49CA5A35.7050001@impulse.net> Message-ID: <49CA70C2.3040305@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Owen Roth wrote: > Hello nanog mailing list, > > I was curious how one would go about looking for certain types of remote > hands by geography (ie coaxial runs in Phoenix, AZ). Is there another > mailing list or a web site that recommends itself? > - ------------------------ http://nanog.cluepon.net/index.php/Hands regards, /virendra -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJynDCpbZvCIJx1bcRAqF3AJ9+BYHGqeYJAmVg+4+rApsW/5uPLQCffq8E ByrjxjtWQLrsI+hFnPhF6jc= =76EB -----END PGP SIGNATURE----- From ernst at easystreet.com Wed Mar 25 13:05:25 2009 From: ernst at easystreet.com (Rick Ernst) Date: Wed, 25 Mar 2009 11:05:25 -0700 (PDT) Subject: Gigabit speed test anybody? Message-ID: <55529.69.30.17.85.1238004325.squirrel@www.woofpaws.com> Resent from my subscribed address. Hopefully this isn't a dupe to anybody. --------------------------------------- I'm working on turning up our first GigE connection (400mbs CIR) and the various online speedtests I'm aware of choke after about 100Mbs or so. Does anybody know of testing sites that can handle higher bandwidth, or have an ftp host or similar to test against? I'm connected to Level3, backhauled to Seattle, WA. Thanks, Rick From william.allen.simpson at gmail.com Wed Mar 25 13:16:14 2009 From: william.allen.simpson at gmail.com (William Allen Simpson) Date: Wed, 25 Mar 2009 14:16:14 -0400 Subject: phishing attacks against ISPs (also with Google translations) In-Reply-To: <49CA590F.5080408@linuxbox.org> References: <49CA25C0.70601@linuxbox.org> <620fd17c0903250655u1e9d8170y4fd8eac7aafa54d4@mail.gmail.com> <49CA5578.2080008@gmail.com> <49CA590F.5080408@linuxbox.org> Message-ID: <49CA74EE.5060103@gmail.com> Gadi Evron wrote: > The guy mentioned the concept of sending warning emails to customers to > begin with. His opinion is that it is a mistake, and only causes > confusion. On top of that it raises support desk costs as people call in > for explanation, as well as to report new fraudulent emails they see > while in the past they mostly just ignored them. > The earliest warning email we sent out to customers was: # Date: Mon, 11 Aug 2003 15:34:43 -0500 # Subject: New Virus Warning #... # There is a new virus spreading around the internet. It has a subject like # "your account" and it has the following text in it: # # > I would like to inform you about important information regarding your # > email address. This email address will be expiring. # > Please read attachment for details. #... I don't remember an uptick in support calls after that message, but there were plenty of calls about the phish message itself, so we hoped that sending a warning to everybody would reduce the problems. We'd had a user taken over, and then the account was used for so much spam that the bounce messages totally filled the incoming mail (filter) server. > I appreciate your feedback, I had no idea ISP phishing goes all the way > back to 2003.. Ha! Goes back much farther than that! The earliest I have at my fingertips (saved email on this laptop only goes back to 1999): # DATE: 27 Dec 00 7:43:14 PM # SUBJECT: re: your account # That was a web phish at hxxp://vaginaonline.com/a.usertrack2781.75/5/ And they were obviously tracking exactly which users responded! You'd think our customers would notice that domain wasn't us. ;-) But even today, it's a security problem that users don't notice the URL they're clicking, or pay attention to security warnings less subtle than a big gray popup dialog box.... > although dictionary attacks may not be best defined that > way. Definition discussions are boring though. > I meant that they tried every word in the dictionary for user names, maybe every combination of letters and numbers. Anyway, I was wrong about the most recent one that I'd saved. Who could forget the especially virulent (976 Google hits): # Date: Tue, 16 Mar 2004 10:59:13 +0100 # Subject: Important notify about your e-mail account. Anyway, none of this helps you with researching non-English ISP phishing. But it shows that this isn't a /new/ problem around here. From dholmes at mwdh2o.com Wed Mar 25 13:58:50 2009 From: dholmes at mwdh2o.com (Holmes,David A) Date: Wed, 25 Mar 2009 11:58:50 -0700 Subject: Recommendation for wiring contractor in Scottsdale, AZ In-Reply-To: <49CA624A.5060008@west.net> References: <49CA624A.5060008@west.net> Message-ID: <485ED9BA02629E4BBBA53AC892EDA50E089E4641@usmsxt104.mwd.h2o> In cases where lengthy in-house DS3 demarc extensions must be run, we have found it expedient to have the local telco provider (Qwest in Scottsdale?) extend the demarc. That way the telco is responsible for end-to-end CSU-to-CSU wiring diagnosis and repair. -----Original Message----- From: Jay Hennigan [mailto:jay at west.net] Sent: Wednesday, March 25, 2009 9:57 AM To: nanog at nanog.org Subject: Recommendation for wiring contractor in Scottsdale, AZ We have a need for a DS-3 extension (734 duplex co-ax, 300 foot run, BNC termination) in Scottsdale, AZ. A recommendation for a clueful wiring contractor familiar with this type of work would be greatly appreciated! -- Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV From azher at hep.caltech.edu Wed Mar 25 14:10:29 2009 From: azher at hep.caltech.edu (Azher Mughal) Date: Wed, 25 Mar 2009 12:10:29 -0700 Subject: Gigabit speed test anybody? In-Reply-To: <55529.69.30.17.85.1238004325.squirrel@www.woofpaws.com> References: <55529.69.30.17.85.1238004325.squirrel@www.woofpaws.com> Message-ID: <49CA81A5.3040508@hep.caltech.edu> You can try: http://www.measurementlab.net/measurement-lab-tools#ndt -Azher Rick Ernst wrote: > Resent from my subscribed address. Hopefully this isn't a dupe to anybody. > --------------------------------------- > > > I'm working on turning up our first GigE connection (400mbs CIR) and the > various online speedtests I'm aware of choke after about 100Mbs or so. > > Does anybody know of testing sites that can handle higher bandwidth, or > have an ftp host or similar to test against? > > I'm connected to Level3, backhauled to Seattle, WA. > > Thanks, > Rick > > > From ernst at easystreet.com Wed Mar 25 14:17:13 2009 From: ernst at easystreet.com (Rick Ernst) Date: Wed, 25 Mar 2009 12:17:13 -0700 (PDT) Subject: Gigabit speed test anybody? In-Reply-To: <49CA81A5.3040508@hep.caltech.edu> References: <55529.69.30.17.85.1238004325.squirrel@www.woofpaws.com> <49CA81A5.3040508@hep.caltech.edu> Message-ID: <53921.69.30.17.85.1238008633.squirrel@www.woofpaws.com> Azher, Thanks for the link. I don't currently have a Linux box I can stick on the network, but I'm trying to get one built. I'm also working with somebody in Seattle for file transfer testing. Thanks, Rick On Wed, March 25, 2009 12:10, Azher Mughal wrote: > You can try: > > http://www.measurementlab.net/measurement-lab-tools#ndt > > -Azher > > Rick Ernst wrote: >> Resent from my subscribed address. Hopefully this isn't a dupe to >> anybody. >> --------------------------------------- >> >> >> I'm working on turning up our first GigE connection (400mbs CIR) and the >> various online speedtests I'm aware of choke after about 100Mbs or so. >> >> Does anybody know of testing sites that can handle higher bandwidth, or >> have an ftp host or similar to test against? >> >> I'm connected to Level3, backhauled to Seattle, WA. >> >> Thanks, >> Rick >> >> >> > From azher at hep.caltech.edu Wed Mar 25 14:32:03 2009 From: azher at hep.caltech.edu (Azher Mughal) Date: Wed, 25 Mar 2009 12:32:03 -0700 Subject: Gigabit speed test anybody? In-Reply-To: <53921.69.30.17.85.1238008633.squirrel@www.woofpaws.com> References: <55529.69.30.17.85.1238004325.squirrel@www.woofpaws.com> <49CA81A5.3040508@hep.caltech.edu> <53921.69.30.17.85.1238008633.squirrel@www.woofpaws.com> Message-ID: <49CA86B3.1090309@hep.caltech.edu> I think windows should be fine, i just tested it from Vista and FireFox. -Azher Rick Ernst wrote: > Azher, > > Thanks for the link. I don't currently have a Linux box I can stick on > the network, but I'm trying to get one built. > > I'm also working with somebody in Seattle for file transfer testing. > > Thanks, > Rick > > > On Wed, March 25, 2009 12:10, Azher Mughal wrote: >> You can try: >> >> http://www.measurementlab.net/measurement-lab-tools#ndt >> >> -Azher >> >> Rick Ernst wrote: >>> Resent from my subscribed address. Hopefully this isn't a dupe to >>> anybody. >>> --------------------------------------- >>> >>> >>> I'm working on turning up our first GigE connection (400mbs CIR) and the >>> various online speedtests I'm aware of choke after about 100Mbs or so. >>> >>> Does anybody know of testing sites that can handle higher bandwidth, or >>> have an ftp host or similar to test against? >>> >>> I'm connected to Level3, backhauled to Seattle, WA. >>> >>> Thanks, >>> Rick >>> >>> >>> > From BBlackford at nwresd.k12.or.us Wed Mar 25 14:35:06 2009 From: BBlackford at nwresd.k12.or.us (Bill Blackford) Date: Wed, 25 Mar 2009 12:35:06 -0700 Subject: Gigabit speed test anybody? In-Reply-To: <55529.69.30.17.85.1238004325.squirrel@www.woofpaws.com> References: <55529.69.30.17.85.1238004325.squirrel@www.woofpaws.com> Message-ID: <6069A203FD01884885C037F81DD75080CA0CA749@wsc-mail-01.intra.nwresd.k12.or.us> Rick. The speedtests are only as good as the hosts they're hosted on and the path by which you reach them. I use iperf on each end of a link that I'm turning up. I put Linux hosts at both endpoints, but I believe iperf comes in a windows flavor too. -b ________________________________________ From: Rick Ernst [ernst at easystreet.com] Sent: Wednesday, March 25, 2009 11:05 AM To: nanog at nanog.org Subject: Gigabit speed test anybody? Resent from my subscribed address. Hopefully this isn't a dupe to anybody. --------------------------------------- I'm working on turning up our first GigE connection (400mbs CIR) and the various online speedtests I'm aware of choke after about 100Mbs or so. Does anybody know of testing sites that can handle higher bandwidth, or have an ftp host or similar to test against? I'm connected to Level3, backhauled to Seattle, WA. Thanks, Rick From ernst at easystreet.com Wed Mar 25 14:42:53 2009 From: ernst at easystreet.com (Rick Ernst) Date: Wed, 25 Mar 2009 12:42:53 -0700 (PDT) Subject: Gigabit speed test anybody? In-Reply-To: <6069A203FD01884885C037F81DD75080CA0CA749@wsc-mail-01.intra.nwresd.k12 .or.us> References: <55529.69.30.17.85.1238004325.squirrel@www.woofpaws.com> <6069A203FD01884885C037F81DD75080CA0CA749@wsc-mail-01.intra.nwresd.k12.or.us> Message-ID: <35797.69.30.17.85.1238010173.squirrel@www.woofpaws.com> Yup. I use iperf for point-to-point testing, but this is an access connection which is why I'm looking more for some kind of test host on Level3 in Seattle rather than a "speed test" site per se. Rick On Wed, March 25, 2009 12:35, Bill Blackford wrote: > Rick. The speedtests are only as good as the hosts they're hosted on and > the path by which you reach them. > > I use iperf on each end of a link that I'm turning up. I put Linux hosts > at both endpoints, but I believe iperf comes in a windows flavor too. > > -b > ________________________________________ > From: Rick Ernst [ernst at easystreet.com] > Sent: Wednesday, March 25, 2009 11:05 AM > To: nanog at nanog.org > Subject: Gigabit speed test anybody? > > Resent from my subscribed address. Hopefully this isn't a dupe to anybody. > --------------------------------------- > > > I'm working on turning up our first GigE connection (400mbs CIR) and the > various online speedtests I'm aware of choke after about 100Mbs or so. > > Does anybody know of testing sites that can handle higher bandwidth, or > have an ftp host or similar to test against? > > I'm connected to Level3, backhauled to Seattle, WA. > > Thanks, > Rick > > > > From paul at blacknight.com Wed Mar 25 15:03:33 2009 From: paul at blacknight.com (Paul Kelly :: Blacknight) Date: Wed, 25 Mar 2009 20:03:33 +0000 Subject: Gigabit speed test anybody? In-Reply-To: <55529.69.30.17.85.1238004325.squirrel@www.woofpaws.com> References: <55529.69.30.17.85.1238004325.squirrel@www.woofpaws.com> Message-ID: Hi Rick, Try an anon ftp or http download from http://ftp.heanet.ie The cluster that serves for ftp.heanet.ie has multiple machines with at least single or bonded 10GE interfaces into HEAnet's backbone and then minimum of 10GE on two carriers to the general internet. Should give you a pretty good speed test. I can max out our GigE links using them for testing. Paul Paul Kelly Technical Director Blacknight Internet Solutions ltd Hosting, Colocation, Dedicated servers IP Transit Services Tel: +353 (0) 59 9183072 Lo-call: 1850 929 929 DDI: +353 (0) 59 9183091 e-mail: paul at blacknight.ie web: http://www.blacknight.ie Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park, Sleaty Road, Graiguecullen, Carlow, Ireland Company No.: 370845 > -----Original Message----- > From: Rick Ernst [mailto:ernst at easystreet.com] > Sent: Wednesday, March 25, 2009 6:05 PM > To: nanog at nanog.org > Subject: Gigabit speed test anybody? > > > Resent from my subscribed address. Hopefully this isn't a dupe to > anybody. > --------------------------------------- > > > I'm working on turning up our first GigE connection (400mbs CIR) and > the > various online speedtests I'm aware of choke after about 100Mbs or so. > > Does anybody know of testing sites that can handle higher bandwidth, or > have an ftp host or similar to test against? > > I'm connected to Level3, backhauled to Seattle, WA. > > Thanks, > Rick > > From stuart at tech.org Wed Mar 25 15:07:02 2009 From: stuart at tech.org (Stephen Stuart) Date: Wed, 25 Mar 2009 20:07:02 +0000 Subject: Gigabit speed test anybody? In-Reply-To: Your message of "Wed, 25 Mar 2009 12:17:13 MST." <53921.69.30.17.85.1238008633.squirrel@www.woofpaws.com> Message-ID: <200903252007.n2PK72Sc092590@nb.tech.org> > Azher, > > Thanks for the link. I don't currently have a Linux box I can stick on > the network, but I'm trying to get one built. All you need on the client side is a browser with Java support (and in your case, a gigabit NIC). Ahzer mentioned using Vista/Firefox in his reply, I've used both Mac/Firefox and FreeBSD/Firefox. Stephen From stuart at tech.org Wed Mar 25 15:08:56 2009 From: stuart at tech.org (Stephen Stuart) Date: Wed, 25 Mar 2009 20:08:56 +0000 Subject: Gigabit speed test anybody? In-Reply-To: Your message of "Wed, 25 Mar 2009 20:07:02 GMT." Message-ID: <200903252008.n2PK8ukc092681@nb.tech.org> > > Azher, > > > > Thanks for the link. I don't currently have a Linux box I can stick on > > the network, but I'm trying to get one built. > > All you need on the client side is a browser with Java support (and in > your case, a gigabit NIC). Ahzer mentioned using Vista/Firefox in his > reply, I've used both Mac/Firefox and FreeBSD/Firefox. My apologies for the typo there, Azher. Stephen From andreas at naund.org Wed Mar 25 16:51:18 2009 From: andreas at naund.org (Andreas Ott) Date: Wed, 25 Mar 2009 14:51:18 -0700 Subject: Gigabit speed test anybody? In-Reply-To: <55529.69.30.17.85.1238004325.squirrel@www.woofpaws.com>; from ernst@easystreet.com on Wed, Mar 25, 2009 at 11:05:25AM -0700 References: <55529.69.30.17.85.1238004325.squirrel@www.woofpaws.com> Message-ID: <20090325145118.L1205@naund.org> Hi, On Wed, Mar 25, 2009 at 11:05:25AM -0700, Rick Ernst wrote: > I'm working on turning up our first GigE connection (400mbs CIR) and the > various online speedtests I'm aware of choke after about 100Mbs or so. > > Does anybody know of testing sites that can handle higher bandwidth, or > have an ftp host or similar to test against? > > I'm connected to Level3, backhauled to Seattle, WA. You might want to calculate what maximum throughput you can get on one TCP session (c.f. windowsize and bandwidth delay product when taking into consideration the RTT between the two endpoints of your test), then start multiple of these sessions in parallel to fill up your pipe. I strongly urge you to use a test like netperf/iperf that runs completely from memory and does not require spinning disks like http/ftp servers usually do. -andreas -- Andreas Ott K6OTT andreas at naund.org From morrowc.lists at gmail.com Wed Mar 25 18:07:26 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 25 Mar 2009 19:07:26 -0400 Subject: Remote hands site or list? In-Reply-To: <49CA70C2.3040305@gmail.com> References: <49CA5A35.7050001@impulse.net> <49CA70C2.3040305@gmail.com> Message-ID: <75cb24520903251607j2c4dee20tb4944882b9f0cd14@mail.gmail.com> On Wed, Mar 25, 2009 at 1:58 PM, virendra rode wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Owen Roth wrote: >> Hello nanog mailing list, >> >> I was curious how one would go about looking for certain types of remote >> hands by geography (ie coaxial runs in Phoenix, AZ). Is there another >> mailing list or a web site that recommends itself? >> > - ------------------------ > http://nanog.cluepon.net/index.php/Hands > wkumari also had a list started I believe as well... sadly I can't find his link now :( Warren where did you hide it? From twright at internode.com.au Wed Mar 25 18:56:59 2009 From: twright at internode.com.au (Tom Wright) Date: Thu, 26 Mar 2009 10:26:59 +1030 Subject: REVERSE DNS Practices. In-Reply-To: <49C91B9D.20301@gmail.com> References: <20090321103230.24415.qmail@simone.iecc.com> <7c9a4be6ad650d86a4884a739cb2ada9@imap.yoafrica.com> <200903221030.12564.mtinka@globaltransit.net> <20090324150708.GA24053@net.tufts.edu> <49C91B9D.20301@gmail.com> Message-ID: <4793D242-06D6-44A1-B22A-C67E7A623EEE@internode.com.au> Don't be afraid to create zones for each location, DNS lends itself to this kind of hierarchy naturally. I find this is tidier than lengthy A records. I.e, hostname.location.domain This also makes your zones a little more manageable (although on all accounts, some simple automation will ensure happiness forever more). I guess I'm speaking more from an ISP point of view. On 25/03/2009, at 4:12 AM, William Allen Simpson wrote: > Matthew F. Ringel wrote: >> Derivability: Being able to synthesize the name with a few pieces of >> data makes naming and debugging easier. > I agree. Remember, this is mostly going to show up in log files, and > they need to be easily skimmed by even the newest staff. > > >> Longer is okay: Barring software limitations on name length, a longer >> name is not a problem if a person knows that they're going to get it >> right on the first try. We used CNAMEs if we wanted abbreviations. > Clarity and consistency are paramount! > > I'm of the mind that you (we) should always setup the reverse *first* > for each block. Only after that's propagated, then add the A records > and CNAMEs. > > When you change from dynamic or unused assignments to static or a > specific customer domain, update the reverse *first*, then the A or > CNAME. The reverse lists become your assurance that you haven't > accidentally added duplicate assignments. > > Another hint (from the days we had a lot of directed broadcast > attacks): > indicate never used addresses and broadcast addresses in the reverse > list (such as reserved0, reserved31, reserved32, reserved255), > although > you will *never* have them in the A records (I always add a reminder > comment line on the forward side). That makes them stand out in the > log. > > Don't forget to block (and log) your reserved addresses at your > boundary > routers! A script to check the ACL against the reverse DNS is good, > although many routers will handle this semi-automatically now. > > So, you'll have a fully defined and propagated reverse list, even > though > the forward side hosts don't exist (yet). Security folks sometimes > worry that makes scanning targeting easier, but arguably similar > effort > to ping those addresses will yield similar results. > > It's most important for security to document the vulnerabilities > (reverse addresses help with self-documentation). Sometimes, folks > deliberately hide their systems in a sparsely populated block of fully > defined reverse addresses. > > -- Kind Regards, Tom Wright Internode Network Operations P: +61 8 8228 2999 W: http://www.internode.on.net From warren at kumari.net Wed Mar 25 19:56:35 2009 From: warren at kumari.net (Warren Kumari) Date: Wed, 25 Mar 2009 20:56:35 -0400 Subject: Remote hands site or list? In-Reply-To: <75cb24520903251607j2c4dee20tb4944882b9f0cd14@mail.gmail.com> References: <49CA5A35.7050001@impulse.net> <49CA70C2.3040305@gmail.com> <75cb24520903251607j2c4dee20tb4944882b9f0cd14@mail.gmail.com> Message-ID: On Mar 25, 2009, at 7:07 PM, Christopher Morrow wrote: > On Wed, Mar 25, 2009 at 1:58 PM, virendra rode > wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Owen Roth wrote: >>> Hello nanog mailing list, >>> >>> I was curious how one would go about looking for certain types of >>> remote >>> hands by geography (ie coaxial runs in Phoenix, AZ). Is there >>> another >>> mailing list or a web site that recommends itself? >>> >> - ------------------------ >> http://nanog.cluepon.net/index.php/Hands >> > > wkumari also had a list started I believe as well... sadly I can't > find his link now :( Warren where did you hide it? http://www.ne-where.com/cgi-bin/mailman/listinfo/ne-where I created this list so that people in the community could provide remote hand for each other and just to try and recapture some of the community spirt, but, well, got sidetracked. This is the first public list that I am running, feel free to provide feedback... On an unrelated note -- I recently ended with a bunch of those expensive Juniper DS3 cables (BNC to SMZ -- CBL-SMZ-BNC-M-S) -- long story, summary is that someone didn't pay their storage fee and I snagged them before they got tossed. Does anyone have a need for them? They will be distributed in the following order: 1: People that I know (and that haven't called me stupid recently). 2: People in the Reston, VA area (who will pick them up so I don't have to ship them). 3: People who do "good things for the Internet" (<- as decided by me). 4: Everyone else. Please only ask for them if you actually want / need them -- if you are just going to dump them, I can do that myself. Free to a good home, limit one per person. W P.S: Yes, i had though of giving them away on juniper-nsp, but, well, didn't want to... -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2173 bytes Desc: not available URL: From bicknell at ufp.org Wed Mar 25 20:24:17 2009 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 25 Mar 2009 20:24:17 -0500 Subject: ARIN Emergency Policy Change Message-ID: <20090326012417.GA31572@ussenterprise.ufp.org> The ARIN Board has put forth an emergency policy change: https://www.arin.net/policy/proposals/2009_1.html As this is an emergency change the timeframe for comments is greatly compressed, the current comment period ends April 7th. If the operators have input on this action you need to get over to ARIN's PPML mailing list, information on that is here: https://www.arin.net/participate/mailing_lists/index.html -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From enger at enger.us Wed Mar 25 22:23:23 2009 From: enger at enger.us (Robert M. Enger) Date: Wed, 25 Mar 2009 23:23:23 -0400 Subject: Gigabit speed test anybody? In-Reply-To: <55529.69.30.17.85.1238004325.squirrel@www.woofpaws.com> References: <55529.69.30.17.85.1238004325.squirrel@www.woofpaws.com> Message-ID: <49CAF52B.3040704@enger.us> I turned-up a pair of 10GigE circuits a while back (with a different, unnamed carrier). They didn't perform too well. When I pushed them for assistance with testing, they revealed that they had multiple IPERF transponders scattered throughout their network. They were not open to the public, but could be made available for short periods of time (timer-based, requiring repeated re-authorization to use them for an extended period). It seems likely that Level3 has similar (or superior) testing facilities. A call to some account executives may be required to open the kimono. Separately, the Super computer centers used to have speed-test servers installed adjacent to their border routers. They were dedicated, tuned hosts specifically for speed testing. One/more of them might be willing to help you out. However, unless one of them happens to use Level3 for commercial transit, your performance will be gated by the excess intervening network(s) and under all circumstances, by the competing traffic on their access circuit. Finally, I echo the sentiments about avoiding disk I/O. If you do use FTP download for testing, you may wish to write the local output to the null device. Some ftp clients allow the null device to be specified as the local output file when downloading files. On XP command-line FTP, the device "Nul:" is accepted. On Un*x it is /dev/null. The command-line client on Server 2003 et al does not seem to accept Nul as the local destination file when downloading. (anyone know the correct magic?) Remember to download multiple times; assuming the source server has enough ram, it will cache the file in memory during the first download and successive downloads in rapid succession should be essentially memory-to-memory (if you're using a null device on the receiving end) Bob Rick Ernst wrote: > Resent from my subscribed address. Hopefully this isn't a dupe to anybody. > --------------------------------------- > > > I'm working on turning up our first GigE connection (400mbs CIR) and the > various online speedtests I'm aware of choke after about 100Mbs or so. > > Does anybody know of testing sites that can handle higher bandwidth, or > have an ftp host or similar to test against? > > I'm connected to Level3, backhauled to Seattle, WA. > > Thanks, > Rick > > > > From frnkblk at iname.com Wed Mar 25 23:09:03 2009 From: frnkblk at iname.com (Frank Bulk) Date: Wed, 25 Mar 2009 23:09:03 -0500 Subject: Gigabit speed test anybody? In-Reply-To: <49CAF52B.3040704@enger.us> References: <55529.69.30.17.85.1238004325.squirrel@www.woofpaws.com> <49CAF52B.3040704@enger.us> Message-ID: If you're turning up a 10 GigE circuit, as a customer I would be asking for that circuit to be tested with some modern tools such as the JDSU T-BERD. For the price you're probably paying, it's probably not unreasonable to have it as part of the turn-up fee. Frank -----Original Message----- From: Robert M. Enger [mailto:enger at enger.us] Sent: Wednesday, March 25, 2009 10:23 PM To: ernst at easystreet.com Cc: nanog at nanog.org Subject: Re: Gigabit speed test anybody? I turned-up a pair of 10GigE circuits a while back (with a different, unnamed carrier). They didn't perform too well. When I pushed them for assistance with testing, they revealed that they had multiple IPERF transponders scattered throughout their network. They were not open to the public, but could be made available for short periods of time (timer-based, requiring repeated re-authorization to use them for an extended period). It seems likely that Level3 has similar (or superior) testing facilities. A call to some account executives may be required to open the kimono. Separately, the Super computer centers used to have speed-test servers installed adjacent to their border routers. They were dedicated, tuned hosts specifically for speed testing. One/more of them might be willing to help you out. However, unless one of them happens to use Level3 for commercial transit, your performance will be gated by the excess intervening network(s) and under all circumstances, by the competing traffic on their access circuit. Finally, I echo the sentiments about avoiding disk I/O. If you do use FTP download for testing, you may wish to write the local output to the null device. Some ftp clients allow the null device to be specified as the local output file when downloading files. On XP command-line FTP, the device "Nul:" is accepted. On Un*x it is /dev/null. The command-line client on Server 2003 et al does not seem to accept Nul as the local destination file when downloading. (anyone know the correct magic?) Remember to download multiple times; assuming the source server has enough ram, it will cache the file in memory during the first download and successive downloads in rapid succession should be essentially memory-to-memory (if you're using a null device on the receiving end) Bob Rick Ernst wrote: > Resent from my subscribed address. Hopefully this isn't a dupe to anybody. > --------------------------------------- > > > I'm working on turning up our first GigE connection (400mbs CIR) and the > various online speedtests I'm aware of choke after about 100Mbs or so. > > Does anybody know of testing sites that can handle higher bandwidth, or > have an ftp host or similar to test against? > > I'm connected to Level3, backhauled to Seattle, WA. > > Thanks, > Rick > > > > From enger at enger.us Wed Mar 25 23:23:01 2009 From: enger at enger.us (Robert M. Enger) Date: Thu, 26 Mar 2009 00:23:01 -0400 Subject: Gigabit speed test anybody? In-Reply-To: References: <55529.69.30.17.85.1238004325.squirrel@www.woofpaws.com> <49CAF52B.3040704@enger.us> Message-ID: <49CB0325.7040402@enger.us> The attachment circuits physical media was single mode dark fiber mid-span meet. After some tinkering with colo center jumpers, the physical attachment circuits were rock solid. The issue was the internal IP network of the ISP (or lack of same). You get what you pay for. (At most. Quite often, you get less.) Frank Bulk wrote: > If you're turning up a 10 GigE circuit, as a customer I would be asking for > that circuit to be tested with some modern tools such as the JDSU T-BERD. > For the price you're probably paying, it's probably not unreasonable to have > it as part of the turn-up fee. > > Frank > > -----Original Message----- > From: Robert M. Enger [mailto:enger at enger.us] > Sent: Wednesday, March 25, 2009 10:23 PM > To: ernst at easystreet.com > Cc: nanog at nanog.org > Subject: Re: Gigabit speed test anybody? > > > I turned-up a pair of 10GigE circuits a while back (with a different, > unnamed carrier). > They didn't perform too well. When I pushed them for assistance with > testing, they revealed that they had multiple IPERF transponders > scattered throughout their network. > They were not open to the public, but could be made available for short > periods of time (timer-based, requiring repeated re-authorization to use > them for an extended period). > > It seems likely that Level3 has similar (or superior) testing > facilities. A call to some account executives may be required to open > the kimono. > > Separately, the Super computer centers used to have speed-test servers > installed adjacent to their border routers. They were dedicated, tuned > hosts specifically for speed testing. One/more of them might be willing > to help you out. However, unless one of them happens to use Level3 for > commercial transit, your performance will be gated by the excess > intervening network(s) and under all circumstances, by the competing > traffic on their access circuit. > > Finally, I echo the sentiments about avoiding disk I/O. > If you do use FTP download for testing, you may wish to write the local > output to the null device. Some ftp clients allow the null device to be > specified as the local output file when downloading files. On XP > command-line FTP, the device "Nul:" is accepted. On Un*x it is > /dev/null. The command-line client on Server 2003 et al does not seem > to accept Nul as the local destination file when downloading. (anyone > know the correct magic?) Remember to download multiple times; > assuming the source server has enough ram, it will cache the file in > memory during the first download and successive downloads in rapid > succession should be essentially memory-to-memory (if you're using a > null device on the receiving end) > > Bob > > > > > > > > Rick Ernst wrote: > >> Resent from my subscribed address. Hopefully this isn't a dupe to anybody. >> --------------------------------------- >> >> >> I'm working on turning up our first GigE connection (400mbs CIR) and the >> various online speedtests I'm aware of choke after about 100Mbs or so. >> >> Does anybody know of testing sites that can handle higher bandwidth, or >> have an ftp host or similar to test against? >> >> I'm connected to Level3, backhauled to Seattle, WA. >> >> Thanks, >> Rick >> >> >> >> >> > > > From rodrick.brown at gmail.com Wed Mar 25 23:39:25 2009 From: rodrick.brown at gmail.com (Rodrick Brown) Date: Thu, 26 Mar 2009 00:39:25 -0400 Subject: OnLive -- Very disruptive internet technology to change things as we know it? Message-ID: Not sure if anyone has followed the recent announcement of OnLive and their new gaming service which will basically allow them to stream video game gameplay output realtime to any commodity PC over a broadband network. Currnet ISP pricing models are not not how many backbone providers today can handle thousands of users simultaneously watch continuous streaming video at 5Mb/s ? If this thing takes off it seem tiered pricing for internet usage might not be as far off as one may think? OnLive is launching the world?s highest performance Games On Demand service, instantly delivering the latest high-end titles over home broadband Internet to the TV and entry-level PCs and Macs. More overview here: http://www.engadget.com/2009/03/24/onlive-killed-the-game-console-star/ http://www.rockpapershotgun.com/2009/03/24/onlive-the-end-of-seperate-games-platforms/ -- [ Rodrick R. Brown ] http://www.rodrickbrown.com http://www.linkedin.com/in/rodrickbrown From schampeo at hesketh.com Thu Mar 26 00:22:17 2009 From: schampeo at hesketh.com (Steven Champeon) Date: Thu, 26 Mar 2009 01:22:17 -0400 Subject: REVERSE DNS Practices. In-Reply-To: <4793D242-06D6-44A1-B22A-C67E7A623EEE@internode.com.au> References: <20090321103230.24415.qmail@simone.iecc.com> <7c9a4be6ad650d86a4884a739cb2ada9@imap.yoafrica.com> <200903221030.12564.mtinka@globaltransit.net> <20090324150708.GA24053@net.tufts.edu> <49C91B9D.20301@gmail.com> <4793D242-06D6-44A1-B22A-C67E7A623EEE@internode.com.au> Message-ID: <20090326052217.GD29761@hesketh.com> on Thu, Mar 26, 2009 at 10:26:59AM +1030, Tom Wright wrote: > Don't be afraid to create zones for each > location, DNS lends itself to this kind of > hierarchy naturally. > > I find this is tidier than lengthy A records. > > I.e, hostname.location.domain And yet makes it more difficult for anyone else to simply set aside ALL of your dynamics as offlimits using simple substrings (say, in sendmail's access.db or using postfix check_client_access). Don't be that guy. > W: http://www.internode.on.net Oh, yeah. You already are (quick! guess which of these are actually dynamic, and which static, who's residential, who's business, etc.): adsl.internode.on.net gaw.internode.on.net padsl.internode.on.net adsl.adelaide.on.net link.internode.on.net as0.adl2.internode.on.net lns1.adl2.internode.on.net lns2.adl2.internode.on.net lns3.adl2.internode.on.net lns4.adl2.internode.on.net lns11.adl2.internode.on.net lns5.adl2.internode.on.net lns1.adl4.internode.on.net lns2.adl4.internode.on.net lns3.adl4.internode.on.net lns10.adl6.internode.on.net lns1.bne1.internode.on.net lns2.bne1.internode.on.net lns1.bne4.internode.on.net lns2.bne4.internode.on.net lns1.cbr1.internode.on.net lns2.cbr1.internode.on.net lns1.hba1.internode.on.net lns1.mel4.internode.on.net lns2.mel4.internode.on.net lns3.mel4.internode.on.net lns4.mel4.internode.on.net lns1.mel6.internode.on.net lns2.mel6.internode.on.net lns4.mel6.internode.on.net lns1.per1.internode.on.net lns1.syd2.internode.on.net lns1.syd6.internode.on.net lns2.syd6.internode.on.net lns4.syd6.internode.on.net lns1.syd7.internode.on.net lns2.syd7.internode.on.net lns3.syd7.internode.on.net cor2.adl2.internode.on.net lns10.adl2.internode.on.net lns10.mel4.internode.on.net lns10.syd6.internode.on.net lns10.syd7.internode.on.net nsw.adsl.internode.on.net qld.adsl.internode.on.net qld.padsl.internode.on.net sa.adsl.internode.on.net tas.adsl.internode.on.net vic.adsl.internode.on.net wa.adsl.internode.on.net Oh, there's also 'static.internode.on.net', so the safe bet is to assume that ALL of the rest are dynamic. Correct bet? Who knows. -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2553 w: http://hesketh.com/ antispam news, solutions for sendmail, exim, postfix: http://enemieslist.com/ From jabley at hopcount.ca Thu Mar 26 03:41:28 2009 From: jabley at hopcount.ca (Joe Abley) Date: Thu, 26 Mar 2009 01:41:28 -0700 Subject: ARIN Emergency Policy Change In-Reply-To: <20090326012417.GA31572@ussenterprise.ufp.org> References: <20090326012417.GA31572@ussenterprise.ufp.org> Message-ID: On 25-Mar-2009, at 18:24, Leo Bicknell wrote: > The ARIN Board has put forth an emergency policy change: > > https://www.arin.net/policy/proposals/2009_1.html For those not following the discussion on ppml, and perhaps not especially familiar with the policu or the policy process, could you either describe or give a concise link to a description of the context for this change? Joe From marty at supine.com Thu Mar 26 04:44:57 2009 From: marty at supine.com (Martin Barry) Date: Thu, 26 Mar 2009 20:44:57 +1100 Subject: REVERSE DNS Practices. In-Reply-To: <20090326052217.GD29761@hesketh.com> References: <20090321103230.24415.qmail@simone.iecc.com> <7c9a4be6ad650d86a4884a739cb2ada9@imap.yoafrica.com> <200903221030.12564.mtinka@globaltransit.net> <20090324150708.GA24053@net.tufts.edu> <49C91B9D.20301@gmail.com> <4793D242-06D6-44A1-B22A-C67E7A623EEE@internode.com.au> <20090326052217.GD29761@hesketh.com> Message-ID: <20090326094457.GA14094@supine.com> $quoted_author = "Steven Champeon" ; > > adsl.internode.on.net > gaw.internode.on.net > padsl.internode.on.net > adsl.adelaide.on.net > link.internode.on.net > as0.adl2.internode.on.net > lns1.adl2.internode.on.net ...and so on and so on. You do realise that they were all infrastructure devices which would never send email? LNS isn't a big enough giveaway? > Oh, there's also 'static.internode.on.net', so the safe bet is to > assume that ALL of the rest are dynamic. Correct bet? Who knows. That's a safe assumption. So ignore static.internode.on.net, their MXes and block everything else *.on.net cheers marty -- The problem with America is stupidity. I'm not saying there should be a capital punishment for stupidity, but why don't we just take the safety labels off of everything and let the problem solve itself? http://www.bash.org/?4753 From jgreco at ns.sol.net Thu Mar 26 08:48:39 2009 From: jgreco at ns.sol.net (Joe Greco) Date: Thu, 26 Mar 2009 07:48:39 -0600 (CST) Subject: Netflix, Blockbuster, and streaming content ... what impact? Message-ID: <200903261348.n2QDmdFC080381@aurora.sol.net> I've been seeing a flurry of new streaming service offerings, proposed or actual, such as Netflix, where it appears that they may be shooting to eventually ditch the mailed-DVD approach and just do broadband delivery of content. Might be a ways off, but they're doing the streaming now. http://www.bloomberg.com/apps/news?pid=email_en&refer=&sid=a1zxwiC6ELnA So we're potentially talking 4Mbps streamed at a customer for 2 hours at a shot, 500KB/s, 3.6GB of data. I know I've mentioned this several times in the past as a "coming challenge," and various parties, including many of our Australian networking friends, have expressed skepticism (and implemented quotas, etc). Yet it seems ever more certain that we're going to be seeing an explosion of video over the Internet, and sooner or later our rural areas, and all of the Australians ( :-) ), won't want to feel like left-out, second-rate Internet users. I see the current situation as being a gateway of sorts. Clearly, there are fortunes to be made and fortunes to be lost on this sort of thing, and I suspect that if some company is successful at this sort of streaming, we'll suddenly see a lot more business plans that involve Internet video delivery. This would seem to present some challenges to networks today, and probably more in the future. This would seem to be a pivotal time of sorts, are our networks planning to meet this challenge by providing the capacity, or are we going to degrade or limit service, or ... ??? What are networks doing today about these issues? ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From bicknell at ufp.org Thu Mar 26 08:55:21 2009 From: bicknell at ufp.org (Leo Bicknell) Date: Thu, 26 Mar 2009 08:55:21 -0500 Subject: ARIN Emergency Policy Change In-Reply-To: References: <20090326012417.GA31572@ussenterprise.ufp.org> Message-ID: <20090326135521.GC60135@ussenterprise.ufp.org> In a message written on Thu, Mar 26, 2009 at 01:41:28AM -0700, Joe Abley wrote: > For those not following the discussion on ppml, and perhaps not > especially familiar with the policu or the policy process, could you > either describe or give a concise link to a description of the context > for this change? http://lists.arin.net/pipermail/arin-ppml/ Go to March, search for "2009-1". -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From a.harrowell at gmail.com Thu Mar 26 09:05:17 2009 From: a.harrowell at gmail.com (Alexander Harrowell) Date: Thu, 26 Mar 2009 14:05:17 +0000 Subject: Netflix, Blockbuster, and streaming content ... what impact? In-Reply-To: <200903261348.n2QDmdFC080381@aurora.sol.net> References: <200903261348.n2QDmdFC080381@aurora.sol.net> Message-ID: The UK has already had this experience in early 2008 when the BBC began making huge amounts of TV content available through its iPlayer project. The impact on the DSL ISP industry was..not pretty. Our company did quite a bit of analysis on the results: http://www.telco2.net/blog/2008/02/bbcs_iplayer_nukes_all_you_can.html http://www.telco2.net/blog/2008/04/bbc_its_paymasters_cutting_the.html http://www.telco2.net/blog/2008/06/no_video_really_has_killed_the.html http://www.telco2.net/blog/2008/07/online_video_scoreboard_youtub.html http://www.telco2.net/blog/2008/08/bbc_iplayer_bandwidth_wars.html Essentially, if you're dependent on bitstream or on monopoly/near monopoly backhaul, you're in for an interesting few years. Answers: encourage peering with content providers, push CDNs as far into the network as possible, look at using set-top boxes creatively (local caching, integrated delivery with satellite/broadcast/cable). On Thu, Mar 26, 2009 at 1:48 PM, Joe Greco wrote: > I've been seeing a flurry of new streaming service offerings, proposed or > actual, such as Netflix, where it appears that they may be shooting to > eventually ditch the mailed-DVD approach and just do broadband delivery of > content. Might be a ways off, but they're doing the streaming now. > > http://www.bloomberg.com/apps/news?pid=email_en&refer=&sid=a1zxwiC6ELnA > > So we're potentially talking 4Mbps streamed at a customer for 2 hours at > a shot, 500KB/s, 3.6GB of data. > > I know I've mentioned this several times in the past as a "coming > challenge," and various parties, including many of our Australian > networking friends, have expressed skepticism (and implemented > quotas, etc). Yet it seems ever more certain that we're going to be > seeing an explosion of video over the Internet, and sooner or later > our rural areas, and all of the Australians ( :-) ), won't want to > feel like left-out, second-rate Internet users. > > I see the current situation as being a gateway of sorts. Clearly, > there are fortunes to be made and fortunes to be lost on this sort > of thing, and I suspect that if some company is successful at this > sort of streaming, we'll suddenly see a lot more business plans > that involve Internet video delivery. > > This would seem to present some challenges to networks today, and > probably more in the future. This would seem to be a pivotal time of > sorts, are our networks planning to meet this challenge by providing > the capacity, or are we going to degrade or limit service, or ... ??? > What are networks doing today about these issues? > > ... JG > -- > Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net > "We call it the 'one bite at the apple' rule. Give me one chance [and] then > I > won't contact you again." - Direct Marketing Ass'n position on e-mail > spam(CNN) > With 24 million small businesses in the US alone, that's way too many > apples. > > From bjamlists at gmail.com Thu Mar 26 09:18:53 2009 From: bjamlists at gmail.com (Brandon James) Date: Thu, 26 Mar 2009 09:18:53 -0500 Subject: Netflix, Blockbuster, and streaming content ... what impact? In-Reply-To: References: <200903261348.n2QDmdFC080381@aurora.sol.net> Message-ID: <49CB8ECD.9060608@gmail.com> Alexander Harrowell wrote: > The UK has already had this experience in early 2008 when the BBC began > making huge amounts of TV content available through its iPlayer project. The > impact on the DSL ISP industry was..not pretty. Our company did quite a bit > of analysis on the results: > http://www.telco2.net/blog/2008/02/bbcs_iplayer_nukes_all_you_can.html > http://www.telco2.net/blog/2008/04/bbc_its_paymasters_cutting_the.html > http://www.telco2.net/blog/2008/06/no_video_really_has_killed_the.html > http://www.telco2.net/blog/2008/07/online_video_scoreboard_youtub.html > http://www.telco2.net/blog/2008/08/bbc_iplayer_bandwidth_wars.html > > Essentially, if you're dependent on bitstream or on monopoly/near monopoly > backhaul, you're in for an interesting few years. Answers: encourage peering > with content providers, push CDNs as far into the network as possible, look > at using set-top boxes creatively (local caching, integrated delivery with > satellite/broadcast/cable). > > > On Thu, Mar 26, 2009 at 1:48 PM, Joe Greco wrote: > > >> I've been seeing a flurry of new streaming service offerings, proposed or >> actual, such as Netflix, where it appears that they may be shooting to >> eventually ditch the mailed-DVD approach and just do broadband delivery of >> content. Might be a ways off, but they're doing the streaming now. >> >> http://www.bloomberg.com/apps/news?pid=email_en&refer=&sid=a1zxwiC6ELnA >> >> So we're potentially talking 4Mbps streamed at a customer for 2 hours at >> a shot, 500KB/s, 3.6GB of data. >> >> I know I've mentioned this several times in the past as a "coming >> challenge," and various parties, including many of our Australian >> networking friends, have expressed skepticism (and implemented >> quotas, etc). Yet it seems ever more certain that we're going to be >> seeing an explosion of video over the Internet, and sooner or later >> our rural areas, and all of the Australians ( :-) ), won't want to >> feel like left-out, second-rate Internet users. >> >> I see the current situation as being a gateway of sorts. Clearly, >> there are fortunes to be made and fortunes to be lost on this sort >> of thing, and I suspect that if some company is successful at this >> sort of streaming, we'll suddenly see a lot more business plans >> that involve Internet video delivery. >> >> This would seem to present some challenges to networks today, and >> probably more in the future. This would seem to be a pivotal time of >> sorts, are our networks planning to meet this challenge by providing >> the capacity, or are we going to degrade or limit service, or ... ??? >> What are networks doing today about these issues? >> >> ... JG >> -- >> Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net >> "We call it the 'one bite at the apple' rule. Give me one chance [and] then >> I >> won't contact you again." - Direct Marketing Ass'n position on e-mail >> spam(CNN) >> With 24 million small businesses in the US alone, that's way too many >> apples. >> >> >> > > I wonder how products like this will figure into the mix. http://videogames.yahoo.com/feature/new-tech-could-make-consoles-obsolete/1299562 From mmoriniaux at prosodie.com Thu Mar 26 09:25:43 2009 From: mmoriniaux at prosodie.com (Moriniaux Michel) Date: Thu, 26 Mar 2009 15:25:43 +0100 Subject: Netflix, Blockbuster, and streaming content ... what impact? References: <200903261348.n2QDmdFC080381@aurora.sol.net> Message-ID: Hello, The way this is implemented on this side of the pond is: the responsibility for bandwidth resides on the broadband operator side. The content providers tend to peer with the broadband networks so that there are no bottlenecks on a third party (transit) network. Of course you need very active and competitive broadband markets for this model to work. Here we've been blessed with such a market and already have plethora of third party VOD offerings. Seeing the state of IP rights across the world the streams are going to be very country specific and will not be available through international transits (eg.: all the actual video offerings in the US that we do not have access to for tv series etc..) Best regards, Michel Moriniaux -----Message d'origine----- De?: Joe Greco [mailto:jgreco at ns.sol.net] Envoy??: jeudi 26 mars 2009 14:49 ??: nanog at nanog.org Objet?: Netflix, Blockbuster, and streaming content ... what impact? I've been seeing a flurry of new streaming service offerings, proposed or actual, such as Netflix, where it appears that they may be shooting to eventually ditch the mailed-DVD approach and just do broadband delivery of content. Might be a ways off, but they're doing the streaming now. http://www.bloomberg.com/apps/news?pid=email_en&refer=&sid=a1zxwiC6ELnA So we're potentially talking 4Mbps streamed at a customer for 2 hours at a shot, 500KB/s, 3.6GB of data. I know I've mentioned this several times in the past as a "coming challenge," and various parties, including many of our Australian networking friends, have expressed skepticism (and implemented quotas, etc). Yet it seems ever more certain that we're going to be seeing an explosion of video over the Internet, and sooner or later our rural areas, and all of the Australians ( :-) ), won't want to feel like left-out, second-rate Internet users. I see the current situation as being a gateway of sorts. Clearly, there are fortunes to be made and fortunes to be lost on this sort of thing, and I suspect that if some company is successful at this sort of streaming, we'll suddenly see a lot more business plans that involve Internet video delivery. This would seem to present some challenges to networks today, and probably more in the future. This would seem to be a pivotal time of sorts, are our networks planning to meet this challenge by providing the capacity, or are we going to degrade or limit service, or ... ??? What are networks doing today about these issues? ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From a.harrowell at gmail.com Thu Mar 26 09:30:57 2009 From: a.harrowell at gmail.com (Alexander Harrowell) Date: Thu, 26 Mar 2009 14:30:57 +0000 Subject: Netflix, Blockbuster, and streaming content ... what impact? In-Reply-To: References: <200903261348.n2QDmdFC080381@aurora.sol.net> Message-ID: Regarding OnLive, the short answer would appear to be that it's like streaming video, but more latency-critical. From ernst at easystreet.com Thu Mar 26 10:57:20 2009 From: ernst at easystreet.com (Rick Ernst) Date: Thu, 26 Mar 2009 08:57:20 -0700 (PDT) Subject: Gigabit speed test anybody? In-Reply-To: <55529.69.30.17.85.1238004325.squirrel@www.woofpaws.com> References: <55529.69.30.17.85.1238004325.squirrel@www.woofpaws.com> Message-ID: <40185.69.30.17.85.1238083040.squirrel@www.woofpaws.com> Thanks to multiple private/public responses. I was able to get an iperf test and also a close mirror for a DVD iso. Time to put live traffic on it and see what happens. On Wed, March 25, 2009 11:05, Rick Ernst wrote: > > Resent from my subscribed address. Hopefully this isn't a dupe to anybody. > --------------------------------------- > > > I'm working on turning up our first GigE connection (400mbs CIR) and the > various online speedtests I'm aware of choke after about 100Mbs or so. > > Does anybody know of testing sites that can handle higher bandwidth, or > have an ftp host or similar to test against? > > I'm connected to Level3, backhauled to Seattle, WA. > > Thanks, > Rick > > > > From schampeo at hesketh.com Thu Mar 26 11:56:58 2009 From: schampeo at hesketh.com (Steven Champeon) Date: Thu, 26 Mar 2009 12:56:58 -0400 Subject: REVERSE DNS Practices. In-Reply-To: <20090326094457.GA14094@supine.com> References: <20090321103230.24415.qmail@simone.iecc.com> <7c9a4be6ad650d86a4884a739cb2ada9@imap.yoafrica.com> <200903221030.12564.mtinka@globaltransit.net> <20090324150708.GA24053@net.tufts.edu> <49C91B9D.20301@gmail.com> <4793D242-06D6-44A1-B22A-C67E7A623EEE@internode.com.au> <20090326052217.GD29761@hesketh.com> <20090326094457.GA14094@supine.com> Message-ID: <20090326165658.GA23335@hesketh.com> on Thu, Mar 26, 2009 at 08:44:57PM +1100, Martin Barry wrote: > $quoted_author = "Steven Champeon" ; > > > > adsl.internode.on.net > > gaw.internode.on.net > > padsl.internode.on.net > > adsl.adelaide.on.net > > link.internode.on.net > > as0.adl2.internode.on.net > > lns1.adl2.internode.on.net > > ...and so on and so on. > > You do realise that they were all infrastructure devices which would > never send email? LNS isn't a big enough giveaway? You do realize that we've seen mail from all of these, which is why they're even on our radar, right? PaDSL is a VPN service. ADSL is a pretty straightforward label. 'link'? Who knows? If you don't take the time to think about your labeling and tokens, don't be surprised if other people not privy to your internal naming scheme start guessing. Especially if they're spewing spam and viruses like a firehose. > > Oh, there's also 'static.internode.on.net', so the safe bet is to > > assume that ALL of the rest are dynamic. Correct bet? Who knows. > > That's a safe assumption. Unfortunately, it's not. Even more unfortunately, we see more junk from their generic statics than we do from their obvious dynamics. -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2553 w: http://hesketh.com/ antispam news, solutions for sendmail, exim, postfix: http://enemieslist.com/ From herrin-nanog at dirtside.com Thu Mar 26 12:12:05 2009 From: herrin-nanog at dirtside.com (William Herrin) Date: Thu, 26 Mar 2009 13:12:05 -0400 Subject: ARIN Emergency Policy Change In-Reply-To: References: <20090326012417.GA31572@ussenterprise.ufp.org> Message-ID: <3c3e3fca0903261012qc87e183s57887738f14a59b2@mail.gmail.com> On Thu, Mar 26, 2009 at 4:41 AM, Joe Abley wrote: > On 25-Mar-2009, at 18:24, Leo Bicknell wrote: > >> The ARIN Board has put forth an emergency policy change: >> https://www.arin.net/policy/proposals/2009_1.html > > For those not following the discussion on ppml, and perhaps not especially > familiar with the policu or the policy process, could you either describe or > give a concise link to a description of the context for this change? Joe, The short, short version: ARIN's board may have gone rogue. The slightly longer version: There is some concern among the regular denizens of the ARIN public policy process that some majority the ARIN board of trustees has gone rogue as evidenced by the board's activity surrounding policy proposal 2009-01. Specifically, the board may be trying to use an obscure emergency provision to insert IP address sale and transfer policy language that slickly contravenes the expressed community consensus. As ARIN's regular denizens are not exactly unbiased, they respectfully request that ARIN's general membership (the network operators) take a closer look at the matter while they still can. Because the board has invoked "emergency" rules, the membership has only two weeks to examine the matter. After a week from Tuesday the board's IP address sale rules will be fait accompli. For the long version, please refer to the ARIN public policy mailing list, archives of which you can find at http://lists.arin.net/pipermail/arin-ppml/ Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From adrian at creative.net.au Thu Mar 26 12:14:27 2009 From: adrian at creative.net.au (Adrian Chadd) Date: Fri, 27 Mar 2009 02:14:27 +0900 Subject: REVERSE DNS Practices. In-Reply-To: <20090326165658.GA23335@hesketh.com> References: <20090321103230.24415.qmail@simone.iecc.com> <7c9a4be6ad650d86a4884a739cb2ada9@imap.yoafrica.com> <200903221030.12564.mtinka@globaltransit.net> <20090324150708.GA24053@net.tufts.edu> <49C91B9D.20301@gmail.com> <4793D242-06D6-44A1-B22A-C67E7A623EEE@internode.com.au> <20090326052217.GD29761@hesketh.com> <20090326094457.GA14094@supine.com> <20090326165658.GA23335@hesketh.com> Message-ID: <20090326171427.GB27422@skywalker.creative.net.au> On Thu, Mar 26, 2009, Steven Champeon wrote: [snip interode related hostnames such as this] > > > adsl.adelaide.on.net > > That's a safe assumption. > > Unfortunately, it's not. Even more unfortunately, we see more junk > from their generic statics than we do from their obvious dynamics. Have you tried just contacting internode in Australia about this? Adrian From randy at psg.com Thu Mar 26 12:18:48 2009 From: randy at psg.com (Randy Bush) Date: Thu, 26 Mar 2009 10:18:48 -0700 Subject: ARIN Emergency Policy Change In-Reply-To: <3c3e3fca0903261012qc87e183s57887738f14a59b2@mail.gmail.com> References: <20090326012417.GA31572@ussenterprise.ufp.org> <3c3e3fca0903261012qc87e183s57887738f14a59b2@mail.gmail.com> Message-ID: can you folk please please keep the arin ppml sickness contained within the arin lists? thanks. randy From schampeo at hesketh.com Thu Mar 26 12:28:29 2009 From: schampeo at hesketh.com (Steven Champeon) Date: Thu, 26 Mar 2009 13:28:29 -0400 Subject: REVERSE DNS Practices. In-Reply-To: <20090326171427.GB27422@skywalker.creative.net.au> References: <20090321103230.24415.qmail@simone.iecc.com> <7c9a4be6ad650d86a4884a739cb2ada9@imap.yoafrica.com> <200903221030.12564.mtinka@globaltransit.net> <20090324150708.GA24053@net.tufts.edu> <49C91B9D.20301@gmail.com> <4793D242-06D6-44A1-B22A-C67E7A623EEE@internode.com.au> <20090326052217.GD29761@hesketh.com> <20090326094457.GA14094@supine.com> <20090326165658.GA23335@hesketh.com> <20090326171427.GB27422@skywalker.creative.net.au> Message-ID: <20090326172829.GA27547@hesketh.com> on Fri, Mar 27, 2009 at 02:14:27AM +0900, Adrian Chadd wrote: > On Thu, Mar 26, 2009, Steven Champeon wrote: > > [snip interode related hostnames such as this] > > > > > adsl.adelaide.on.net > > > > That's a safe assumption. > > > > Unfortunately, it's not. Even more unfortunately, we see more junk > > from their generic statics than we do from their obvious dynamics. > > Have you tried just contacting internode in Australia about this? We maintain patterns for some 21K domains. No, we don't contact every ISP we see abusive traffic from, as it would take far longer than simply blocking based on evidence. We've been down that road before, and frankly it's a stunning waste of time. In the six years we've been doing this, we've had maybe two ISPs actually take the time to rename based on a recognition that doing so would be a boon to the antispam community and a good PR move. One of them took about 18 months to do so, and is still not finished across their entire network. The other has since reverted to stupid naming, presumably because the clue left the building. We've seen some adoption of sane naming practices, probably as a response to deliverability problems, but it's far from widespread. -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2553 w: http://hesketh.com/ antispam news, solutions for sendmail, exim, postfix: http://enemieslist.com/ From ravi at cow.org Thu Mar 26 12:58:32 2009 From: ravi at cow.org (Ravi Pina) Date: Thu, 26 Mar 2009 13:58:32 -0400 Subject: OnLive -- Very disruptive internet technology to change things as we know it? In-Reply-To: References: Message-ID: <20090326175831.GT73294@neu.cow.org> On Thu, Mar 26, 2009 at 12:39:25AM -0400, Rodrick Brown wrote: > Not sure if anyone has followed the recent announcement of OnLive and > their new gaming service which will basically allow them to stream > video game gameplay output realtime to any commodity PC over a > broadband network. > > Currnet ISP pricing models are not not how many backbone providers > today can handle thousands of users simultaneously watch continuous > streaming video at 5Mb/s ? > If this thing takes off it seem tiered pricing for internet usage > might not be as far off as one may think? > > OnLive is launching the world?s highest performance Games On Demand > service, instantly delivering the latest high-end titles over home > broadband Internet to the TV and entry-level PCs and Macs. > > More overview here: > http://www.engadget.com/2009/03/24/onlive-killed-the-game-console-star/ > http://www.rockpapershotgun.com/2009/03/24/onlive-the-end-of-seperate-games-platforms/ > > -- > [ Rodrick R. Brown ] > http://www.rodrickbrown.com http://www.linkedin.com/in/rodrickbrown This is very similar to Roiku/TiVo/Apple TV et al just that they say they can do HD with ~5Mb/s circuit. Has tiered pricing become a hotter topic with those products? I'm not taking any position -- just asking out loud. -r From stephen at sprunk.org Thu Mar 26 13:04:47 2009 From: stephen at sprunk.org (Stephen Sprunk) Date: Thu, 26 Mar 2009 13:04:47 -0500 Subject: ARIN Emergency Policy Change In-Reply-To: References: <20090326012417.GA31572@ussenterprise.ufp.org> Message-ID: <49CBC3BF.3000406@sprunk.org> Joe Abley wrote: > On 25-Mar-2009, at 18:24, Leo Bicknell wrote: >> The ARIN Board has put forth an emergency policy change: >> >> https://www.arin.net/policy/proposals/2009_1.html > > For those not following the discussion on ppml, and perhaps not > especially familiar with the policu or the policy process, could you > either describe or give a concise link to a description of the context > for this change? Textually, the change is fairly simple. Proposal 2008-6 [1] was adopted by the BoT after a finding of consensus by the ARIN AC, and the relevant part reads: -------------------- Policy statement: Emergency Transfer Policy for IPv4 Addresses For a period of 3 years from policy implementation, authorized resource holders served by ARIN may designate a recipient for number resources they release to ARIN. Number resources may only be received under RSA in the exact amount which can be justified under ARIN resource-allocation policies. Timetable for implementation: This policy, once ratified by the ARIN Board of Trustees, would be implemented when either the free-pool of IANA addresses is exhausted or IPv4 address resources in the ARIN Region reach a threshold of scarcity recognized by the ARIN Board of Trustees as requiring this policy implementation. -------------------- The BoT then proposed emergency policy 2009-1 [2], which has some minor editorial changes (e.g. section renumbering) and the following relevant text: -------------------- *8.3 Transfers to Specified Recipients* Number resources may be released, in whole or in part, to ARIN for transfer to another specified organizational recipient, by any authorized resource holder within the ARIN region. Such transferred number resources may only be received by organizations that are within the ARIN region and can demonstrate the need for such resources in the exact amount which they can justify under current ARIN policies. -------------------- Most notably, the revised text does not contain the 3-year "sunset" clause that was a fundamental part of 2008-6. It is also unclear (to me) whether the "timetable for implementation" specified in 2008-6 also applies to 2009-1. As to the remaining changes, you can decide for yourself whether the rewrite has a material effect on the type of IPv4 address market this policy would create. The BoT did not mention any relevant issues with the text of 2008-6 to the PPML, to the AC, or at the Public Policy Meetings it was discussed at prior to taking this action, nor has it (officially[3]) published any explanation for its changes, why it could not send 2008-6 back to the AC for modification, or why it believes there is an "emergency" that precludes this proposal following the normal PDP. The use of the Emergency PDP requires a last call that ends 7 Apr 2009, less than a month before the next Public Policy Meeting (26-29 Apr 2009). My opinion: This policy should be rejected, regardless of its merits, because of how the BoT has (so far) handled it in violation of the spirit (though, admittedly, not the letter) of the process, how it disregards community consensus and attempts to sidestep community review, the complete and utter lack of transparency that we expect from ARIN, and the glaringly obvious lack of any "emergency" with a policy that isn't expected to be implemented for _at least_ another year or two. If there is indeed a flaw in 2008-6 that needs correcting, let it be discussed at the meeting next month and the AC and BoT can then take the appropriate non-emergency action. S [1] https://www.arin.net/policy/proposals/2008_6.html [2] https://www.arin.net/policy/proposals/2009_1.html [3] The BoT Chair has posted several messages on PPML about this, but they do not appear to be official statements by the entire BoT. I haven't noticed any other BoT members commenting. -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3241 bytes Desc: S/MIME Cryptographic Signature URL: From davet1 at gmail.com Thu Mar 26 16:56:14 2009 From: davet1 at gmail.com (Dave Temkin) Date: Thu, 26 Mar 2009 14:56:14 -0700 Subject: OnLive -- Very disruptive internet technology to change things as we know it? In-Reply-To: <20090326175831.GT73294@neu.cow.org> References: <20090326175831.GT73294@neu.cow.org> Message-ID: <49CBF9FE.2050501@gmail.com> Ravi Pina wrote: > On Thu, Mar 26, 2009 at 12:39:25AM -0400, Rodrick Brown wrote: > >> Not sure if anyone has followed the recent announcement of OnLive and >> their new gaming service which will basically allow them to stream >> video game gameplay output realtime to any commodity PC over a >> broadband network. >> >> Currnet ISP pricing models are not not how many backbone providers >> today can handle thousands of users simultaneously watch continuous >> streaming video at 5Mb/s ? >> If this thing takes off it seem tiered pricing for internet usage >> might not be as far off as one may think? >> >> OnLive is launching the world?s highest performance Games On Demand >> service, instantly delivering the latest high-end titles over home >> broadband Internet to the TV and entry-level PCs and Macs. >> >> More overview here: >> http://www.engadget.com/2009/03/24/onlive-killed-the-game-console-star/ >> http://www.rockpapershotgun.com/2009/03/24/onlive-the-end-of-seperate-games-platforms/ >> >> -- >> [ Rodrick R. Brown ] >> http://www.rodrickbrown.com http://www.linkedin.com/in/rodrickbrown >> > > This is very similar to Roiku/TiVo/Apple TV et al just that they say they > can do HD with ~5Mb/s circuit. Has tiered pricing become a hotter topic > with those products? > > I'm not taking any position -- just asking out loud. > > -r > > > > > That's a great question. Another question I asked, specific to the OnLive product is related to *how* they plan on distributing this traffic. If you take the Netflix or Apple or Blockbuster models they don't necessarily apply to OnLive, being as their content is static and easily cacheable at the edge, whereas I'm imagining OnLive's content is far more dynamic and nearly impossible to cache, especially if they're shipping a "lightweight" device that won't be doing graphics processing (or storage) locally. -Dave From list-only at dnz.se Thu Mar 26 17:10:24 2009 From: list-only at dnz.se (=?ISO-8859-1?Q?Anders_Lindb=E4ck?=) Date: Thu, 26 Mar 2009 23:10:24 +0100 Subject: OnLive -- Very disruptive internet technology to change things as we know it? In-Reply-To: <49CBF9FE.2050501@gmail.com> References: <20090326175831.GT73294@neu.cow.org> <49CBF9FE.2050501@gmail.com> Message-ID: <9E3FC2A9-DD2E-45A1-9BBC-44A18322C0FA@dnz.se> On 26 mar 2009, at 22.56, Dave Temkin wrote: > Ravi Pina wrote: >> On Thu, Mar 26, 2009 at 12:39:25AM -0400, Rodrick Brown wrote: >> >>> Not sure if anyone has followed the recent announcement of OnLive >>> and >>> their new gaming service which will basically allow them to stream >>> video game gameplay output realtime to any commodity PC over a >>> broadband network. >>> >>> Currnet ISP pricing models are not not how many backbone providers >>> today can handle thousands of users simultaneously watch continuous >>> streaming video at 5Mb/s ? >>> If this thing takes off it seem tiered pricing for internet usage >>> might not be as far off as one may think? >>> >>> OnLive is launching the world?s highest performance Games On Demand >>> service, instantly delivering the latest high-end titles over home >>> broadband Internet to the TV and entry-level PCs and Macs. >>> >>> More overview here: >>> http://www.engadget.com/2009/03/24/onlive-killed-the-game-console- >>> star/ >>> http://www.rockpapershotgun.com/2009/03/24/onlive-the-end-of- >>> seperate-games-platforms/ >>> >>> -- >>> [ Rodrick R. Brown ] >>> http://www.rodrickbrown.com http://www.linkedin.com/in/rodrickbrown >>> >> >> This is very similar to Roiku/TiVo/Apple TV et al just that they >> say they >> can do HD with ~5Mb/s circuit. Has tiered pricing become a hotter >> topic >> with those products? >> >> I'm not taking any position -- just asking out loud. >> >> -r >> >> >> >> >> > That's a great question. Another question I asked, specific to the > OnLive product is related to *how* they plan on distributing this > traffic. If you take the Netflix or Apple or Blockbuster models > they don't necessarily apply to OnLive, being as their content is > static and easily cacheable at the edge, whereas I'm imagining > OnLive's content is far more dynamic and nearly impossible to > cache, especially if they're shipping a "lightweight" device that > won't be doing graphics processing (or storage) locally. > > -Dave > Reading about the solution it is essentially gaming over RDP, so it is impossible to cache and the test rig shown had noticable delay even though the processing servers where only 50 miles away from the show floor [1]. So even if they manage there plan on having servers in "all major metropolitan" areas, I am not hopefull, but it is a very cool idea anyway. [1] http://i.gizmodo.com/5184502/onlive-streaming-games-hands+on- impressions /Anders. From ravi at cow.org Thu Mar 26 17:39:50 2009 From: ravi at cow.org (Ravi Pina) Date: Thu, 26 Mar 2009 18:39:50 -0400 Subject: OnLive -- Very disruptive internet technology to change things as we know it? In-Reply-To: <49CBF9FE.2050501@gmail.com> References: <20090326175831.GT73294@neu.cow.org> <49CBF9FE.2050501@gmail.com> Message-ID: <20090326223949.GX73294@neu.cow.org> On Thu, Mar 26, 2009 at 02:56:14PM -0700, Dave Temkin wrote: > That's a great question. Another question I asked, specific to the > OnLive product is related to *how* they plan on distributing this > traffic. If you take the Netflix or Apple or Blockbuster models they > don't necessarily apply to OnLive, being as their content is static and > easily cacheable at the edge, whereas I'm imagining OnLive's content is > far more dynamic and nearly impossible to cache, especially if they're > shipping a "lightweight" device that won't be doing graphics processing > (or storage) locally. > > -Dave To overly simplify what they are doing and hopefully answering your question they are a IPKVM with a ultra efficient high quality video codec. That said there really isn't any way to cache content that I can think of since everything is dynamic. As to how do you mean protocol or delivery platform? The latter sounded like from the press conference that they will at minimum have roughly 5 or so POPs (from their 'need to be 1000 mi from the customer') over the country. I suspect the radius will shrink as they roll out. -r From charles at thewybles.com Thu Mar 26 19:32:10 2009 From: charles at thewybles.com (Charles Wyble) Date: Thu, 26 Mar 2009 17:32:10 -0700 Subject: First steps towards v6 support by ATT? Message-ID: <49CC1E8A.20608@thewybles.com> While researching at&t and ipv6 I came across http://www.feise.com/~jfeise/blogs/index.php?blog=8 and also http://www.corp.att.com/gov/solution/network_services/data_nw/ipv6/ Looks like they have established a tunnel in the United States perhaps? I realize that getting native v6 support to DSL users isn't exactly a high priority for US IPSes, but building tunnel servers that are on the same continent as the user base is nice. :) .... of course that tunnel might be broken. Can anyone comment on this? From morrowc.lists at gmail.com Thu Mar 26 19:48:32 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 26 Mar 2009 20:48:32 -0400 Subject: First steps towards v6 support by ATT? In-Reply-To: <49CC1E8A.20608@thewybles.com> References: <49CC1E8A.20608@thewybles.com> Message-ID: <75cb24520903261748g30b532b5o2576301a9c4a1dec@mail.gmail.com> On Thu, Mar 26, 2009 at 8:32 PM, Charles Wyble wrote: > While researching at&t and ipv6 I came across > http://www.feise.com/~jfeise/blogs/index.php?blog=8 and also doesn't that blog basically say: "it's broke Jim..." and that 7018 (really 7132) passes off the anycast into HE.net? > http://www.corp.att.com/gov/solution/network_services/data_nw/ipv6/ > > Looks like they have established a tunnel in the United States perhaps? > how did you gather that? Maybe Tom knows more about this and can let us all know? -Chris From charles at thewybles.com Thu Mar 26 19:59:14 2009 From: charles at thewybles.com (Charles Wyble) Date: Thu, 26 Mar 2009 17:59:14 -0700 Subject: First steps towards v6 support by ATT? In-Reply-To: <75cb24520903261748g30b532b5o2576301a9c4a1dec@mail.gmail.com> References: <49CC1E8A.20608@thewybles.com> <75cb24520903261748g30b532b5o2576301a9c4a1dec@mail.gmail.com> Message-ID: <49CC24E2.8020303@thewybles.com> Christopher Morrow wrote: > On Thu, Mar 26, 2009 at 8:32 PM, Charles Wyble wrote: >> While researching at&t and ipv6 I came across >> http://www.feise.com/~jfeise/blogs/index.php?blog=8 and also > > doesn't that blog basically say: "it's broke Jim..." and that 7018 > (really 7132) passes off the anycast into HE.net? Yes. It does say it's broken. However it's entirely possible that AT&T hands out different routes to their l33t enterprise/govt customers with t1 or better who pay real money, vs end users. > >> http://www.corp.att.com/gov/solution/network_services/data_nw/ipv6/ >> >> Looks like they have established a tunnel in the United States perhaps? >> > > how did you gather that? Maybe Tom knows more about this and can let > us all know? From: Remote Access Service to IPv6 Internet * Support IPv6 for small (or satellite) locations and individual remote users * Reach a dynamically configurable IPv6 Tunnel Gateway through IPv4 ISPs through fractional T1, DSL or dial-up access * The Tunnel Setup Protocol (TSP) will be used to create tunnels to transport IPv6 traffic over an IPv4 network to the gateway Granted that doesn't necessarily mean it's in the United States, but I'm guessing it would be due to being an offering targeted at the United States Government. :) Hence my request for more comments/information. Maybe off topic for NANOG but then what does that even mean anymore? :) From twright at internode.com.au Thu Mar 26 20:09:49 2009 From: twright at internode.com.au (Tom Wright) Date: Fri, 27 Mar 2009 11:39:49 +1030 Subject: REVERSE DNS Practices. In-Reply-To: <20090326165658.GA23335@hesketh.com> References: <20090321103230.24415.qmail@simone.iecc.com> <7c9a4be6ad650d86a4884a739cb2ada9@imap.yoafrica.com> <200903221030.12564.mtinka@globaltransit.net> <20090324150708.GA24053@net.tufts.edu> <49C91B9D.20301@gmail.com> <4793D242-06D6-44A1-B22A-C67E7A623EEE@internode.com.au> <20090326052217.GD29761@hesketh.com> <20090326094457.GA14094@supine.com> <20090326165658.GA23335@hesketh.com> Message-ID: <3E57EAF7-2F70-4C00-AFBA-1EA8FE5E563D@internode.com.au> On 27/03/2009, at 3:26 AM, Steven Champeon wrote: > Especially if they're spewing spam and viruses like a firehose. If you're talking about our net blocks, then please do drop me a line. We're quite serious about minimising the spam sent from our network, and we'd be happy to investigate. > Unfortunately, it's not. Even more unfortunately, we see more junk > from their generic statics than we do from their obvious dynamics. That seems about right. We filter port 25 outbound from our dynamic ranges (by default). http://www.internode.on.net/support/faq/email/port_filtering/ -- Kind Regards, Tom Wright Internode Network Operations P: +61 8 8228 2999 W: http://www.internode.on.net From morrowc.lists at gmail.com Thu Mar 26 20:13:26 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 26 Mar 2009 21:13:26 -0400 Subject: First steps towards v6 support by ATT? In-Reply-To: <49CC24E2.8020303@thewybles.com> References: <49CC1E8A.20608@thewybles.com> <75cb24520903261748g30b532b5o2576301a9c4a1dec@mail.gmail.com> <49CC24E2.8020303@thewybles.com> Message-ID: <75cb24520903261813g84c6a0bo77f9f77a3a223e95@mail.gmail.com> On Thu, Mar 26, 2009 at 8:59 PM, Charles Wyble wrote: > > > Christopher Morrow wrote: >> >> On Thu, Mar 26, 2009 at 8:32 PM, Charles Wyble >> wrote: >>> >>> While researching at&t and ipv6 I came across >>> http://www.feise.com/~jfeise/blogs/index.php?blog=8 and also >> >> doesn't that blog basically say: "it's broke Jim..." and that 7018 >> (really 7132) passes off the anycast into HE.net? > > > Yes. It does say it's broken. However it's entirely possible that AT&T hands > out different routes to their l33t enterprise/govt customers with t1 or > better who pay real money, vs end users. > yea... maybe they do, I don't see that from my view of 7018's routing data (limited as it may be) > >> >>> http://www.corp.att.com/gov/solution/network_services/data_nw/ipv6/ >>> >>> Looks like they have established a tunnel in the United States perhaps? >>> >> >> how did you gather that? Maybe Tom knows more about this and can let >> us all know? > > From: > > Remote Access Service to IPv6 Internet > > ? ?* Support IPv6 for small (or satellite) locations and individual remote > users > ? ?* Reach a dynamically configurable IPv6 Tunnel Gateway through IPv4 ISPs > through fractional T1, DSL or dial-up access > ? ?* The Tunnel Setup Protocol (TSP) will be used to create tunnels to > transport IPv6 traffic over an IPv4 network to the gateway > wow, 'tsp'... uhm, what's that I wonder? This: http://www.broker.ipv6.ac.uk/download.html perhaps?? yeek! > Granted that doesn't necessarily mean it's in the United States, but I'm > guessing it would be due to being an offering targeted at the United States > Government. :) Sure... I'd love to know though :) > > Hence my request for more comments/information. > agreed > Maybe off topic for NANOG but then what does that even mean anymore? :) I'm fairly sure that operating a network (even a v6 network) is on-topic for nanog. From charles at thewybles.com Thu Mar 26 20:23:46 2009 From: charles at thewybles.com (Charles Wyble) Date: Thu, 26 Mar 2009 18:23:46 -0700 Subject: First steps towards v6 support by ATT? In-Reply-To: <75cb24520903261813g84c6a0bo77f9f77a3a223e95@mail.gmail.com> References: <49CC1E8A.20608@thewybles.com> <75cb24520903261748g30b532b5o2576301a9c4a1dec@mail.gmail.com> <49CC24E2.8020303@thewybles.com> <75cb24520903261813g84c6a0bo77f9f77a3a223e95@mail.gmail.com> Message-ID: <49CC2AA2.9090506@thewybles.com> >> > > yea... maybe they do, I don't see that from my view of 7018's routing > data (limited as it may be) Interesting. > >>>> http://www.corp.att.com/gov/solution/network_services/data_nw/ipv6/ >>>> >>>> Looks like they have established a tunnel in the United States perhaps? >>>> >>> how did you gather that? Maybe Tom knows more about this and can let >>> us all know? >> From: >> >> Remote Access Service to IPv6 Internet >> >> * Support IPv6 for small (or satellite) locations and individual remote >> users >> * Reach a dynamically configurable IPv6 Tunnel Gateway through IPv4 ISPs >> through fractional T1, DSL or dial-up access >> * The Tunnel Setup Protocol (TSP) will be used to create tunnels to >> transport IPv6 traffic over an IPv4 network to the gateway >> > > wow, 'tsp'... uhm, what's that I wonder? This: > http://www.broker.ipv6.ac.uk/download.html > > perhaps?? yeek! Yes looks like. Especially with the mention of DSL/dial up access. Plus I seem to recall some discussion around the ipv6 mandate having some language specifying they had to support it transit wise, but not necessarily be on v6 addresses. [1] Anyone from .gov with ATT connectivity care to comment (both on the nature of the native/tunneled v6 offering and the actual requirements of meeting the mandate) [1] Language from http://georgewbush-whitehouse.archives.gov/omb/memoranda/fy2005/m05-22.pdf "Meaning the network backbone is either operating a dual stack network core or it is operating in a pure IPv6 mode, i.e., IPv6-compliant and configured to carry operational IPv6 traffic." From morrowc.lists at gmail.com Thu Mar 26 21:15:42 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 26 Mar 2009 22:15:42 -0400 Subject: First steps towards v6 support by ATT? In-Reply-To: <49CC2AA2.9090506@thewybles.com> References: <49CC1E8A.20608@thewybles.com> <75cb24520903261748g30b532b5o2576301a9c4a1dec@mail.gmail.com> <49CC24E2.8020303@thewybles.com> <75cb24520903261813g84c6a0bo77f9f77a3a223e95@mail.gmail.com> <49CC2AA2.9090506@thewybles.com> Message-ID: <75cb24520903261915p113d57f0pdd78c672c868afb@mail.gmail.com> On Thu, Mar 26, 2009 at 9:23 PM, Charles Wyble wrote: >>> >> >> yea... maybe they do, I don't see that from my view of 7018's routing >> data (limited as it may be) > > Interesting. so, actually, looking at 7018's route-server: route-server> sho ip bgp 192.88.99.1 | in recei 7018 1239, (received & used) 7018 1239, (received & used) 7018 1239, (received & used) 7018 1239, (received & used) 7018 1239, (received & used) 7018 1239, (received & used) 7018 1239, (received & used) 7018 1239, (received & used) 7018 1239, (received & used) 7018 1239, (received & used) 7018 1239, (received & used) 7018 1239, (received & used) 7018 1239, (received & used) 7018 1239, (received & used) 7018 1239, (received & used) 7018 1239, (received & used) 7018 1239, (received & used) 7018 1239, (received & used) seems they prefer Sprint for 6to4 services... 7132 doesn't have a publicly listed route-server :( oh well. -chris From tom at spf.is-is.ca Thu Mar 26 22:25:36 2009 From: tom at spf.is-is.ca (tom scholl) Date: Thu, 26 Mar 2009 23:25:36 -0400 Subject: First steps towards v6 support by ATT? Message-ID: <20090327032536.GA59513@spf.is-is.ca> > seems they prefer Sprint for 6to4 services... 7132 doesn't have a > publicly listed route-server :( oh well. There is route-server.sbcglobal.net. I'm able to hit HE's anycast box from various locations within AS7132. I'll try to contact the blogger to help out. From schampeo at hesketh.com Thu Mar 26 22:28:21 2009 From: schampeo at hesketh.com (Steven Champeon) Date: Thu, 26 Mar 2009 23:28:21 -0400 Subject: REVERSE DNS Practices. In-Reply-To: <3E57EAF7-2F70-4C00-AFBA-1EA8FE5E563D@internode.com.au> References: <20090321103230.24415.qmail@simone.iecc.com> <7c9a4be6ad650d86a4884a739cb2ada9@imap.yoafrica.com> <200903221030.12564.mtinka@globaltransit.net> <20090324150708.GA24053@net.tufts.edu> <49C91B9D.20301@gmail.com> <4793D242-06D6-44A1-B22A-C67E7A623EEE@internode.com.au> <20090326052217.GD29761@hesketh.com> <20090326094457.GA14094@supine.com> <20090326165658.GA23335@hesketh.com> <3E57EAF7-2F70-4C00-AFBA-1EA8FE5E563D@internode.com.au> Message-ID: <20090327032821.GA3303@hesketh.com> on Fri, Mar 27, 2009 at 11:39:49AM +1030, Tom Wright wrote: > On 27/03/2009, at 3:26 AM, Steven Champeon wrote: >> Especially if they're spewing spam and viruses like a firehose. > > If you're talking about our net blocks, then > please do drop me a line. We're quite serious > about minimising the spam sent from our network, > and we'd be happy to investigate. Thanks, but I think it's easy enough for you to rsync a copy of CBL or other DNSBL zones and grepcidr through it for your own netblocks, so I'll just continue as I am. I appreciate the offer, though, and don't doubt the sincerity. I just don't have time to police your networks for you, much less everyone else's. >> Unfortunately, it's not. Even more unfortunately, we see more junk >> from their generic statics than we do from their obvious dynamics. > > That seems about right. We filter port 25 outbound from > our dynamic ranges (by default). > http://www.internode.on.net/support/faq/email/port_filtering/ How long have you been doing this? And do all of your statically assigned internode.on.net PTRs contain the token 'static'? Or not? If not, why not? In any case, do you provide custom PTRs for those who ask? If so, why not provide them for /all/ customers with statics? The hosts with 'padsl' tokens - are they all NAT/VPNs (Private Access DSL, a la THUS) , or just "Personal ADSL"? Are your hosts with ppp tokens dynamic, static, or a mixture? I see both types; hosts wstarting with 'ppp' and containing a 'static' token, and others without. Martin Barry mentioned 'LNS' as a big giveaway as to the sort of nodes those are, and suggested that they're infrastructure devices which would never send mail, yet in the past couple weeks we've seen connections from the following hosts: ppp121-44-233-193.lns1.per1.internode.on.net ppp118-208-178-233.lns10.mel4.internode.on.net ppp224-33.lns3.syd7.internode.on.net ppp121-44-110-124.lns10.syd6.internode.on.net So I guess they're not that sort of device. Under Technobabble on the Web page above, you specify which services are usually static and which dynamic, making distinctions between Home, SOHO, Corporate and so forth, but your naming doesn't reflect those distinctions. (Think Road Runner, who uses res.rr.com for nearly all of their home cable hookups, and biz.rr.com for their business cable). Thanks for any assistance/clarification you can provide. -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2553 w: http://hesketh.com/ antispam news, solutions for sendmail, exim, postfix: http://enemieslist.com/ From morrowc.lists at gmail.com Fri Mar 27 01:54:36 2009 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 27 Mar 2009 02:54:36 -0400 Subject: First steps towards v6 support by ATT? In-Reply-To: <20090327032536.GA59513@spf.is-is.ca> References: <20090327032536.GA59513@spf.is-is.ca> Message-ID: <75cb24520903262354j2e7d665fpfb10f30e565bdb80@mail.gmail.com> On Thu, Mar 26, 2009 at 11:25 PM, tom scholl wrote: >> seems they prefer Sprint for 6to4 services... 7132 doesn't have a >> publicly listed route-server ?:( oh well. > > There is route-server.sbcglobal.net. > > I'm able to hit HE's anycast box from various locations within AS7132. I'll try to contact the blogger to help out. neat! -> (from the above route-server) 192.88.99.0/24 *[BGP/170] 6w3d 12:02:29, MED 1, localpref 115, from 66.10.0.24 AS path: 6939 I -Chris From cidr-report at potaroo.net Fri Mar 27 06:00:04 2009 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 27 Mar 2009 22:00:04 +1100 (EST) Subject: BGP Update Report Message-ID: <200903271100.n2RB04f4044313@wattle.apnic.net> BGP Update Report Interval: 23-Feb-09 -to- 26-Mar-09 (32 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS9583 178710 4.2% 168.3 -- SIFY-AS-IN Sify Limited 2 - AS3130 75459 1.8% 580.5 -- RGNET-3130 RGnet/PSGnet 3 - AS6629 45245 1.1% 7540.8 -- NOAA-AS - NOAA 4 - AS35805 34923 0.8% 109.8 -- UTG-AS United Telecom AS 5 - AS9498 33067 0.8% 47.5 -- BBIL-AP BHARTI Airtel Ltd. 6 - AS4771 31425 0.7% 119.9 -- NZTELECOM Netgate 7 - AS5056 28898 0.7% 249.1 -- INS-NET-2 - Iowa Network Services 8 - AS29372 28893 0.7% 324.6 -- SFR-NETWORK SFR 9 - AS6458 28167 0.7% 86.9 -- Telgua 10 - AS12978 28084 0.7% 156.9 -- DOGAN-ONLINE Dogan Iletisim Elektronik Servis Hizmetleri AS 11 - AS17488 26032 0.6% 16.6 -- HATHWAY-NET-AP Hathway IP Over Cable Internet 12 - AS5050 24618 0.6% 2461.8 -- PSC-EXT - Pittsburgh Supercomputing Center 13 - AS4434 23460 0.6% 601.5 -- ERX-RADNET1-AS PT Rahajasa Media Internet 14 - AS7643 22445 0.5% 19.7 -- VNN-AS-AP Vietnam Posts and Telecommunications (VNPT) 15 - AS4648 22396 0.5% 110.3 -- NZIX-2 Netgate 16 - AS4795 20117 0.5% 61.9 -- INDOSATM2-ID INDOSATM2 ASN 17 - AS9829 19858 0.5% 30.9 -- BSNL-NIB National Internet Backbone 18 - AS17974 18503 0.4% 31.5 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 19 - AS8103 17873 0.4% 29.9 -- STATE-OF-FLA - Florida Department of Management Services - Technology Program 20 - AS10620 17537 0.4% 22.1 -- TV Cable S.A. TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS5691 10406 0.2% 10406.0 -- MITRE-AS-5 - The MITRE Corporation 2 - AS6629 45245 1.1% 7540.8 -- NOAA-AS - NOAA 3 - AS19017 5658 0.1% 5658.0 -- QUALCOMM-QWBS-LV - Qualcomm, Inc. 4 - AS30306 17285 0.4% 4321.2 -- AfOL-Sz-AS 5 - AS8225 4183 0.1% 4183.0 -- ASTELIT-MSK-AS Astelit Autonomous System 6 - AS46653 10128 0.2% 3376.0 -- FREDRIKSON---BYRON - Fredrikson & Byron, P.A. 7 - AS6312 3284 0.1% 3284.0 -- WESTWORLD-AS - WestWorld Media, LLC 8 - AS41343 5906 0.1% 2953.0 -- TRIUNFOTEL-ASN TRIUNFOTEL 9 - AS5050 24618 0.6% 2461.8 -- PSC-EXT - Pittsburgh Supercomputing Center 10 - AS8755 2068 0.1% 2068.0 -- CITYLINESPB-AS CityLine-SPb Autonomous System 11 - AS28194 4074 0.1% 2037.0 -- 12 - AS30552 1970 0.1% 1970.0 -- SAINT-JOSEPHS-HOSPITAL-OF-ATLANTA - Saint Joseph's Hospital of Atlanta 13 - AS32398 13839 0.3% 1729.9 -- REALNET-ASN-1 14 - AS46328 14725 0.3% 1636.1 -- PTCNEBRASKA - PIERCE TELEPHONE COMPANY, INCORPORATED 15 - AS7717 12904 0.3% 1613.0 -- OPENIXP-AS-ID-AP OpenIXP ASN 16 - AS20925 4456 0.1% 1485.3 -- RESEAU-DANZAS DANZAS Autonomous System 17 - AS30520 5756 0.1% 1439.0 -- NUANCE-SOMERVILLE - NUANCE COMMUNICATIONS, INC 18 - AS35335 1430 0.0% 1430.0 -- ESSTU-AS East-Siberian State Technological University AS 19 - AS40344 1379 0.0% 1379.0 -- PROSK-1 - Pro Sky Wireless 20 - AS42291 4884 0.1% 1221.0 -- ISTRANET-AS Istranet LLC TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 72.23.246.0/24 24527 0.5% AS5050 -- PSC-EXT - Pittsburgh Supercomputing Center 2 - 192.35.129.0/24 15183 0.3% AS6629 -- NOAA-AS - NOAA 3 - 192.102.88.0/24 15043 0.3% AS6629 -- NOAA-AS - NOAA 4 - 198.77.177.0/24 15007 0.3% AS6629 -- NOAA-AS - NOAA 5 - 221.135.105.0/24 14858 0.3% AS9583 -- SIFY-AS-IN Sify Limited 6 - 210.214.222.0/24 14823 0.3% AS9583 -- SIFY-AS-IN Sify Limited 7 - 210.214.232.0/24 14774 0.3% AS9583 -- SIFY-AS-IN Sify Limited 8 - 210.214.177.0/24 14743 0.3% AS9583 -- SIFY-AS-IN Sify Limited 9 - 210.214.132.0/24 14723 0.3% AS9583 -- SIFY-AS-IN Sify Limited 10 - 210.214.184.0/24 14714 0.3% AS9583 -- SIFY-AS-IN Sify Limited 11 - 210.214.156.0/24 14705 0.3% AS9583 -- SIFY-AS-IN Sify Limited 12 - 210.214.146.0/24 14539 0.3% AS9583 -- SIFY-AS-IN Sify Limited 13 - 210.214.117.0/24 14435 0.3% AS9583 -- SIFY-AS-IN Sify Limited 14 - 210.210.127.0/24 14386 0.3% AS9583 -- SIFY-AS-IN Sify Limited 15 - 41.204.2.0/24 13641 0.3% AS32398 -- REALNET-ASN-1 16 - 221.134.32.0/24 12908 0.3% AS9583 -- SIFY-AS-IN Sify Limited 17 - 121.101.184.0/24 12755 0.3% AS38785 -- BAGUSNET-AS-ID PT. BORNEO BROADBAND TECHNOLOGY AS7717 -- OPENIXP-AS-ID-AP OpenIXP ASN 18 - 222.255.51.64/26 11005 0.2% AS7643 -- VNN-AS-AP Vietnam Posts and Telecommunications (VNPT) 19 - 192.12.120.0/24 10406 0.2% AS5691 -- MITRE-AS-5 - The MITRE Corporation 20 - 199.45.13.0/24 10096 0.2% AS46653 -- FREDRIKSON---BYRON - Fredrikson & Byron, P.A. Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Mar 27 06:00:02 2009 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 27 Mar 2009 22:00:02 +1100 (EST) Subject: The Cidr Report Message-ID: <200903271100.n2RB02kJ044301@wattle.apnic.net> This report has been generated at Fri Mar 27 21:14:03 2009 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 20-03-09 290412 181310 21-03-09 290541 181280 22-03-09 290520 181269 23-03-09 290491 181327 24-03-09 290531 181343 25-03-09 290656 181601 26-03-09 290800 181539 27-03-09 290729 181710 AS Summary 30998 Number of ASes in routing system 13159 Number of ASes announcing only one prefix 4322 Largest number of prefixes announced by an AS AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc. 89615616 Largest address span announced by an AS (/32s) AS27064: DDN-ASNBLK1 - DoD Network Information Center Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 27Mar09 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 290864 181668 109196 37.5% All ASes AS6389 4322 343 3979 92.1% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4323 4248 1677 2571 60.5% TWTC - tw telecom holdings, inc. AS209 2655 1156 1499 56.5% ASN-QWEST - Qwest Communications Corporation AS4766 1822 529 1293 71.0% KIXS-AS-KR Korea Telecom AS17488 1532 349 1183 77.2% HATHWAY-NET-AP Hathway IP Over Cable Internet AS22773 1038 66 972 93.6% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS8452 1247 298 949 76.1% TEDATA TEDATA AS1785 1737 797 940 54.1% AS-PAETEC-NET - PaeTec Communications, Inc. AS4755 1177 271 906 77.0% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS8151 1438 572 866 60.2% Uninet S.A. de C.V. AS19262 969 250 719 74.2% VZGNI-TRANSIT - Verizon Internet Services Inc. AS7545 800 203 597 74.6% TPG-INTERNET-AP TPG Internet Pty Ltd AS11492 1193 636 557 46.7% CABLEONE - CABLE ONE, INC. AS6478 1295 742 553 42.7% ATT-INTERNET3 - AT&T WorldNet Services AS3356 1198 650 548 45.7% LEVEL3 Level 3 Communications AS18101 760 222 538 70.8% RIL-IDC Reliance Infocom Ltd Internet Data Centre, AS2706 544 26 518 95.2% HKSUPER-HK-AP Pacific Internet (Hong Kong) Limited AS6517 745 231 514 69.0% RELIANCEGLOBALCOM - Reliance Globalcom Services, Inc AS22047 607 119 488 80.4% VTR BANDA ANCHA S.A. AS4808 616 160 456 74.0% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS17908 603 148 455 75.5% TCISL Tata Communications AS4804 494 64 430 87.0% MPX-AS Microplex PTY LTD AS9443 523 95 428 81.8% INTERNETPRIMUS-AS-AP Primus Telecommunications AS24560 678 250 428 63.1% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS7018 1449 1022 427 29.5% ATT-INTERNET4 - AT&T WorldNet Services AS17676 547 131 416 76.1% GIGAINFRA BB TECHNOLOGY Corp. AS7011 962 550 412 42.8% FRONTIER-AND-CITIZENS - Frontier Communications of America, Inc. AS4668 693 285 408 58.9% LGNET-AS-KR LG CNS AS5668 775 383 392 50.6% AS-5668 - CenturyTel Internet Holdings, Inc. AS6471 442 62 380 86.0% ENTEL CHILE S.A. Total 37109 12287 24822 66.9% Top 30 total Possible Bogus Routes 24.75.116.0/22 AS10796 SCRR-10796 - Road Runner HoldCo LLC 24.245.128.0/17 AS11492 CABLEONE - CABLE ONE, INC. 24.246.0.0/17 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 24.246.128.0/18 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 41.220.16.0/20 AS8668 TELONE-AS TelOne Zimbabwe P/L 41.223.112.0/22 AS5713 SAIX-NET 41.223.188.0/24 AS22351 INTELSAT Intelsat Global BGP Routing Policy 41.223.189.0/24 AS26452 BRING-AS - BringCom, Inc. 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 63.140.213.0/24 AS22555 UTC - Universal Talkware Corporation 63.143.251.0/24 AS22555 UTC - Universal Talkware Corporation 64.31.32.0/19 AS11955 SCRR-11955 - Road Runner HoldCo LLC 64.31.32.0/22 AS10796 SCRR-10796 - Road Runner HoldCo LLC 64.31.36.0/23 AS10796 SCRR-10796 - Road Runner HoldCo LLC 64.31.38.0/23 AS12262 RR-CINCINNATI-ASN-01 - Road Runner HoldCo LLC 64.31.40.0/23 AS12262 RR-CINCINNATI-ASN-01 - Road Runner HoldCo LLC 64.31.42.0/23 AS10796 SCRR-10796 - Road Runner HoldCo LLC 64.31.44.0/23 AS10796 SCRR-10796 - Road Runner HoldCo LLC 64.31.46.0/24 AS10796 SCRR-10796 - Road Runner HoldCo LLC 64.31.48.0/22 AS11060 NEO-RR-COM - Road Runner HoldCo LLC 64.31.53.0/24 AS10796 SCRR-10796 - Road Runner HoldCo LLC 64.31.55.0/24 AS10796 SCRR-10796 - Road Runner HoldCo LLC 64.31.59.0/24 AS7017 SCRR-7015 - Road Runner HoldCo LLC 64.31.60.0/24 AS7017 SCRR-7015 - Road Runner HoldCo LLC 64.73.192.0/19 AS11247 IBSINC - Internet Business Services, Inc. 64.79.88.0/24 AS26096 LODDEN - Lodden Services 64.79.89.0/24 AS26096 LODDEN - Lodden Services 64.147.64.0/19 AS40156 THEOPT-HOU - The Optimal Link Corporation 64.186.0.0/19 AS6371 AMERICATEL - Americatel Corporation 64.186.6.0/24 AS6371 AMERICATEL - Americatel Corporation 66.11.32.0/20 AS6261 VISINET - Visionary Systems, Inc. 66.11.40.0/21 AS6261 VISINET - Visionary Systems, Inc. 66.54.91.0/24 AS30506 BLACKSUN-1 - Blacksun Technologies LLC 66.55.160.0/19 AS29994 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.206.32.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.33.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.34.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.35.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.40.0/22 AS174 COGENT Cogent/PSI 66.206.44.0/23 AS174 COGENT Cogent/PSI 66.206.47.0/24 AS17557 PKTELECOM-AS-AP Pakistan Telecom 66.207.32.0/20 AS23011 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 69.71.192.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 69.80.0.0/17 AS3043 AMPHIB-AS - Amphibian Media Corporation 80.88.0.0/21 AS33774 DJAWEB 80.88.8.0/22 AS33774 DJAWEB 80.88.10.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 91.212.99.0/24 AS43113 WARPNET-AS Warpnet 96.0.0.0/16 AS32392 OPENTRANSFER-ECOMMERCE - Ecommerce Corporation 98.96.0.0/13 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 109.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 109.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 109.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 121.50.168.0/21 AS9931 CAT-AP The Communication Authoity of Thailand, CAT 121.101.3.0/24 AS4739 CIX-ADELAIDE-AS Internode Systems Pty Ltd 121.101.4.0/24 AS4739 CIX-ADELAIDE-AS Internode Systems Pty Ltd 121.101.7.0/24 AS4739 CIX-ADELAIDE-AS Internode Systems Pty Ltd 121.101.17.0/24 AS4739 CIX-ADELAIDE-AS Internode Systems Pty Ltd 121.101.18.0/23 AS4739 CIX-ADELAIDE-AS Internode Systems Pty Ltd 122.128.120.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. 124.157.1.0/24 AS4739 CIX-ADELAIDE-AS Internode Systems Pty Ltd 124.157.22.0/24 AS4739 CIX-ADELAIDE-AS Internode Systems Pty Ltd 124.157.30.0/24 AS4739 CIX-ADELAIDE-AS Internode Systems Pty Ltd 124.157.32.0/23 AS4739 CIX-ADELAIDE-AS Internode Systems Pty Ltd 124.157.34.0/24 AS4739 CIX-ADELAIDE-AS Internode Systems Pty Ltd 124.157.56.0/24 AS4739 CIX-ADELAIDE-AS Internode Systems Pty Ltd 131.161.0.0/16 AS7091 VIANET-ASN - ViaNet Communications 137.0.0.0/13 AS27064 DDN-ASNBLK1 - DoD Network Information Center 163.142.0.0/16 AS2500 WIDE-BB WIDE Project 172.7.0.0/24 AS28175 172.10.1.0/30 AS18305 POSNET POSDATA Co.,Ltd 178.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 178.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 178.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc 192.9.200.0/24 AS3602 AS3602-RTI - Rogers Telecom Inc. 192.64.85.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.107.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.108.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.177.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.70.164.0/24 AS25689 NRCNET-AS - National Research Council of Canada 192.96.37.0/24 AS10474 NETACTIVE 192.96.135.0/24 AS2018 TENET-1 192.96.136.0/23 AS2018 TENET-1 192.96.141.0/24 AS2018 TENET-1 192.96.143.0/24 AS2018 TENET-1 192.96.145.0/24 AS2018 TENET-1 192.96.177.0/24 AS6083 POSIX-AFRICA 192.101.45.0/24 AS2905 TICSA-ASN 192.101.46.0/24 AS6503 Avantel, S.A. 192.101.64.0/21 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.72.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.74.0/24 AS1239 SPRINTLINK - Sprint 192.124.248.0/23 AS680 DFN-IP service G-WiN 192.124.252.0/22 AS680 DFN-IP service G-WiN 192.131.233.0/24 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 192.133.6.0/24 AS10282 ORANGE-BUSINESS-SERVICES-CEEUR Orange Business Services (formerly Equant) AS for CEEUR 192.153.144.0/21 AS27064 DDN-ASNBLK1 - DoD Network Information Center 192.154.32.0/19 AS81 NCREN - MCNC 192.188.208.0/20 AS27064 DDN-ASNBLK1 - DoD Network Information Center 196.6.108.0/24 AS5713 SAIX-NET 196.10.119.0/24 AS2018 TENET-1 196.10.122.0/23 AS2018 TENET-1 196.10.251.0/24 AS2018 TENET-1 196.10.252.0/23 AS2018 TENET-1 196.10.254.0/24 AS2018 TENET-1 196.13.101.0/24 AS2018 TENET-1 196.13.102.0/23 AS2018 TENET-1 196.13.104.0/24 AS2018 TENET-1 196.13.121.0/24 AS2018 TENET-1 196.13.125.0/24 AS2018 TENET-1 196.13.126.0/24 AS2018 TENET-1 196.13.169.0/24 AS2018 TENET-1 196.13.174.0/23 AS2018 TENET-1 196.13.176.0/21 AS2018 TENET-1 196.13.192.0/22 AS2018 TENET-1 196.13.196.0/24 AS2018 TENET-1 196.32.96.0/20 AS6453 GLOBEINTERNET TATA Communications 196.202.224.0/21 AS8818 TELE Greenland Autonomous System 198.1.2.0/24 AS4761 INDOSAT-INP-AP INDOSAT Internet Network Provider 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc. 198.54.82.0/24 AS2018 TENET-1 198.54.92.0/24 AS2018 TENET-1 198.54.222.0/24 AS2018 TENET-1 198.97.72.0/21 AS27064 DDN-ASNBLK1 - DoD Network Information Center 198.97.96.0/19 AS27064 DDN-ASNBLK1 - DoD Network Information Center 198.97.240.0/20 AS27064 DDN-ASNBLK1 - DoD Network Information Center 198.161.87.0/24 AS6539 GT-BELL - Bell Canada 198.167.0.0/16 AS7456 INTERHOP - Interhop Network SERVICES Inc. 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 198.169.0.0/16 AS803 SASKTEL - Saskatchewan Telecommunications 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services 199.10.0.0/16 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.114.0.0/21 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.114.128.0/18 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.114.130.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.131.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.132.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.134.0/24 AS3541 ITSDN-U4 - DoD Network Information Center 199.114.136.0/24 AS27044 DDN-ASNBLK1 - DoD Network Information Center 199.114.138.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.140.0/24 AS3544 ITSDN-U7 - DoD Network Information Center 199.114.142.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.144.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.148.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.150.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.152.0/24 AS27033 DDN-ASNBLK1 - DoD Network Information Center 199.114.153.0/24 AS27034 DDN-ASNBLK1 - DoD Network Information Center 199.114.154.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.114.156.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.114.160.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.121.0.0/16 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.123.0.0/18 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.123.16.0/20 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.123.80.0/21 AS27064 DDN-ASNBLK1 - DoD Network Information Center 199.189.32.0/19 AS7332 IQUEST-AS - IQuest Internet 199.202.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.202.216.0/21 AS577 BACOM - Bell Canada 199.246.116.0/24 AS813 UUNET-CANADA - MCI Communications Services, Inc. d/b/a Verizon Business 201.229.64.0/22 AS11816 SetarNet 202.6.176.0/20 AS24316 202.58.113.0/24 AS19161 INNOCOM-TELECOM - INNOCOM TELECOM 202.72.40.0/24 AS38205 202.72.41.0/24 AS38205 202.72.47.0/24 AS38205 202.73.144.0/20 AS4788 TMNET-AS-AP TM Net, Internet Service Provider 202.80.192.0/20 AS2706 HKSUPER-HK-AP Pacific Internet (Hong Kong) Limited 202.86.252.0/22 AS4748 RESOLINK-AS-AP Resources Link Network Limited 202.86.252.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.253.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.254.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.255.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.94.70.0/24 AS9837 POWERTEL-AP Powertel Ltd 202.122.120.0/21 AS17494 BTTB-AS-AP Telecom Operator & Internet Service Provider as well 202.124.195.0/24 AS17557 PKTELECOM-AS-AP Pakistan Telecom 202.133.70.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.133.73.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.136.254.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.136.255.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.140.160.0/24 AS4841 202.140.161.0/24 AS4841 202.140.162.0/24 AS4841 202.140.163.0/24 AS4841 202.140.164.0/24 AS4841 202.140.165.0/24 AS4841 202.140.166.0/24 AS4841 202.140.167.0/24 AS4841 202.140.168.0/24 AS4841 202.140.169.0/24 AS4841 202.140.170.0/24 AS4841 202.140.171.0/24 AS4841 202.140.172.0/24 AS4841 202.140.173.0/24 AS4841 202.140.174.0/24 AS4841 202.140.175.0/24 AS4841 202.140.180.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.140.181.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.140.182.0/24 AS7540 HKCIX-AS-AP HongKong Commercial Internet Exchange 202.150.227.0/24 AS17727 NAPINFO-AS-AP PT. NAP Info Lintas Nusa 202.181.32.0/24 AS4645 ASN-HKNET-AP HKNet Co. Ltd 203.12.45.0/24 AS4854 NETSPACE-AS-AP Netspace Online Systems 203.62.0.0/17 AS7575 AARNET-AS-AP Australian Academic and Reasearch Network (AARNet) 203.78.48.0/20 AS9299 IPG-AS-AP Philippine Long Distance Telephone Company 203.83.224.0/24 AS4739 CIX-ADELAIDE-AS Internode Systems Pty Ltd 203.83.226.0/24 AS4739 CIX-ADELAIDE-AS Internode Systems Pty Ltd 203.83.233.0/24 AS4739 CIX-ADELAIDE-AS Internode Systems Pty Ltd 203.83.234.0/24 AS4739 CIX-ADELAIDE-AS Internode Systems Pty Ltd 203.89.139.0/24 AS17911 BRAINPK-AS-AP Brain Telecommunication Ltd. 203.111.192.0/20 AS7473 SINGTEL-AS-AP Singapore Telecommunications Ltd 203.112.111.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.113.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.114.0/24 AS4802 ASN-IINET iiNet Limited 203.112.116.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.117.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.118.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.119.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.120.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.121.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.127.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.128.128.0/19 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 203.128.128.0/24 AS23849 CNNIC-NET263-AP Beijing Capital-online science development Co.,Ltd. 203.152.154.0/23 AS9583 SIFY-AS-IN Sify Limited 204.9.216.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.9.217.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.9.218.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.13.140.0/22 AS7270 NET2PHONE - Net2Phone Corp. 204.13.140.0/24 AS7270 NET2PHONE - Net2Phone Corp. 204.13.142.0/24 AS7270 NET2PHONE - Net2Phone Corp. 204.13.143.0/24 AS7270 NET2PHONE - Net2Phone Corp. 204.13.184.0/23 AS35967 204.13.186.0/23 AS35967 204.13.186.0/24 AS35967 204.13.187.0/24 AS35967 204.16.120.0/23 AS12077 204.16.122.0/23 AS12077 204.19.14.0/23 AS577 BACOM - Bell Canada 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.189.134.0/24 AS11814 CYBERSURF - Cybersurf Inc. 205.210.145.0/24 AS11814 CYBERSURF - Cybersurf Inc. 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 207.174.0.0/16 AS13790 INTERNAP-BLK3 - Internap Network Services Corporation 207.174.130.0/24 AS13345 ROCKYNET-COM - Rockynet.com, Inc 207.174.131.0/24 AS30715 NETRACK - Netrack, Inc. 207.174.132.0/23 AS30715 NETRACK - Netrack, Inc. 207.174.137.0/24 AS13345 ROCKYNET-COM - Rockynet.com, Inc 207.174.138.0/23 AS13345 ROCKYNET-COM - Rockynet.com, Inc 207.174.140.0/22 AS13345 ROCKYNET-COM - Rockynet.com, Inc 207.174.151.0/24 AS11500 PEAKPEAK - Peak to Peak Internet 207.174.152.0/22 AS30715 NETRACK - Netrack, Inc. 207.174.157.0/24 AS13345 ROCKYNET-COM - Rockynet.com, Inc 207.174.158.0/24 AS11500 PEAKPEAK - Peak to Peak Internet 207.174.173.0/24 AS16618 AS-HFS-CAVION - Harland Financial Solutions, Inc. 207.174.175.0/24 AS13345 ROCKYNET-COM - Rockynet.com, Inc 207.174.177.0/24 AS11500 PEAKPEAK - Peak to Peak Internet 207.174.178.0/24 AS11500 PEAKPEAK - Peak to Peak Internet 207.174.182.0/24 AS29831 FONENET - FONE NET, LLC 207.174.188.0/22 AS30715 NETRACK - Netrack, Inc. 207.174.192.0/24 AS29831 FONENET - FONE NET, LLC 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.174.201.0/24 AS13345 ROCKYNET-COM - Rockynet.com, Inc 207.174.202.0/24 AS13345 ROCKYNET-COM - Rockynet.com, Inc 207.174.210.0/23 AS16618 AS-HFS-CAVION - Harland Financial Solutions, Inc. 207.174.211.0/24 AS16618 AS-HFS-CAVION - Harland Financial Solutions, Inc. 207.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 207.204.168.0/24 AS15150 BELLTECH-AS - BELLWETHER TECHNOLOGY CORPORATION 207.204.222.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 209.54.93.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 209.54.111.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 209.54.123.0/24 AS6062 NETPLEX - NETPLEX 209.54.240.0/21 AS10887 BPSI-AS - BPSI Internet Services 209.74.96.0/19 AS10912 INTERNAP-BLK - Internap Network Services Corporation 209.140.90.0/24 AS14461 NTSL - NET SOLUTIONS 209.140.224.0/21 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.234.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.235.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.236.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.237.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.238.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.239.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.141.16.0/21 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.141.48.0/22 AS14461 NTSL - NET SOLUTIONS 209.145.192.0/18 AS3043 AMPHIB-AS - Amphibian Media Corporation 209.222.5.0/24 AS26699 PSI-CT - Printing For Systems Inc 209.222.6.0/24 AS26699 PSI-CT - Printing For Systems Inc 209.236.64.0/19 AS7911 LVLT-7911 - Level 3 Communications, Inc. 209.236.96.0/19 AS7911 LVLT-7911 - Level 3 Communications, Inc. 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 216.37.114.0/23 AS3549 GBLX Global Crossing Ltd. 216.37.120.0/23 AS13377 216.99.16.0/24 AS6395 LVLT-6395 - Level 3 Communications, Inc. 216.99.20.0/24 AS6395 LVLT-6395 - Level 3 Communications, Inc. 216.172.198.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.172.199.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.210.86.0/24 AS577 BACOM - Bell Canada 216.240.240.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.240.241.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.240.242.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.251.207.0/24 AS1239 SPRINTLINK - Sprint 217.78.71.0/24 AS12491 IPPLANET-AS IPPlanet 217.78.72.0/24 AS12491 IPPLANET-AS IPPlanet 217.78.73.0/24 AS12491 IPPLANET-AS IPPlanet Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From robert at ufl.edu Fri Mar 27 07:18:50 2009 From: robert at ufl.edu (Robert D. Scott) Date: Fri, 27 Mar 2009 08:18:50 -0400 Subject: Google Over IPV6 Message-ID: <00d601c9aed6$2fc517d0$8f4f4770$@edu> http://www.google.com/intl/en/ipv6/ http://www.networkworld.com/news/2009/032509-google-ipv6-easy.html Any one making use of Google IPV6? Robert D. Scott Robert at ufl.edu Senior Network Engineer 352-273-0113 Phone CNS - Network Services 352-392-2061 CNS Phone Tree University of Florida 352-392-9440 FAX Florida Lambda Rail 352-294-3571 FLR NOC Gainesville, FL 32611 321-663-0421 Cell From peter at peter-dambier.de Fri Mar 27 07:35:16 2009 From: peter at peter-dambier.de (Peter Dambier) Date: Fri, 27 Mar 2009 13:35:16 +0100 Subject: Google Over IPV6 In-Reply-To: <00d601c9aed6$2fc517d0$8f4f4770$@edu> References: <00d601c9aed6$2fc517d0$8f4f4770$@edu> Message-ID: <49CCC804.7060402@peter-dambier.de> Yes I do. I can use it but sometimes got trouble with teredo. Retry half an hour later works :) ipv6.google.com looks better to me than the IPv4 version does. More comfort. It is worth the trouble with teredo. Peter Robert D. Scott wrote: > http://www.google.com/intl/en/ipv6/ > > http://www.networkworld.com/news/2009/032509-google-ipv6-easy.html > > Any one making use of Google IPV6? > > Robert D. Scott Robert at ufl.edu > Senior Network Engineer 352-273-0113 Phone > CNS - Network Services 352-392-2061 CNS Phone Tree > University of Florida 352-392-9440 FAX > Florida Lambda Rail 352-294-3571 FLR NOC > Gainesville, FL 32611 321-663-0421 Cell > > > -- Peter and Karin Dambier Cesidian Root - Radice Cesidiana Rimbacher Strasse 16 D-69509 Moerlenbach-Bonsweiher +49(6209)795-816 (Telekom) +49(6252)750-308 (VoIP: sipgate.de) mail: peter at peter-dambier.de http://www.peter-dambier.de/ http://iason.site.voila.fr/ https://sourceforge.net/projects/iason/ ULA= fd80:4ce1:c66a::/48 From steve at ibctech.ca Fri Mar 27 07:43:02 2009 From: steve at ibctech.ca (Steve Bertrand) Date: Fri, 27 Mar 2009 08:43:02 -0400 Subject: Google Over IPV6 In-Reply-To: <00d601c9aed6$2fc517d0$8f4f4770$@edu> References: <00d601c9aed6$2fc517d0$8f4f4770$@edu> Message-ID: <49CCC9D6.70305@ibctech.ca> Robert D. Scott wrote: > http://www.google.com/intl/en/ipv6/ > > http://www.networkworld.com/news/2009/032509-google-ipv6-easy.html > > Any one making use of Google IPV6? It's been my Firefox home page ever since it was available. Steve From nuno.vieira at nfsi.pt Fri Mar 27 07:37:38 2009 From: nuno.vieira at nfsi.pt (Nuno Vieira - nfsi telecom) Date: Fri, 27 Mar 2009 12:37:38 +0000 (WET) Subject: Google Over IPV6 In-Reply-To: <00d601c9aed6$2fc517d0$8f4f4770$@edu> Message-ID: <1500330546.19641238157458639.JavaMail.root@zimbra.nfsi.pt> yup... and it is nice, adwords don't work pretty well (or at least on the GeoIP thingie), and i get less publicity to look at :-) --- Nuno Vieira nfsi telecom, lda. nuno.vieira at nfsi.pt Tel. (+351) 21 949 2300 - Fax (+351) 21 949 2301 http://www.nfsi.pt/ ----- "Robert D. Scott" wrote: > http://www.google.com/intl/en/ipv6/ > > http://www.networkworld.com/news/2009/032509-google-ipv6-easy.html > > Any one making use of Google IPV6? > > Robert D. Scott Robert at ufl.edu > Senior Network Engineer 352-273-0113 Phone > CNS - Network Services 352-392-2061 CNS Phone Tree > University of Florida 352-392-9440 FAX > Florida Lambda Rail 352-294-3571 FLR NOC > Gainesville, FL 32611 321-663-0421 Cell From daniel at bit.nl Fri Mar 27 07:59:03 2009 From: daniel at bit.nl (Daniel Verlouw) Date: Fri, 27 Mar 2009 13:59:03 +0100 Subject: Google Over IPV6 In-Reply-To: <00d601c9aed6$2fc517d0$8f4f4770$@edu> References: <00d601c9aed6$2fc517d0$8f4f4770$@edu> Message-ID: <1238158743.17980.10.camel@daniel.office.bit.nl> On Fri, 2009-03-27 at 08:18 -0400, Robert D. Scott wrote: > Any one making use of Google IPV6? yes. We participate in the Google IPv6 trial program so our recursors get AAAA records for www.google.com and so far it's been great, no issues whatsoever. daniel at jun1> traceroute www.google.com traceroute6 to www.l.google.com (2001:4860:a003::68) from 2001:7f8:1::a501:2859:2, 64 hops max, 12 byte packets 1 pr61.ams04.net.google.com (2001:7f8:1::a501:5169:1) 2.388 ms 1.798 ms 1.712 ms 2 2001:4860::23 (2001:4860::23) 8.664 ms 8.480 ms 8.364 ms 3 2001:4860:a003::68 (2001:4860:a003::68) 8.624 ms 8.639 ms 8.719 ms Regards, Daniel. From kauer at biplane.com.au Fri Mar 27 08:06:58 2009 From: kauer at biplane.com.au (Karl Auer) Date: Sat, 28 Mar 2009 00:06:58 +1100 Subject: Google Over IPV6 In-Reply-To: <49CCC804.7060402@peter-dambier.de> References: <00d601c9aed6$2fc517d0$8f4f4770$@edu> <49CCC804.7060402@peter-dambier.de> Message-ID: <1238159218.8962.191.camel@karl> On Fri, 2009-03-27 at 13:35 +0100, Peter Dambier wrote: > I can use it but sometimes got trouble with teredo. > Retry half an hour later works :) > > ipv6.google.com looks better to me than the IPv4 version does. > More comfort. It is worth the trouble with teredo. Um, are you sure you are using Google over IPv6? This is *not the same thing* as ipv6.google.com. Google over IPv6 is about accessing www.google.com via IPv6. For you to be doing this, you must have IPv6 connectivity and your IPv6 network must meet Google's fairly stringent requirements. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/~kauer/ +61-428-957160 (mob) GPG fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From s.ewing at aussiehq.com.au Fri Mar 27 08:20:26 2009 From: s.ewing at aussiehq.com.au (Shaun Ewing) Date: Sat, 28 Mar 2009 00:20:26 +1100 Subject: Google Over IPV6 In-Reply-To: <1238158743.17980.10.camel@daniel.office.bit.nl> Message-ID: On 27/03/09 11:59 PM, "Daniel Verlouw" wrote: > yes. We participate in the Google IPv6 trial program so our recursors > get AAAA records for www.google.com and so far it's been great, no > issues whatsoever. Same. We've been participating since January and haven't had any problems: # traceroute6 www.google.com traceroute to www.google.com (2001:4860:c003::68), 30 hops max, 40 byte packets 1 vl2-gw.cbr1.as24557.net.au (2405:5000:1:2::1) 0.492 ms 0.484 ms 0.501 ms 2 gi0-1-4.bdr1.syd1.as24557.net.au (2405:5000:1:4::21) 5.009 ms 5.048 ms 5.212 ms 3 AS15169.ipv6.sydney.pipenetworks.com (2001:7fa:b::14) 4.552 ms 4.538 ms 4.522 ms 4 2001:4860::29 (2001:4860::29) 157.930 ms 157.914 ms 149.638 ms 5 2001:4860:c003::68 (2001:4860:c003::68) 157.709 ms 156.651 ms 149.585 ms -Shaun From smb at cs.columbia.edu Fri Mar 27 08:34:58 2009 From: smb at cs.columbia.edu (Steven M. Bellovin) Date: Fri, 27 Mar 2009 09:34:58 -0400 Subject: Google Over IPV6 In-Reply-To: References: <1238158743.17980.10.camel@daniel.office.bit.nl> Message-ID: <20090327093458.3fe15904@cs.columbia.edu> On Sat, 28 Mar 2009 00:20:26 +1100 Shaun Ewing wrote: > > On 27/03/09 11:59 PM, "Daniel Verlouw" wrote: > > > yes. We participate in the Google IPv6 trial program so our > > recursors get AAAA records for www.google.com and so far it's been > > great, no issues whatsoever. > > Same. > > We've been participating since January and haven't had any problems: > > # traceroute6 www.google.com > traceroute to www.google.com (2001:4860:c003::68), 30 hops max, 40 > byte packets > 1 vl2-gw.cbr1.as24557.net.au (2405:5000:1:2::1) 0.492 ms 0.484 > ms 0.501 ms > 2 gi0-1-4.bdr1.syd1.as24557.net.au (2405:5000:1:4::21) 5.009 ms > 5.048 ms 5.212 ms > 3 AS15169.ipv6.sydney.pipenetworks.com (2001:7fa:b::14) 4.552 ms > 4.538 ms 4.522 ms > 4 2001:4860::29 (2001:4860::29) 157.930 ms 157.914 ms 149.638 ms > 5 2001:4860:c003::68 (2001:4860:c003::68) 157.709 ms 156.651 ms > 149.585 ms > It's working for me, too, though I noticed that tcptraceroute (at least the version I have) doesn't do well with ipv6.google.com. --Steve Bellovin, http://www.cs.columbia.edu/~smb From daniel at bit.nl Fri Mar 27 08:46:50 2009 From: daniel at bit.nl (Daniel Verlouw) Date: Fri, 27 Mar 2009 14:46:50 +0100 Subject: Google Over IPV6 In-Reply-To: <20090327093458.3fe15904@cs.columbia.edu> References: <1238158743.17980.10.camel@daniel.office.bit.nl> <20090327093458.3fe15904@cs.columbia.edu> Message-ID: <1238161610.17980.13.camel@daniel.office.bit.nl> On Fri, 2009-03-27 at 09:34 -0400, Steven M. Bellovin wrote: > It's working for me, too, though I noticed that tcptraceroute (at least > the version I have) doesn't do well with ipv6.google.com. seems to work fine from over here: # tcptraceroute6 www.google.com 80 traceroute to www.google.com (2001:4860:a003::68) from 2001:7b8:3:30::, port 80, from port 62699, 30 hops max, 60 byte packets 1 2001:7b8:3:30::2 (2001:7b8:3:30::2) 0.505 ms 0.246 ms 0.228 ms 2 pr61.ams04.net.google.com (2001:7f8:1::a501:5169:1) 1.664 ms 1.619 ms 1.641 ms 3 2001:4860::23 (2001:4860::23) 220.972 ms 174.560 ms 120.445 ms 4 2001:4860:a003::68 (2001:4860:a003::68) 9.101 ms [open] 9.196 ms 9.055 ms # tcptraceroute6 -V traceroute6: TCP & UDP IPv6 traceroute tool 0.9.3 ($Rev: 483 $) --Daniel. From JShao at dtcc.com Fri Mar 27 09:02:16 2009 From: JShao at dtcc.com (Jay Shao) Date: Fri, 27 Mar 2009 10:02:16 -0400 Subject: Jay Shao is out of the office. Message-ID: I will be out of the office starting 03/27/2009 and will not return until 03/30/2009. I will respond to your message when I return. Please contact with NETTCP at DTCC.COM for any production issues ----------------------------------------- ________________________________________________________ DTCC DISCLAIMER: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error, please notify us immediately and delete the email and any attachments from your system. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. From ren.provo at gmail.com Fri Mar 27 09:08:41 2009 From: ren.provo at gmail.com (Ren Provo) Date: Fri, 27 Mar 2009 10:08:41 -0400 Subject: [NANOG-announce] NANOG46 - abstracts, trains & hotels - oh my! Message-ID: <787581440903270708s34fb318dpb70bde25beaf5c13@mail.gmail.com> Hi folks, NANOG46 is only a few months away and I hear many are getting their ducks in a row to participate. We, the Program Committee, would like to remind all who have submitted abstracts at http://pc.nanog.org that the time has come to get your presentation materials uploaded. For those of you still considering submitting presentations it is not too late to request a BOF, tutorial, track, or general session slot. Lightning talk submissions will be welcomed in May. Shifting gears to represent the host, Comcast, I would encourage folks to consider exploring Philly either before or after NANOG46, which runs 14-17 June. http://nanog46.comcast.net includes links for sightseeing, socializing and general transportation guidance. This is a work in progress, yes it will be IPv6 ready shortly, and if folks have recommendations for inclusion please do email me directly. Amtrak is running a special until July (must purchase by 12-Jun-09) which can significantly reduce costs, a bonus in this economy. Go to http://www.amtrak.com and click on 'Hot Deals' for the lower fares on Acela Express. Washington, DC to Philly is only $73 and you get to keep your shoes on! Philly is a walking city and there is no need to rent a car. Whether you arrive by Amtrak or airplane consider using the SEPTA Rail trains to take you to the conference hotel. Market East would be the right stop to exit, also known as Convention Center. Follow the signs for the Hard Rock Cafe and you'll spot the Loews Hotel across the street. Of course if you really want to explore Philly above ground take the Segway tour - http://reservations.gophila.com/nexres/activities/detail.cgi?src=10018788&ses=1829b368884e04999bcd78b4bc0455e9&airport_code=PHL&city=Phl&actType=tours&supplier_id=22653 Hotel reservations for the Loews can be made at http://www.phlgroupbooking.com/NANOG/ The NANOG Group Rate is $199 (plus 15.2% tax) which includes guest room Internet access. Group rate expires: May 29, 2009 Registration is open and we look forward to a fun NANOG in Philly! Cheers, -Ren Provo _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce From smb at cs.columbia.edu Fri Mar 27 09:18:36 2009 From: smb at cs.columbia.edu (Steven M. Bellovin) Date: Fri, 27 Mar 2009 10:18:36 -0400 Subject: Google Over IPV6 In-Reply-To: <1238161610.17980.13.camel@daniel.office.bit.nl> References: <1238158743.17980.10.camel@daniel.office.bit.nl> <20090327093458.3fe15904@cs.columbia.edu> <1238161610.17980.13.camel@daniel.office.bit.nl> Message-ID: <20090327101836.5b2e945f@cs.columbia.edu> On Fri, 27 Mar 2009 14:46:50 +0100 Daniel Verlouw wrote: > On Fri, 2009-03-27 at 09:34 -0400, Steven M. Bellovin wrote: > > It's working for me, too, though I noticed that tcptraceroute (at > > least the version I have) doesn't do well with ipv6.google.com. > > seems to work fine from over here: > > # tcptraceroute6 www.google.com 80 > traceroute to www.google.com (2001:4860:a003::68) from > 2001:7b8:3:30::, port 80, from port 62699, 30 hops max, 60 > byte packets > 1 2001:7b8:3:30::2 (2001:7b8:3:30::2) 0.505 ms 0.246 ms 0.228 ms > 2 pr61.ams04.net.google.com (2001:7f8:1::a501:5169:1) 1.664 ms > 1.619 ms 1.641 ms > 3 2001:4860::23 (2001:4860::23) 220.972 ms 174.560 ms 120.445 ms > 4 2001:4860:a003::68 (2001:4860:a003::68) 9.101 ms [open] 9.196 ms > 9.055 ms > > # tcptraceroute6 -V > traceroute6: TCP & UDP IPv6 traceroute tool 0.9.3 ($Rev: 483 $) > Traceroute6 works; I'm talking about tcptraceroute, which is useful for seeing what happens to connections in the presence of ACLs, firewalls, and the like. I don't seem to have a tcptraceroute6. --Steve Bellovin, http://www.cs.columbia.edu/~smb From jason at lixfeld.ca Fri Mar 27 09:22:27 2009 From: jason at lixfeld.ca (Jason Lixfeld) Date: Fri, 27 Mar 2009 10:22:27 -0400 Subject: Gigabit speed test anybody? In-Reply-To: <40185.69.30.17.85.1238083040.squirrel@www.woofpaws.com> References: <55529.69.30.17.85.1238004325.squirrel@www.woofpaws.com> <40185.69.30.17.85.1238083040.squirrel@www.woofpaws.com> Message-ID: <41FBACA1-8498-4288-A4D3-501A972B91D7@lixfeld.ca> Ironically, two days later, I find myself in exactly the same position; needing an iperf box to test a 100Mb client connection against. In a perfect world, this box would hang off of NYIIX (or Arbinet) and be able to sustain 100Mb of throughput for the duration of a couple of generic iperf tests that I need to perform at a client site in a couple of hours. Thanks in advance... On 26-Mar-09, at 11:57 AM, Rick Ernst wrote: > > Thanks to multiple private/public responses. > > I was able to get an iperf test and also a close mirror for a DVD iso. > > Time to put live traffic on it and see what happens. > > > > > On Wed, March 25, 2009 11:05, Rick Ernst wrote: >> >> Resent from my subscribed address. Hopefully this isn't a dupe to >> anybody. >> --------------------------------------- >> >> >> I'm working on turning up our first GigE connection (400mbs CIR) >> and the >> various online speedtests I'm aware of choke after about 100Mbs or >> so. >> >> Does anybody know of testing sites that can handle higher >> bandwidth, or >> have an ftp host or similar to test against? >> >> I'm connected to Level3, backhauled to Seattle, WA. >> >> Thanks, >> Rick >> >> >> >> > > > From bicknell at ufp.org Fri Mar 27 09:32:12 2009 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 27 Mar 2009 09:32:12 -0500 Subject: Google Over IPV6 In-Reply-To: <00d601c9aed6$2fc517d0$8f4f4770$@edu> References: <00d601c9aed6$2fc517d0$8f4f4770$@edu> Message-ID: <20090327143212.GA50105@ussenterprise.ufp.org> In a message written on Fri, Mar 27, 2009 at 08:18:50AM -0400, Robert D. Scott wrote: > Any one making use of Google IPV6? We are in the trial: % traceroute6 -n www.google.com traceroute6 to www.l.google.com (2001:4860:b002::68) from 2001:4f8:3:bb::5, 64 hops max, 12 byte packets 1 2001:4f8:3:bb:203:47ff:fefd:ddab 0.350 ms 0.263 ms 0.233 ms 2 2001:4f8:3:c::1 0.734 ms 0.481 ms 0.613 ms 3 2001:4f8:0:4::3 4.602 ms 5.859 ms 5.234 ms 4 2001:4f8:0:1::45:1 78.206 ms 2.829 ms 1.858 ms 5 2001:504:d::1f 13.601 ms 1.607 ms 1.738 ms 6 2001:4860::30 80.442 ms 70.358 ms 68.369 ms 7 2001:4860:b002::68 70.092 ms 68.064 ms 68.021 ms Completely seamless from here. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From Grzegorz at Janoszka.pl Fri Mar 27 09:54:56 2009 From: Grzegorz at Janoszka.pl (Grzegorz Janoszka) Date: Fri, 27 Mar 2009 15:54:56 +0100 Subject: Google Over IPV6 In-Reply-To: <1238158743.17980.10.camel@daniel.office.bit.nl> References: <00d601c9aed6$2fc517d0$8f4f4770$@edu> <1238158743.17980.10.camel@daniel.office.bit.nl> Message-ID: <49CCE8C0.9080707@Janoszka.pl> Daniel Verlouw wrote: > yes. We participate in the Google IPv6 trial program so our recursors > get AAAA records for www.google.com and so far it's been great, no > issues whatsoever. Same experiences - it just works. > daniel at jun1> traceroute www.google.com > traceroute6 to www.l.google.com (2001:4860:a003::68) from > 2001:7f8:1::a501:2859:2, 64 hops max, 12 byte packets > 1 pr61.ams04.net.google.com (2001:7f8:1::a501:5169:1) 2.388 ms 1.798 > ms 1.712 ms > 2 2001:4860::23 (2001:4860::23) 8.664 ms 8.480 ms 8.364 ms > 3 2001:4860:a003::68 (2001:4860:a003::68) 8.624 ms 8.639 ms 8.719 > ms Yes, but only www records have AAAA record, the domain (google.com without www prefix) is still IPv4 only. -- Grzegorz Janoszka From robert at ufl.edu Fri Mar 27 10:03:05 2009 From: robert at ufl.edu (Robert D. Scott) Date: Fri, 27 Mar 2009 11:03:05 -0400 Subject: Google Over IPV6 In-Reply-To: <49CCE8C0.9080707@Janoszka.pl> References: <00d601c9aed6$2fc517d0$8f4f4770$@edu> <1238158743.17980.10.camel@daniel.office.bit.nl> <49CCE8C0.9080707@Janoszka.pl> Message-ID: <016c01c9aeed$2245ed20$66d1c760$@edu> Their press would indicate that more than www is IPV6. When I posted my original note, I was not really looking for end user feedback, but rather is anyone peering V6 with them on either a public fabric or private peer. Any idea if they have native V6 transit, or are tunneling, and to where. Robert D. Scott Robert at ufl.edu Senior Network Engineer 352-273-0113 Phone CNS - Network Services 352-392-2061 CNS Phone Tree University of Florida 352-392-9440 FAX Florida Lambda Rail 352-294-3571 FLR NOC Gainesville, FL 32611 321-663-0421 Cell -----Original Message----- From: Grzegorz Janoszka [mailto:Grzegorz at Janoszka.pl] Sent: Friday, March 27, 2009 10:55 AM To: Daniel Verlouw Cc: nanog at nanog.org Subject: Re: Google Over IPV6 Daniel Verlouw wrote: > yes. We participate in the Google IPv6 trial program so our recursors > get AAAA records for www.google.com and so far it's been great, no > issues whatsoever. Same experiences - it just works. > daniel at jun1> traceroute www.google.com > traceroute6 to www.l.google.com (2001:4860:a003::68) from > 2001:7f8:1::a501:2859:2, 64 hops max, 12 byte packets > 1 pr61.ams04.net.google.com (2001:7f8:1::a501:5169:1) 2.388 ms 1.798 > ms 1.712 ms > 2 2001:4860::23 (2001:4860::23) 8.664 ms 8.480 ms 8.364 ms > 3 2001:4860:a003::68 (2001:4860:a003::68) 8.624 ms 8.639 ms 8.719 > ms Yes, but only www records have AAAA record, the domain (google.com without www prefix) is still IPv4 only. -- Grzegorz Janoszka From Grzegorz at Janoszka.pl Fri Mar 27 10:07:36 2009 From: Grzegorz at Janoszka.pl (Grzegorz Janoszka) Date: Fri, 27 Mar 2009 16:07:36 +0100 Subject: Google Over IPV6 In-Reply-To: <016c01c9aeed$2245ed20$66d1c760$@edu> References: <00d601c9aed6$2fc517d0$8f4f4770$@edu> <1238158743.17980.10.camel@daniel.office.bit.nl> <49CCE8C0.9080707@Janoszka.pl> <016c01c9aeed$2245ed20$66d1c760$@edu> Message-ID: <49CCEBB8.6070606@Janoszka.pl> Robert D. Scott wrote: > When I posted my original note, I was not really looking for end user > feedback, but rather is anyone peering V6 with them on either a public > fabric or private peer. Any idea if they have native V6 transit, or are > tunneling, and to where. No tuneling I think. We have with them several peerings, IPv6 native together with IPv4. -- Grzegorz Janoszka From internetplumber at gmail.com Fri Mar 27 10:13:02 2009 From: internetplumber at gmail.com (Rob Evans) Date: Fri, 27 Mar 2009 15:13:02 +0000 Subject: Google Over IPV6 In-Reply-To: <016c01c9aeed$2245ed20$66d1c760$@edu> References: <00d601c9aed6$2fc517d0$8f4f4770$@edu> <1238158743.17980.10.camel@daniel.office.bit.nl> <49CCE8C0.9080707@Janoszka.pl> <016c01c9aeed$2245ed20$66d1c760$@edu> Message-ID: <9a8fa98b0903270813k6a1e8e53w2d450f0ef7f31c59@mail.gmail.com> > When I posted my original note, I was not really looking for end user > feedback, but rather is anyone peering V6 with them on either a public > fabric or private peer. Any idea if they have native V6 transit, or are > tunneling, and to where. They are peering over some IXPs and private peerings with native IPv6, and I believe Google like to check IPv6 connectivity before putting your DNS resolver addresses in a whitelist so AAAA records are returned. Regards, Rob From chris at netops.t3com.net Fri Mar 27 10:23:56 2009 From: chris at netops.t3com.net (Chris Wallace) Date: Fri, 27 Mar 2009 11:23:56 -0400 Subject: ATT Mail Administrator Message-ID: <465AB0EA-60E3-4484-AA97-E93C56CF3BE6@netops.t3com.net> Can someone from ATT contact off-list with the contact for the mail administrator? We recently got a new CIDR from ARIN and previously belonged to Adelphia. Needless to say, the IP's are pretty much blacklisted everywhere as dynamic IP space. I have gotten them pretty much cleaned up on other mail servers but I can't get a hold of ATT. Any help would be greatly appreciated! ---Chris From bicknell at ufp.org Fri Mar 27 10:26:14 2009 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 27 Mar 2009 10:26:14 -0500 Subject: Google Over IPV6 In-Reply-To: <016c01c9aeed$2245ed20$66d1c760$@edu> References: <00d601c9aed6$2fc517d0$8f4f4770$@edu> <1238158743.17980.10.camel@daniel.office.bit.nl> <49CCE8C0.9080707@Janoszka.pl> <016c01c9aeed$2245ed20$66d1c760$@edu> Message-ID: <20090327152614.GB53235@ussenterprise.ufp.org> In a message written on Fri, Mar 27, 2009 at 11:03:05AM -0400, Robert D. Scott wrote: > When I posted my original note, I was not really looking for end user > feedback, but rather is anyone peering V6 with them on either a public > fabric or private peer. Any idea if they have native V6 transit, or are > tunneling, and to where. AFAIK you have to have native peering with them to be part of the pilot. At least, you did when we signed up. They may have relaxed that since. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From davidu at everydns.net Fri Mar 27 10:37:00 2009 From: davidu at everydns.net (David Ulevitch) Date: Fri, 27 Mar 2009 08:37:00 -0700 Subject: ATT Mail Administrator In-Reply-To: <465AB0EA-60E3-4484-AA97-E93C56CF3BE6@netops.t3com.net> References: <465AB0EA-60E3-4484-AA97-E93C56CF3BE6@netops.t3com.net> Message-ID: <49CCF29C.7020604@everydns.net> On 3/27/09 8:23 AM, Chris Wallace wrote: > Can someone from ATT contact off-list with the contact for the mail > administrator? We recently got a new CIDR from ARIN and previously > belonged to Adelphia. Needless to say, the IP's are pretty much > blacklisted everywhere as dynamic IP space. I have gotten them pretty > much cleaned up on other mail servers but I can't get a hold of ATT. Any > help would be greatly appreciated! They typically respond / resolve to submissions at this URL within a few hours: http://worldnet.att.net/general-info/block_admin.html (via http://www.att.net/blocks) -David From bjamlists at gmail.com Fri Mar 27 10:44:14 2009 From: bjamlists at gmail.com (Brandon James) Date: Fri, 27 Mar 2009 10:44:14 -0500 Subject: ATT Mail Administrator In-Reply-To: <49CCF29C.7020604@everydns.net> References: <465AB0EA-60E3-4484-AA97-E93C56CF3BE6@netops.t3com.net> <49CCF29C.7020604@everydns.net> Message-ID: <49CCF44E.1000208@gmail.com> David Ulevitch wrote: > On 3/27/09 8:23 AM, Chris Wallace wrote: >> Can someone from ATT contact off-list with the contact for the mail >> administrator? We recently got a new CIDR from ARIN and previously >> belonged to Adelphia. Needless to say, the IP's are pretty much >> blacklisted everywhere as dynamic IP space. I have gotten them pretty >> much cleaned up on other mail servers but I can't get a hold of ATT. Any >> help would be greatly appreciated! > > They typically respond / resolve to submissions at this URL within a > few hours: > > http://worldnet.att.net/general-info/block_admin.html > (via http://www.att.net/blocks) > > -David > > > Yeah they are typically very responsive and helpful via normal channels. From aduitsis at gmail.com Fri Mar 27 10:54:23 2009 From: aduitsis at gmail.com (Athanasios Douitsis) Date: Fri, 27 Mar 2009 17:54:23 +0200 Subject: Google Over IPV6 In-Reply-To: <1238158743.17980.10.camel@daniel.office.bit.nl> References: <00d601c9aed6$2fc517d0$8f4f4770$@edu> <1238158743.17980.10.camel@daniel.office.bit.nl> Message-ID: <317578510903270854q313747d8uf48f725044754d5e@mail.gmail.com> On Fri, Mar 27, 2009 at 2:59 PM, Daniel Verlouw wrote: > On Fri, 2009-03-27 at 08:18 -0400, Robert D. Scott wrote: > > Any one making use of Google IPV6? > > yes. We participate in the Google IPv6 trial program so our recursors > get AAAA records for www.google.com and so far it's been great, no > issues whatsoever. > > daniel at jun1> traceroute www.google.com > traceroute6 to www.l.google.com (2001:4860:a003::68) from > 2001:7f8:1::a501:2859:2, 64 hops max, 12 byte packets > 1 pr61.ams04.net.google.com (2001:7f8:1::a501:5169:1) 2.388 ms 1.798 > ms 1.712 ms > 2 2001:4860::23 (2001:4860::23) 8.664 ms 8.480 ms 8.364 ms > 3 2001:4860:a003::68 (2001:4860:a003::68) 8.624 ms 8.639 ms 8.719 > ms > > Regards, > Daniel. > > Heard that they are somewhat picky about who they AAAA-enable. Our campus has had native IPv6 everywhere and upwards all the way to Geant for many years. We are thinking of applying in the hopes that it will boost IPv6 usage. Did you have any trouble getting them to IPv6-enable you? Anyone from Google in the list with any informative comment? Regards, Athanasios From nick at foobar.org Fri Mar 27 11:08:23 2009 From: nick at foobar.org (Nick Hilliard) Date: Fri, 27 Mar 2009 16:08:23 +0000 Subject: Google Over IPV6 In-Reply-To: <20090327152614.GB53235@ussenterprise.ufp.org> References: <00d601c9aed6$2fc517d0$8f4f4770$@edu> <1238158743.17980.10.camel@daniel.office.bit.nl> <49CCE8C0.9080707@Janoszka.pl> <016c01c9aeed$2245ed20$66d1c760$@edu> <20090327152614.GB53235@ussenterprise.ufp.org> Message-ID: <49CCF9F7.8050704@foobar.org> On 27/03/2009 15:26, Leo Bicknell wrote: > AFAIK you have to have native peering with them to be part of the > pilot. At least, you did when we signed up. They may have relaxed > that since. According to a Google IPv6 talk I attended yesterday, they don't intend to relax that rule. Tunneling ipv6 connectivity over ipv4 is trash quality engineering and to be honest, its not a credible substitute for adequate ipv6 infrastructure. Nick From charles at thewybles.com Fri Mar 27 11:43:23 2009 From: charles at thewybles.com (Charles Wyble) Date: Fri, 27 Mar 2009 09:43:23 -0700 Subject: Google Over IPV6 In-Reply-To: <20090327101836.5b2e945f@cs.columbia.edu> References: <1238158743.17980.10.camel@daniel.office.bit.nl> <20090327093458.3fe15904@cs.columbia.edu> <1238161610.17980.13.camel@daniel.office.bit.nl> <20090327101836.5b2e945f@cs.columbia.edu> Message-ID: <49CD022B.60102@thewybles.com> Steven M. Bellovin wrote: > On Fri, 27 Mar 2009 14:46:50 +0100 > Daniel Verlouw wrote: > >> On Fri, 2009-03-27 at 09:34 -0400, Steven M. Bellovin wrote: >>> It's working for me, too, though I noticed that tcptraceroute (at >>> least the version I have) doesn't do well with ipv6.google.com. >> seems to work fine from over here: >> >> # tcptraceroute6 www.google.com 80 >> traceroute to www.google.com (2001:4860:a003::68) from >> 2001:7b8:3:30::, port 80, from port 62699, 30 hops max, 60 >> byte packets >> 1 2001:7b8:3:30::2 (2001:7b8:3:30::2) 0.505 ms 0.246 ms 0.228 ms >> 2 pr61.ams04.net.google.com (2001:7f8:1::a501:5169:1) 1.664 ms >> 1.619 ms 1.641 ms >> 3 2001:4860::23 (2001:4860::23) 220.972 ms 174.560 ms 120.445 ms >> 4 2001:4860:a003::68 (2001:4860:a003::68) 9.101 ms [open] 9.196 ms >> 9.055 ms >> >> # tcptraceroute6 -V >> traceroute6: TCP & UDP IPv6 traceroute tool 0.9.3 ($Rev: 483 $) >> > Traceroute6 works; I'm talking about tcptraceroute, which is useful for > seeing what happens to connections in the presence of ACLs, firewalls, > and the like. I don't seem to have a tcptraceroute6. Very cool. apt-get install ndisc6 gives me tcptraceroute6. Didn't know about tcptraceroute(6). Thanks for sharing! :) From stephen at sprunk.org Fri Mar 27 12:19:56 2009 From: stephen at sprunk.org (Stephen Sprunk) Date: Fri, 27 Mar 2009 12:19:56 -0500 Subject: Google Over IPV6 In-Reply-To: <00d601c9aed6$2fc517d0$8f4f4770$@edu> References: <00d601c9aed6$2fc517d0$8f4f4770$@edu> Message-ID: <49CD0ABC.4090906@sprunk.org> Robert D. Scott wrote: > http://www.google.com/intl/en/ipv6/ > > http://www.networkworld.com/news/2009/032509-google-ipv6-easy.html > It's relatively easy to make _your own_ apps (i.e. ones you have the source for) support IPv6. Most companies, though, are completely reliant on their vendors, which means buying a new version, testing, deployment, etc. -- assuming the vendor is still in business, hasn't discontinued the product, has even bothered to try implementing IPv6 yet (most haven't), etc. That may also involve an upgrade of the OS that the app runs on, purchasing new hardware to handle the bloat in newer OSes, etc. You may also need to upgrade your LAN hardware to models that support IPv6 forwarding in hardware, more RAM for routers to run IPv6 code (if it's even available), new VPN boxes, etc. Now, if you keep up with your upgrades every year, and stop using products when the vendors stop supporting them or go out of business, most of this should already be built into your budgets -- but not many execs see value in that. "If it ain't broke so badly that it cuts into profits, you don't need any budget for it." S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3241 bytes Desc: S/MIME Cryptographic Signature URL: From peter at peter-dambier.de Fri Mar 27 12:27:59 2009 From: peter at peter-dambier.de (Peter Dambier) Date: Fri, 27 Mar 2009 18:27:59 +0100 Subject: Google Over IPV6 In-Reply-To: <1238159218.8962.191.camel@karl> References: <00d601c9aed6$2fc517d0$8f4f4770$@edu> <49CCC804.7060402@peter-dambier.de> <1238159218.8962.191.camel@karl> Message-ID: <49CD0C9F.2040702@peter-dambier.de> Karl Auer wrote: > On Fri, 2009-03-27 at 13:35 +0100, Peter Dambier wrote: >> I can use it but sometimes got trouble with teredo. >> Retry half an hour later works :) >> >> ipv6.google.com looks better to me than the IPv4 version does. >> More comfort. It is worth the trouble with teredo. > > Um, are you sure you are using Google over IPv6? > > This is *not the same thing* as ipv6.google.com. > > Google over IPv6 is about accessing www.google.com via IPv6. For you to > be doing this, you must have IPv6 connectivity and your IPv6 network > must meet Google's fairly stringent requirements. > > Regards, K. > I see cname www.l.google.com and only IPv4 addresses :( sorry Peter -- Peter and Karin Dambier Cesidian Root - Radice Cesidiana Rimbacher Strasse 16 D-69509 Moerlenbach-Bonsweiher +49(6209)795-816 (Telekom) +49(6252)750-308 (VoIP: sipgate.de) mail: peter at peter-dambier.de http://www.peter-dambier.de/ http://iason.site.voila.fr/ https://sourceforge.net/projects/iason/ ULA= fd80:4ce1:c66a::/48 From smb at cs.columbia.edu Fri Mar 27 12:55:20 2009 From: smb at cs.columbia.edu (Steven M. Bellovin) Date: Fri, 27 Mar 2009 13:55:20 -0400 Subject: Google Over IPV6 In-Reply-To: <49CD0C9F.2040702@peter-dambier.de> References: <00d601c9aed6$2fc517d0$8f4f4770$@edu> <49CCC804.7060402@peter-dambier.de> <1238159218.8962.191.camel@karl> <49CD0C9F.2040702@peter-dambier.de> Message-ID: <20090327135520.2e5a2b28@cs.columbia.edu> On Fri, 27 Mar 2009 18:27:59 +0100 Peter Dambier wrote: > > > Karl Auer wrote: > > On Fri, 2009-03-27 at 13:35 +0100, Peter Dambier wrote: > >> I can use it but sometimes got trouble with teredo. > >> Retry half an hour later works :) > >> > >> ipv6.google.com looks better to me than the IPv4 version does. > >> More comfort. It is worth the trouble with teredo. > > > > Um, are you sure you are using Google over IPv6? > > > > This is *not the same thing* as ipv6.google.com. > > > > Google over IPv6 is about accessing www.google.com via IPv6. For > > you to be doing this, you must have IPv6 connectivity and your IPv6 > > network must meet Google's fairly stringent requirements. > > > > Regards, K. > > > > I see cname www.l.google.com and only IPv4 addresses :( > If you're part of the Google v6 program -- that is, if your network is listed by them as v6-suitable -- you'll get different DNS answers... --Steve Bellovin, http://www.cs.columbia.edu/~smb From Mark_Andrews at isc.org Fri Mar 27 12:58:41 2009 From: Mark_Andrews at isc.org (Mark Andrews) Date: Sat, 28 Mar 2009 04:58:41 +1100 Subject: Google Over IPV6 In-Reply-To: Your message of "Fri, 27 Mar 2009 18:27:59 BST." <49CD0C9F.2040702@peter-dambier.de> Message-ID: <200903271758.n2RHwfM2019200@drugs.dv.isc.org> In message <49CD0C9F.2040702 at peter-dambier.de>, Peter Dambier writes: > > > Karl Auer wrote: > > On Fri, 2009-03-27 at 13:35 +0100, Peter Dambier wrote: > >> I can use it but sometimes got trouble with teredo. > >> Retry half an hour later works :) > >> > >> ipv6.google.com looks better to me than the IPv4 version does. > >> More comfort. It is worth the trouble with teredo. > > > > Um, are you sure you are using Google over IPv6? > > > > This is *not the same thing* as ipv6.google.com. > > > > Google over IPv6 is about accessing www.google.com via IPv6. For you to > > be doing this, you must have IPv6 connectivity and your IPv6 network > > must meet Google's fairly stringent requirements. > > > > Regards, K. > > > > I see cname www.l.google.com and only IPv4 addresses :( Well talk to your ISP and have them turn up IPv6. :-) If they can't do native all the way to you, have them bring up a local tunnel server so they are in a position to diagnose problems with the entire tunnel path. Mark > sorry > > Peter > > -- > Peter and Karin Dambier > Cesidian Root - Radice Cesidiana > Rimbacher Strasse 16 > D-69509 Moerlenbach-Bonsweiher > +49(6209)795-816 (Telekom) > +49(6252)750-308 (VoIP: sipgate.de) > mail: peter at peter-dambier.de > http://www.peter-dambier.de/ > http://iason.site.voila.fr/ > https://sourceforge.net/projects/iason/ > ULA= fd80:4ce1:c66a::/48 > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews at isc.org From cscora at apnic.net Fri Mar 27 13:11:41 2009 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 28 Mar 2009 04:11:41 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <200903271811.n2RIBfQF024854@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 28 Mar, 2009 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 283794 Prefixes after maximum aggregation: 134532 Deaggregation factor: 2.11 Unique aggregates announced to Internet: 139535 Total ASes present in the Internet Routing Table: 30912 Prefixes per ASN: 9.18 Origin-only ASes present in the Internet Routing Table: 26905 Origin ASes announcing only one prefix: 13087 Transit ASes present in the Internet Routing Table: 4007 Transit-only ASes present in the Internet Routing Table: 99 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 25 Max AS path prepend of ASN (18678) 21 Prefixes from unregistered ASNs in the Routing Table: 493 Unregistered ASNs in the Routing Table: 165 Number of 32-bit ASNs allocated by the RIRs: 138 Prefixes from 32-bit ASNs in the Routing Table: 20 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 251 Number of addresses announced to Internet: 2022627808 Equivalent to 120 /8s, 142 /16s and 217 /24s Percentage of available address space announced: 54.6 Percentage of allocated address space announced: 63.8 Percentage of available address space allocated: 85.5 Percentage of address space in use by end-sites: 76.1 Total number of prefixes smaller than registry allocations: 139620 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 65682 Total APNIC prefixes after maximum aggregation: 23471 APNIC Deaggregation factor: 2.80 Prefixes being announced from the APNIC address blocks: 62432 Unique aggregates announced from the APNIC address blocks: 28564 APNIC Region origin ASes present in the Internet Routing Table: 3585 APNIC Prefixes per ASN: 17.41 APNIC Region origin ASes announcing only one prefix: 974 APNIC Region transit ASes present in the Internet Routing Table: 547 Average APNIC Region AS path length visible: 3.6 Max APNIC Region AS path length visible: 19 Number of APNIC addresses announced to Internet: 409336608 Equivalent to 24 /8s, 101 /16s and 251 /24s Percentage of available APNIC address space announced: 81.3 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 APNIC Address Blocks 58/8, 59/8, 60/8, 61/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 124316 Total ARIN prefixes after maximum aggregation: 65644 ARIN Deaggregation factor: 1.89 Prefixes being announced from the ARIN address blocks: 93687 Unique aggregates announced from the ARIN address blocks: 36273 ARIN Region origin ASes present in the Internet Routing Table: 12867 ARIN Prefixes per ASN: 7.28 ARIN Region origin ASes announcing only one prefix: 4937 ARIN Region transit ASes present in the Internet Routing Table: 1239 Average ARIN Region AS path length visible: 3.3 Max ARIN Region AS path length visible: 20 Number of ARIN addresses announced to Internet: 420340480 Equivalent to 25 /8s, 13 /16s and 227 /24s Percentage of available ARIN address space announced: 80.8 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 ARIN Address Blocks 24/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 108/8, 173/8, 174/8, 184/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 65001 Total RIPE prefixes after maximum aggregation: 37810 RIPE Deaggregation factor: 1.72 Prefixes being announced from the RIPE address blocks: 59598 Unique aggregates announced from the RIPE address blocks: 39657 RIPE Region origin ASes present in the Internet Routing Table: 12845 RIPE Prefixes per ASN: 4.64 RIPE Region origin ASes announcing only one prefix: 6749 RIPE Region transit ASes present in the Internet Routing Table: 1937 Average RIPE Region AS path length visible: 4.0 Max RIPE Region AS path length visible: 23 Number of RIPE addresses announced to Internet: 392009120 Equivalent to 23 /8s, 93 /16s and 149 /24s Percentage of available RIPE address space announced: 83.4 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223 RIPE Address Blocks 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 178/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 23524 Total LACNIC prefixes after maximum aggregation: 5849 LACNIC Deaggregation factor: 4.02 Prefixes being announced from the LACNIC address blocks: 21683 Unique aggregates announced from the LACNIC address blocks: 11890 LACNIC Region origin ASes present in the Internet Routing Table: 1082 LACNIC Prefixes per ASN: 20.04 LACNIC Region origin ASes announcing only one prefix: 342 LACNIC Region transit ASes present in the Internet Routing Table: 179 Average LACNIC Region AS path length visible: 4.0 Max LACNIC Region AS path length visible: 25 Number of LACNIC addresses announced to Internet: 61816320 Equivalent to 3 /8s, 175 /16s and 62 /24s Percentage of available LACNIC address space announced: 61.4 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247 plus ERX transfers LACNIC Address Blocks 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 4816 Total AfriNIC prefixes after maximum aggregation: 1387 AfriNIC Deaggregation factor: 3.47 Prefixes being announced from the AfriNIC address blocks: 4519 Unique aggregates announced from the AfriNIC address blocks: 1351 AfriNIC Region origin ASes present in the Internet Routing Table: 284 AfriNIC Prefixes per ASN: 15.91 AfriNIC Region origin ASes announcing only one prefix: 85 AfriNIC Region transit ASes present in the Internet Routing Table: 55 Average AfriNIC Region AS path length visible: 3.9 Max AfriNIC Region AS path length visible: 15 Number of AfriNIC addresses announced to Internet: 10140928 Equivalent to 0 /8s, 154 /16s and 189 /24s Percentage of available AfriNIC address space announced: 30.2 AfriNIC AS Blocks 36864-37887 & ERX transfers AfriNIC Address Blocks 41/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 1693 6929 393 Korea Telecom (KIX) 17488 1532 121 96 Hathway IP Over Cable Interne 4755 1177 405 182 TATA Communications formerly 9583 1086 86 537 Sify Limited 4134 927 16390 367 CHINANET-BACKBONE 7545 774 163 105 TPG Internet Pty Ltd 18101 760 206 34 Reliance Infocom Ltd Internet 9498 688 296 50 BHARTI BT INTERNET LTD. 24560 678 228 175 Bharti Airtel Ltd. 9829 638 491 20 BSNL National Internet Backbo Complete listing at http://thyme.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 4324 3672 329 bellsouth.net, inc. 209 2653 4151 622 Qwest 4323 1808 1049 372 Time Warner Telecom 1785 1737 717 139 PaeTec Communications, Inc. 20115 1594 1430 725 Charter Communications 7018 1447 5896 1020 AT&T WorldNet Services 6478 1295 295 527 AT&T Worldnet Services 2386 1255 680 899 AT&T Data Communications Serv 3356 1198 10978 452 Level 3 Communications, LLC 11492 1193 192 11 Cable One Complete listing at http://thyme.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8452 1247 188 7 TEDATA 3292 453 1763 393 TDC Tele Danmark 30890 436 86 194 SC Kappa Invexim SRL 12479 405 578 6 Uni2 Autonomous System 3301 342 1685 307 TeliaNet Sweden 3215 339 3017 108 France Telecom Transpac 3320 337 7074 294 Deutsche Telekom AG 8866 337 109 22 Bulgarian Telecommunication C 29049 324 26 3 AzerSat LLC. 8551 313 288 40 Bezeq International Complete listing at http://thyme.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 1441 2831 235 UniNet S.A. de C.V. 10620 839 191 98 TVCABLE BOGOTA 22047 607 302 14 VTR PUNTO NET S.A. 7303 520 260 80 Telecom Argentina Stet-France 11830 520 294 42 Instituto Costarricense de El 16814 491 31 10 NSS, S.A. 6471 442 95 32 ENTEL CHILE S.A. 11172 410 102 72 Servicios Alestra S.A de C.V 7738 397 794 28 Telecomunicacoes da Bahia S.A 28573 386 518 25 NET Servicos de Comunicao S.A Complete listing at http://thyme.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 831 74 30 LINKdotNET AS number 20858 292 34 3 This AS will be used to conne 3741 272 858 232 The Internet Solution 2018 242 215 142 Tertiary Education Network 6713 159 150 15 Itissalat Al-MAGHRIB 33783 148 10 8 EEPAD TISP TELECOM & INTERNET 29571 137 15 8 Ci Telecom Autonomous system 5536 123 8 9 Internet Egypt Network 5713 115 507 65 Telkom SA Ltd 33776 109 6 3 Starcomms Nigeria Limited Complete listing at http://thyme.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 4324 3672 329 bellsouth.net, inc. 209 2653 4151 622 Qwest 4323 1808 1049 372 Time Warner Telecom 1785 1737 717 139 PaeTec Communications, Inc. 4766 1693 6929 393 Korea Telecom (KIX) 20115 1594 1430 725 Charter Communications 17488 1532 121 96 Hathway IP Over Cable Interne 7018 1447 5896 1020 AT&T WorldNet Services 8151 1441 2831 235 UniNet S.A. de C.V. 6478 1295 295 527 AT&T Worldnet Services Complete listing at http://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 209 2653 2031 Qwest 1785 1737 1598 PaeTec Communications, Inc. 4323 1808 1436 Time Warner Telecom 17488 1532 1436 Hathway IP Over Cable Interne 4766 1693 1300 Korea Telecom (KIX) 8452 1247 1240 TEDATA 8151 1441 1206 UniNet S.A. de C.V. 11492 1193 1182 Cable One 18566 1061 1051 Covad Communications 4755 1177 995 TATA Communications formerly Complete listing at http://thyme.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 16927 UNALLOCATED 12.0.252.0/23 7018 AT&T WorldNet Servic 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 7018 AT&T WorldNet Servic 13746 UNALLOCATED 12.24.56.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.25.107.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.152.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.154.0/23 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.159.0/24 7018 AT&T WorldNet Servic 32326 UNALLOCATED 12.40.49.0/24 7018 AT&T WorldNet Servic 25639 UNALLOCATED 12.41.169.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 24.75.116.0/22 10796 ServiceCo LLC - Road Runner 24.246.0.0/17 7018 AT&T WorldNet Services 24.246.128.0/18 7018 AT&T WorldNet Services 41.220.16.0/20 8668 TelOne Zimbabwe P/L 41.223.112.0/22 5713 Telkom SA Ltd 41.223.188.0/24 22351 Intelsat 41.223.189.0/24 26452 Local Communications Networks 62.61.220.0/24 24974 Tachyon Europe BV - Wireless 62.61.221.0/24 24974 Tachyon Europe BV - Wireless 63.140.213.0/24 22555 Universal Talkware Corporatio Complete listing at http://thyme.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:19 /9:10 /10:20 /11:56 /12:163 /13:321 /14:586 /15:1143 /16:10388 /17:4640 /18:7977 /19:17040 /20:20218 /21:19919 /22:25356 /23:25314 /24:148648 /25:646 /26:799 /27:363 /28:115 /29:37 /30:9 /31:0 /32:7 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2809 4324 bellsouth.net, inc. 4766 1398 1693 Korea Telecom (KIX) 209 1358 2653 Qwest 17488 1301 1532 Hathway IP Over Cable Interne 8452 1226 1247 TEDATA 11492 1149 1193 Cable One 1785 1145 1737 PaeTec Communications, Inc. 18566 1042 1061 Covad Communications 2386 957 1255 AT&T Data Communications Serv 4323 942 1808 Time Warner Telecom Complete listing at http://thyme.apnic.net/current/data/sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 4:13 8:172 12:2198 13:3 15:19 16:3 17:4 20:35 24:1122 32:51 38:550 40:97 41:2002 43:1 44:2 47:21 52:3 55:2 56:3 57:25 58:530 59:618 60:461 61:1104 62:1122 63:2023 64:3604 65:2430 66:3595 67:1506 68:688 69:2537 70:512 71:164 72:1651 73:2 74:1462 75:206 76:309 77:835 78:540 79:306 80:955 81:821 82:533 83:407 84:598 85:1009 86:396 87:623 88:351 89:1490 90:44 91:2089 92:331 93:1127 94:1209 95:825 96:106 97:184 98:243 99:17 109:1 110:32 112:91 113:89 114:223 115:235 116:1127 117:476 118:285 119:658 120:142 121:712 122:981 123:552 124:960 125:1302 128:221 129:226 130:129 131:415 132:74 133:9 134:186 135:39 136:241 137:153 138:147 139:77 140:419 141:104 142:391 143:331 144:323 145:43 146:376 147:150 148:513 149:239 150:147 151:200 152:151 153:136 154:11 155:266 156:167 157:297 158:133 159:273 160:281 161:133 162:271 163:148 164:478 165:533 166:276 167:361 168:682 169:162 170:475 171:38 172:10 173:249 174:153 178:1 186:7 187:69 188:9 189:304 190:2704 192:5808 193:4219 194:3330 195:2677 196:1069 198:3729 199:3317 200:5503 201:1361 202:7861 203:8069 204:3795 205:2158 206:2389 207:2797 208:3896 209:3450 210:2632 211:1107 212:1503 213:1693 214:70 215:25 216:4542 217:1268 218:360 219:416 220:1208 221:449 222:261 End of report From fw at deneb.enyo.de Fri Mar 27 13:20:42 2009 From: fw at deneb.enyo.de (Florian Weimer) Date: Fri, 27 Mar 2009 19:20:42 +0100 Subject: Google Over IPV6 In-Reply-To: <016c01c9aeed$2245ed20$66d1c760$@edu> (Robert D. Scott's message of "Fri, 27 Mar 2009 11:03:05 -0400") References: <00d601c9aed6$2fc517d0$8f4f4770$@edu> <1238158743.17980.10.camel@daniel.office.bit.nl> <49CCE8C0.9080707@Janoszka.pl> <016c01c9aeed$2245ed20$66d1c760$@edu> Message-ID: <87iqlu3k05.fsf@mid.deneb.enyo.de> * Robert D. Scott: > When I posted my original note, I was not really looking for end > user feedback, but rather is anyone peering V6 with them on either a > public fabric or private peer. Any idea if they have native V6 > transit, or are tunneling, and to where. Google seems to aim at Tier 1 status for IPv6. No transit, no tunneling. From chris at netops.t3com.net Fri Mar 27 14:54:10 2009 From: chris at netops.t3com.net (Chris Wallace) Date: Fri, 27 Mar 2009 15:54:10 -0400 Subject: ATT Mail Administrator In-Reply-To: <49CCF29C.7020604@everydns.net> References: <465AB0EA-60E3-4484-AA97-E93C56CF3BE6@netops.t3com.net> <49CCF29C.7020604@everydns.net> Message-ID: Yeah, I had just found that site after I posted to the list. I found it through an old dslreports forum thread... ---Chris On Mar 27, 2009, at 11:37 AM, David Ulevitch wrote: > On 3/27/09 8:23 AM, Chris Wallace wrote: >> Can someone from ATT contact off-list with the contact for the mail >> administrator? We recently got a new CIDR from ARIN and previously >> belonged to Adelphia. Needless to say, the IP's are pretty much >> blacklisted everywhere as dynamic IP space. I have gotten them pretty >> much cleaned up on other mail servers but I can't get a hold of >> ATT. Any >> help would be greatly appreciated! > > They typically respond / resolve to submissions at this URL within a > few hours: > > http://worldnet.att.net/general-info/block_admin.html > (via http://www.att.net/blocks) > > -David > From nanog at daork.net Fri Mar 27 16:25:08 2009 From: nanog at daork.net (Nathan Ward) Date: Fri, 27 Mar 2009 14:25:08 -0700 Subject: Google Over IPV6 In-Reply-To: <87iqlu3k05.fsf@mid.deneb.enyo.de> References: <00d601c9aed6$2fc517d0$8f4f4770$@edu> <1238158743.17980.10.camel@daniel.office.bit.nl> <49CCE8C0.9080707@Janoszka.pl> <016c01c9aeed$2245ed20$66d1c760$@edu> <87iqlu3k05.fsf@mid.deneb.enyo.de> Message-ID: <3274BEAB-B381-4FF4-8253-6F47B78FCE81@daork.net> On 27/03/2009, at 11:20 AM, Florian Weimer wrote: > Google seems to aim at Tier 1 status for IPv6. No transit, no > tunneling. That seems to be the case, yep. It's an interesting plan. On 27/03/2009, at 8:03 AM, Robert D. Scott wrote: > Their press would indicate that more than www is IPV6. Yep. Map tiles over IPv6 was turned on last week during the Google IPv6 Implementers meeting, and other stuff is IPv6 as well. The traffic jump was pretty big :-) [nward at dhcp-12df.meeting.ietf.org]~% host -t AAAA www.gmail.com | grep IPv6 googlemail.l.google.com has IPv6 address 2001:4860:b003::53 [nward at dhcp-12df.meeting.ietf.org]~% host -t AAAA maps.google.com | grep IPv6 maps.l.google.com has IPv6 address 2001:4860:b003::68 [nward at dhcp-12df.meeting.ietf.org]~% host mt0.google.com | grep IPv6 mt.l.google.com has IPv6 address 2001:4860:b003::88 mt.l.google.com has IPv6 address 2001:4860:b003::be mt.l.google.com has IPv6 address 2001:4860:b003::5b mt.l.google.com has IPv6 address 2001:4860:b003::5d etc. etc. (mt[0-3].google.com are the same) -- Nathan Ward From schampeo at hesketh.com Fri Mar 27 17:03:09 2009 From: schampeo at hesketh.com (Steven Champeon) Date: Fri, 27 Mar 2009 18:03:09 -0400 Subject: REVERSE DNS Practices. In-Reply-To: <20090326052217.GD29761@hesketh.com> References: <20090321103230.24415.qmail@simone.iecc.com> <7c9a4be6ad650d86a4884a739cb2ada9@imap.yoafrica.com> <200903221030.12564.mtinka@globaltransit.net> <20090324150708.GA24053@net.tufts.edu> <49C91B9D.20301@gmail.com> <4793D242-06D6-44A1-B22A-C67E7A623EEE@internode.com.au> <20090326052217.GD29761@hesketh.com> Message-ID: <20090327220309.GB4663@hesketh.com> on Thu, Mar 26, 2009 at 01:22:17AM -0400, Steven Champeon wrote: > on Thu, Mar 26, 2009 at 10:26:59AM +1030, Tom Wright wrote: > > Don't be afraid to create zones for each > > location, DNS lends itself to this kind of > > hierarchy naturally. > > > > I find this is tidier than lengthy A records. > > > > I.e, hostname.location.domain > > And yet makes it more difficult for anyone else to simply set > aside ALL of your dynamics as offlimits using simple substrings > (say, in sendmail's access.db or using postfix check_client_access). > > Don't be that guy. > > > W: http://www.internode.on.net > > Oh, yeah. You already are (quick! guess which of these are actually > dynamic, and which static, who's residential, who's business, etc.): As there seems to have been some misunderstanding as to what I was advocating, to the extent that some people have accused me of calling Tom and Internode out for criticism for their leaky network, etc. etc., I'll try to explain again. Due to the botnet problem, generic reverse DNS is a useful indicator of the risk involved in accepting email from a given source. I have a large (~36K patterns) collection of regexes that attempt to classify said rDNS into assignment type and various other subtypes, as well as the technology in use, on the grounds that certain types of names are highly correlated to spambot-infected hosts, or their relative likelihood of being/staying infected, anyway. I personally don't care if every ISP on the planet uses vague and uninformative PTR naming, as long as they do so consistently. It's actually in my interest to have the names be impenetrably obtuse, as we license the patterns to various appliance and reputation service providers and ISPs, etc. I am also aware, however, that many folks do not have such a collection of regexes for classified PTR naming conventions, and so whenever the subject of naming comes up, I try to point out reasons why there are best practices that should be followed, if only for the sake of mail admins being able to collectively block all mail from dynamics or generics on a certain source network in a reliable manner. First among those practices is to indicate dynamicity /first/; in Tom's example, you might even set up zones for each of your allocations - one for dynamics, and one for statics. What Tom was actually recommending, though, was to use geographies as the first (rightmost) token, which while it may have certain merits in offloading management responsibility, makes it difficult for everyone else, as it multiples the number of substrings you need to throw into your MTA filtering config. When I mentioned "spewing spam and viruses", I wasn't necessarily singling out Tom or Internode for irresponsibility, and as it turns out their volumes here are relatively low compared to others (and may, in fact, be the fault of customers whose networks they don't control at all, if they're all statically assigned). I was merely saying that it will be much more favorably received by a mail admin who is seeing high volumes of crud from a given network if said admin can block it all with one rule, instead of having to collect dozens. Nonetheless, there are inconsistencies in the on.net naming; some hosts have 'static' as a token, some others are apparently static but lack that token, and so forth. So, if I've looked at millions of hostnames and classified tens of thousands of patterns and I can't tell whether a given host is static or dynamic, I can't expect someone with little experience in global DNS label/token meanings to be able to, either. In the subsequent thread, we saw that Internode port blocks outbound 25, so some substrings I had considered dynamic may well not be. I've asked for more information and hope that I can correct my classifications. Given that most of my patterns came from hostnames who've tried to send me spam, it may be that my patterns pre-date their port 25 blocks. I have no way of knowing. I've got patterns going back six years or more, and just because I have a pattern doesn't mean I've seen traffic from a host matching the pattern recently. We also saw that padsl could mean "personal ADSL", or "private access DSL / VPN"; that "LNS" may be a network management tool, an L2TP Network Server, or a PPPoE node served *by* that server, and may well mean something else entirely (Lancaster Airport, Laboratory for Nuclear Science, and so forth). The main point still stands: clarity in naming, especially of end user nodes, is important. If I gave anyone the wrong impression about Tom or Internode, or their relative responsibility as network operators, I apologize. I had no such intent. Steve -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2553 w: http://hesketh.com/ antispam news, solutions for sendmail, exim, postfix: http://enemieslist.com/ From frnkblk at iname.com Fri Mar 27 17:33:10 2009 From: frnkblk at iname.com (Frank Bulk - iName.com) Date: Fri, 27 Mar 2009 17:33:10 -0500 Subject: Gigabit speed test anybody? In-Reply-To: <49CB09B4.7070808@ibctech.ca> References: <55529.69.30.17.85.1238004325.squirrel@www.woofpaws.com> <49CAF52B.3040704@enger.us> <49CB09B4.7070808@ibctech.ca> Message-ID: I believe there is an ITU standard for testing that could be looked at, but if you went with the same test gear that SPs use to test their circuits, I think you would be safe. Hence my mention of JDSU, but I could also add Agilent (more engineering focused), Anritsu, EXFO, Fluke (more enterprise focused), and SR Telecom. Frank -----Original Message----- From: Steve Bertrand [mailto:steve at ibctech.ca] Sent: Wednesday, March 25, 2009 11:51 PM To: Frank Bulk Cc: 'Robert M. Enger'; ernst at easystreet.com; nanog at nanog.org Subject: Re: Gigabit speed test anybody? Frank Bulk wrote: > If you're turning up a 10 GigE circuit, as a customer I would be asking for > that circuit to be tested with some modern tools such as the JDSU T-BERD. > For the price you're probably paying, it's probably not unreasonable to have > it as part of the turn-up fee. What is it then that one would classify as an 'industry standard' test for turning up 100Mb-1Gb connections over optical? Is there an industry approved standard application in which the results can be backed up by the "big" SP's? Something that can be passed to the client that explains that "even though your VPN gateway is doing 20Mbps, we can get 856Mbps over the connection without it". (My chosen setup is two FBSD boxes that boot/run from removable media into 2-4GB of RAM using Iperf and/or the 'netrate' tools). Steve ps. I've toyed with small deployments of MPLS VPNs and SP owned CE with encrypted tunnels, but the hardware to do such at any scale is out of reach for us at this point. The theory in practise is fantastic though ;) From Charles at thewybles.com Fri Mar 27 17:47:17 2009 From: Charles at thewybles.com (Charles at thewybles.com) Date: Fri, 27 Mar 2009 22:47:17 +0000 Subject: Gigabit speed test anybody? Message-ID: <286748274-1238194061-cardhu_decombobulator_blackberry.rim.net-910266317-@bxe1302.bisx.prod.on.blackberry> Owamp? ------Original Message------ From: Frank Bulk - iName.com To: 'Steve Bertrand' Cc: nanog at nanog.org ReplyTo: frnkblk at iname.com Subject: RE: Gigabit speed test anybody? Sent: Mar 27, 2009 3:33 PM I believe there is an ITU standard for testing that could be looked at, but if you went with the same test gear that SPs use to test their circuits, I think you would be safe. Hence my mention of JDSU, but I could also add Agilent (more engineering focused), Anritsu, EXFO, Fluke (more enterprise focused), and SR Telecom. Frank -----Original Message----- From: Steve Bertrand [mailto:steve at ibctech.ca] Sent: Wednesday, March 25, 2009 11:51 PM To: Frank Bulk Cc: 'Robert M. Enger'; ernst at easystreet.com; nanog at nanog.org Subject: Re: Gigabit speed test anybody? Frank Bulk wrote: > If you're turning up a 10 GigE circuit, as a customer I would be asking for > that circuit to be tested with some modern tools such as the JDSU T-BERD. > For the price you're probably paying, it's probably not unreasonable to have > it as part of the turn-up fee. What is it then that one would classify as an 'industry standard' test for turning up 100Mb-1Gb connections over optical? Is there an industry approved standard application in which the results can be backed up by the "big" SP's? Something that can be passed to the client that explains that "even though your VPN gateway is doing 20Mbps, we can get 856Mbps over the connection without it". (My chosen setup is two FBSD boxes that boot/run from removable media into 2-4GB of RAM using Iperf and/or the 'netrate' tools). Steve ps. I've toyed with small deployments of MPLS VPNs and SP owned CE with encrypted tunnels, but the hardware to do such at any scale is out of reach for us at this point. The theory in practise is fantastic though ;) Sent via BlackBerry from T-Mobile From oberman at es.net Fri Mar 27 22:29:00 2009 From: oberman at es.net (Kevin Oberman) Date: Fri, 27 Mar 2009 20:29:00 -0700 Subject: Gigabit speed test anybody? In-Reply-To: Your message of "Fri, 27 Mar 2009 22:47:17 -0000." <286748274-1238194061-cardhu_decombobulator_blackberry.rim.net-910266317-@bxe1302.bisx.prod.on.blackberry> Message-ID: <20090328032900.3E6001CC09@ptavv.es.net> > From: Charles at thewybles.com > Date: Fri, 27 Mar 2009 22:47:17 +0000 > > Owamp? owamp is a latency measurement tool. While we find it invaluable, I'm not sure how it fits in here. We use iperf on high-performance systems with a lot of tuning and Myricom 10GE cards to test 10 Gig circuits (10GE or OC-192). No particular endorsement of Myricom. We also qualified Chelsio. At the time we tested, TSO on the Chelsios caused some problems when the other end was a Myricom, but TSO is easily turned off. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman at es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From oberman at es.net Fri Mar 27 22:34:51 2009 From: oberman at es.net (Kevin Oberman) Date: Fri, 27 Mar 2009 20:34:51 -0700 Subject: Google Over IPV6 In-Reply-To: Your message of "Fri, 27 Mar 2009 19:20:42 BST." <87iqlu3k05.fsf@mid.deneb.enyo.de> Message-ID: <20090328033451.F40E91CC09@ptavv.es.net> > From: Florian Weimer > Date: Fri, 27 Mar 2009 19:20:42 +0100 > > * Robert D. Scott: > > > When I posted my original note, I was not really looking for end > > user feedback, but rather is anyone peering V6 with them on either a > > public fabric or private peer. Any idea if they have native V6 > > transit, or are tunneling, and to where. > > Google seems to aim at Tier 1 status for IPv6. No transit, no > tunneling. > >From their web page at http://www.google.com/intl/en/ipv6/: "To qualify for Google over IPv6, your network must have good IPv6 connectivity to Google. Multiple direct interconnections are preferred, but a direct peering with multiple backup routes through transit or multiple reliable transit connections may be acceptable. Your network must provide and support production-quality IPv6 networking and provide access to a substantial number of IPv6 users. Additionally, because IPv6 problems with users' connections can cause users to become unable to access Google if Google over IPv6 is enabled, we expect you to troubleshoot any IPv6 connection problems that arise in your or your users' networks." So you need multiple IPv6 connections or one IPv6 connection with transit IPv6 support to get it. A university with a direct peering with Google and and Internet2 transit to google would probably qualify. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman at es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From lsc at prgmr.com Sat Mar 28 02:12:22 2009 From: lsc at prgmr.com (Luke S Crawford) Date: 28 Mar 2009 03:12:22 -0400 Subject: REVERSE DNS Practices. In-Reply-To: <20090321130055.GA5782@vacation.karoshi.com.> References: <20090321103230.24415.qmail@simone.iecc.com> <7c9a4be6ad650d86a4884a739cb2ada9@imap.yoafrica.com> <20090321130055.GA5782@vacation.karoshi.com.> Message-ID: bmanning at vacation.karoshi.com writes: > or - the more modern approach is to let the node (w/ proper authorization) > do a secure dynamic update of the revserse map - so the forward and reverse > delegations match. ... a -VERY- useful technique. I have a question. Is this an abuse problem? some ISPs require their domain to be in the rdns in an effort to herd abuse reports to the correct org. Is this generally considered useless? Is it generally considered OK to hand relatively untrusted users the keys to their own rdns? (I'm forcing my own customers to have a rdns of something.xen.prgmr.com for several months, Much to the chagrin of many presumably innocent and legitimate customers. ) From nenolod at systeminplace.net Sat Mar 28 02:39:00 2009 From: nenolod at systeminplace.net (William Pitcock) Date: Sat, 28 Mar 2009 02:39:00 -0500 Subject: REVERSE DNS Practices. In-Reply-To: References: <20090321103230.24415.qmail@simone.iecc.com> <7c9a4be6ad650d86a4884a739cb2ada9@imap.yoafrica.com> <20090321130055.GA5782@vacation.karoshi.com.> Message-ID: <1238225940.4420.96.camel@petrie> On Sat, 2009-03-28 at 03:12 -0400, Luke S Crawford wrote: > bmanning at vacation.karoshi.com writes: > > or - the more modern approach is to let the node (w/ proper authorization) > > do a secure dynamic update of the revserse map - so the forward and reverse > > delegations match. ... a -VERY- useful technique. > > I have a question. Is this an abuse problem? some ISPs require their domain > to be in the rdns in an effort to herd abuse reports to the correct org. > Is this generally considered useless? Is it generally considered OK to > hand relatively untrusted users the keys to their own rdns? > > (I'm forcing my own customers to have a rdns of something.xen.prgmr.com > for several months, Much to the chagrin of many presumably innocent and > legitimate customers. ) We allow RDNS controls to RapidXen customers since January 2009. It seems to be ok. We do have the ability to disable RDNS access to specific users if we feel it is being abused, however. -- William Pitcock SystemInPlace - Simple Hosting Solutions 1-866-519-6149 From berni at birkenwald.de Sat Mar 28 09:50:48 2009 From: berni at birkenwald.de (Bernhard Schmidt) Date: Sat, 28 Mar 2009 14:50:48 +0000 (UTC) Subject: Google Over IPV6 References: <00d601c9aed6$2fc517d0$8f4f4770$@edu> <1238158743.17980.10.camel@daniel.office.bit.nl> <317578510903270854q313747d8uf48f725044754d5e@mail.gmail.com> Message-ID: Athanasios Douitsis wrote: > Heard that they are somewhat picky about who they AAAA-enable. Our campus > has had native IPv6 everywhere and upwards all the way to Geant for many > years. We are thinking of applying in the hopes that it will boost IPv6 > usage. Did you have any trouble getting them to IPv6-enable you? Anyone > from Google in the list with any informative comment? We have one hop in between (the german NREN), haven't had any issues getting it enabled. bschmidt at lxbsc01:~$ traceroute6 -q1 www.google.com traceroute to www.google.com (2001:4860:a005::68) from 2001:4ca0:0:f000:211:43ff:fe7e:3a76, port 33434, from port 38962, 30 hops max, 60 byte packets 1 vl-23.csr1-2wr.lrz-muenchen.de (2001:4ca0:0:f000::1) 0.612 ms 2 xr-gar1-te1-3-108.x-win.dfn.de (2001:638:c:a003::1) 0.429 ms 3 zr-fra1-te0-7-0-1.x-win.dfn.de (2001:638:c:c043::2) 8.273 ms 4 de-cix20.net.google.com (2001:7f8::3b41:0:1) 8.202 ms 5 2001:4860::34 (2001:4860::34) 20.122 ms 6 2001:4860:a005::68 (2001:4860:a005::68) 20.691 ms If you are only connected to GEANT your mileage will vary, as GEANT doesn't peer themselves there will be at least one additional hop in between (GBLX most likely). I think they want a decent path and a usable backup path, not sure whether Telia (the second Geant transit) is ready yet. I'd suggest you just try to contact them. Bernhard From tt_745 at yahoo.co.uk Sat Mar 28 12:13:54 2009 From: tt_745 at yahoo.co.uk (tt tt) Date: Sat, 28 Mar 2009 17:13:54 +0000 (GMT) Subject: iBGP Scaling Message-ID: <450499.97499.qm@web26702.mail.ukl.yahoo.com> Hi List, We are looking to move our non infrastructure routes into iBGP to help with our IGP scalability (OSPF). We already run full BGP tables on our core where we connect to multiple upstream and downstream customers. Most of our aggregation and edge routers cannot hold full tables and it's certainly not possible to upgrade them. Is there any reason why we shouldn't filter iBGP routes between our core and aggregation layers (we plan to use route reflectors) or should we be look at using a private AS number per POP? Thanks Dave From kris.foster at gmail.com Fri Mar 27 18:35:31 2009 From: kris.foster at gmail.com (kris foster) Date: Fri, 27 Mar 2009 16:35:31 -0700 Subject: [NANOG-announce] VERP now active on all NANOG mailing lists Message-ID: Hi everyone All NANOG mailing lists were updated to use VERP (variable envelope return paths) at the beginning of the week. This will aid in bounce detection and help identify the subscriber. A more detailed description of VERP can be found here: http://wiki.list.org/display/DOC/So+what+is+this+VERP+stuff With this change some headers have changed. Depending on how you are performing your filtering this may or may not affect you. The header changes are: Old Return-Path: LISTNAME-bounces at nanog.org New Return-Path: LISTNAME-bounces+USERID=DOMAIN at nanog.org Old Errors-To: : LISTNAME-bounces at nanog.org New Return-Path: LISTNAME-bounces+USERID=DOMAIN at nanog.org I hope that this change does not cause any serious issues for you. The mailing list admins are always reachable at admins at nanog.org if you have any technical questions. Thanks! Kris Foster MLC Chair _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce From cgucker at onesc.net Sat Mar 28 15:41:25 2009 From: cgucker at onesc.net (Charles Gucker) Date: Sat, 28 Mar 2009 16:41:25 -0400 Subject: iBGP Scaling In-Reply-To: <450499.97499.qm@web26702.mail.ukl.yahoo.com> References: <450499.97499.qm@web26702.mail.ukl.yahoo.com> Message-ID: On Sat, Mar 28, 2009 at 1:13 PM, tt tt wrote: > > Hi List, > > We are looking to move our non infrastructure routes into iBGP to help with our IGP scalability (OSPF). ?We already run full BGP tables on our core where we connect to multiple upstream and downstream customers. ?Most of our aggregation and edge routers cannot hold full tables and it's certainly not possible to upgrade them. Is there any reason why we shouldn't filter iBGP routes between our core and aggregation layers (we plan to use route reflectors) or should we be look at using a private AS number per POP? Dave, From past experiences, you would be better off by only keeping directly connected networks (as in the netblocks/routes used for the interconnections between your routers, both internal an external). Most should be /30's or the like unless you aggregate the address space between stub areas and area 0). After that, you should tag (via BGP Communities) externally learned routes (mainly from Transit and Peers) and suppress those routes going out to your sub-par aggregation routers. Keep in mind, when you filter these routes you will have to pass a default route, either via iBGP or via your IGP (as the one exception). Also, since you are doing this via BGP Communities when additional routes are learned from your external peers, those routes would not be passed onto your aggregation routers. charles From isabeldias1 at yahoo.com Sat Mar 28 16:43:20 2009 From: isabeldias1 at yahoo.com (isabel dias) Date: Sat, 28 Mar 2009 14:43:20 -0700 (PDT) Subject: iBGP Scaling In-Reply-To: <450499.97499.qm@web26702.mail.ukl.yahoo.com> Message-ID: <389367.98195.qm@web52603.mail.re2.yahoo.com> Dave, Your netblock might be a standard /19 or just a modest /30 :-) or you are just deploying IPv6 and therefore applied for one of the most recent RIPE assigments. Do you have different AS private/public numbers running on your network? filtering IGP routes ....part pf the OSPF design would be to find out how many areas you need to have LSA types ...or just one area O all part of your routing policy or LCR policy in place. Or just go for ISIS ....and then you have to think about L2/L1 bounderies. Can you be more specific on the question? .//ID --- On Sat, 3/28/09, tt tt wrote: > From: tt tt > Subject: iBGP Scaling > To: nanog at nanog.org > Date: Saturday, March 28, 2009, 6:13 PM > Hi List, > > We are looking to move our non infrastructure routes into > iBGP to help with our IGP scalability (OSPF). We already > run full BGP tables on our core where we connect to multiple > upstream and downstream customers. Most of our aggregation > and edge routers cannot hold full tables and it's > certainly not possible to upgrade them. Is there any reason > why we shouldn't filter iBGP routes between our core and > aggregation layers (we plan to use route reflectors) or > should we be look at using a private AS number per POP? > > Thanks > > Dave From j at arpa.com Sun Mar 29 02:43:51 2009 From: j at arpa.com (jamie rishaw) Date: Sun, 29 Mar 2009 02:43:51 -0500 Subject: Request for data : Earth Hour - traffic stats [28 March 2009 20:30-21:30 local] Message-ID: Ninjas, I'm compiling some data re this year's "Earth Hour"[1] . For those not in the know, or those that dismissed it, "Earth Hour" is something the World Wildlife Fund cooked up, suggesting that the world "turn off" all non-essential electrical devices, to demonstrate some global-warming hypothesis. I'm looking for data - either compiled or raw - of activity between 8:30 (20:30) and 9:30 (21:30) "local" time. Power usage (and comparisons against previous weeks if available) and probably easier to push out - bandwidth info (and, again, comparisons against previous 2030-2130-saturday-night data). All data will be anonymized. Sources, if you send from $work email, will not be included in any summarizations. I think this will turn out to be some rather interesting info. I'll post findings to nanog, of course, or at least, appropriate urls and such. TIA, -jamie [1] http://en.wikipedia.org/wiki/Earth_Hour | http://www.earthhour.org/about/ -- Jamie Rishaw // .com.arpa at j <- reverse it. ish. [Impressive C-level Title Here], arpa / arpa labs From sethm at rollernet.us Sun Mar 29 03:06:04 2009 From: sethm at rollernet.us (Seth Mattinen) Date: Sun, 29 Mar 2009 01:06:04 -0700 Subject: Request for data : Earth Hour - traffic stats [28 March 2009 20:30-21:30 local] In-Reply-To: References: Message-ID: <49CF2BEC.3020607@rollernet.us> jamie rishaw wrote: > Ninjas, > > I'm compiling some data re this year's "Earth Hour"[1] . > > For those not in the know, or those that dismissed it, "Earth Hour" is > something the World Wildlife Fund cooked up, suggesting that the world "turn > off" all non-essential electrical devices, to demonstrate some > global-warming hypothesis. > > I'm looking for data - either compiled or raw - of activity between 8:30 > (20:30) and 9:30 (21:30) "local" time. Power usage (and comparisons against > previous weeks if available) and probably easier to push out - bandwidth > info (and, again, comparisons against previous 2030-2130-saturday-night > data). > > All data will be anonymized. Sources, if you send from $work email, will > not be included in any summarizations. > > I think this will turn out to be some rather interesting info. I'll post > findings to nanog, of course, or at least, appropriate urls and such. > I say we all run "off the grid" on generator power for earth hour. (At least that's what I'm saying because it was coincidentally my regular automatic exercise time with load transfer.) ~Seth From ken.gilmour at gmail.com Sun Mar 29 09:55:59 2009 From: ken.gilmour at gmail.com (Ken Gilmour) Date: Sun, 29 Mar 2009 08:55:59 -0600 Subject: Fiber cut on Irish Sea Message-ID: <5b6f80200903290755t2f0e4ff2m6c805aa93854e4ec@mail.gmail.com> Hi There, Since we use a vendor of "the vendor" of two Irish sea submarine cables I am wondering if anyone has first hand information on the fiber cut this morning? Does anyone have a status update on what is happening? I am getting some Chinese whispers going on here. Thanks! Ken From nanog-post at rsuc.gweep.net Sun Mar 29 09:57:09 2009 From: nanog-post at rsuc.gweep.net (Joe Provo) Date: Sun, 29 Mar 2009 10:57:09 -0400 Subject: iBGP Scaling In-Reply-To: <450499.97499.qm@web26702.mail.ukl.yahoo.com> References: <450499.97499.qm@web26702.mail.ukl.yahoo.com> Message-ID: <20090329145709.GA73830@gweep.net> On Sat, Mar 28, 2009 at 05:13:54PM +0000, tt tt wrote: > > Hi List, > > We are looking to move our non infrastructure routes into iBGP > to help with our IGP scalability (OSPF). We already run full BGP > tables on our core where we connect to multiple upstream and > downstream customers. Most of our aggregation and edge routers > cannot hold full tables and it's certainly not possible to upgrade > them. Is there any reason why we shouldn't filter iBGP routes between > our core and aggregation layers (we plan to use route reflectors) > or should we be look at using a private AS number per POP? Dave, This isn't an either/or. If you are memory-starved then even with a confederation model you'd need to be filtering or summarizing at the core/aggregation boundary. The decision axis there has to do with the number of routers, fluidity VS rigidity of your core/agg relationships, restrictions or capabilities of your equipment, etc. The only reason not to limit the aggregation-heard routes in your situation is if there are downstream customers (or internal servers/ services) which need the data. For manageability, follow cgucker's advice and tag everything with various communities to describe them: customer/peer/transit, your transit's customer VS truly remote, internal pop heard, geographic region, et al. Based upon a good set of tags, it will be easy to see what data can be reduced from your memory-starved sites with a limited pathway to the rest of your net. Cheers, Joe -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE From isabeldias1 at yahoo.com Sun Mar 29 10:02:52 2009 From: isabeldias1 at yahoo.com (isabel dias) Date: Sun, 29 Mar 2009 08:02:52 -0700 (PDT) Subject: Fiber cut on Irish Sea In-Reply-To: <5b6f80200903290755t2f0e4ff2m6c805aa93854e4ec@mail.gmail.com> Message-ID: <930756.91415.qm@web52609.mail.re2.yahoo.com> affecting whom? and who's network? --- On Sun, 3/29/09, Ken Gilmour wrote: > From: Ken Gilmour > Subject: Fiber cut on Irish Sea > To: nanog at nanog.org > Date: Sunday, March 29, 2009, 4:55 PM > Hi There, > > Since we use a vendor of "the vendor" of two > Irish sea submarine > cables I am wondering if anyone has first hand information > on the > fiber cut this morning? Does anyone have a status update on > what is > happening? I am getting some Chinese whispers going on > here. > > Thanks! > > Ken From ken.gilmour at gmail.com Sun Mar 29 10:04:10 2009 From: ken.gilmour at gmail.com (Ken Gilmour) Date: Sun, 29 Mar 2009 09:04:10 -0600 Subject: Fiber cut on Irish Sea In-Reply-To: <930756.91415.qm@web52609.mail.re2.yahoo.com> References: <5b6f80200903290755t2f0e4ff2m6c805aa93854e4ec@mail.gmail.com> <930756.91415.qm@web52609.mail.re2.yahoo.com> Message-ID: <5b6f80200903290804v803ba7eh225b975333ddc350@mail.gmail.com> We received the report from Packet Exchange, however they are not the owners of the cable. I assume they just rent spectrum. 2009/3/29 isabel dias : > > affecting whom? and who's network? > > > --- On Sun, 3/29/09, Ken Gilmour wrote: > >> From: Ken Gilmour >> Subject: Fiber cut on Irish Sea >> To: nanog at nanog.org >> Date: Sunday, March 29, 2009, 4:55 PM >> Hi There, >> >> Since we use a vendor of "the vendor" of two >> Irish sea submarine >> cables I am wondering if anyone has first hand information >> on the >> fiber cut this morning? Does anyone have a status update on >> what is >> happening? I am getting some Chinese whispers going on >> here. >> >> Thanks! >> >> Ken > > > > From isabeldias1 at yahoo.com Sun Mar 29 10:11:24 2009 From: isabeldias1 at yahoo.com (isabel dias) Date: Sun, 29 Mar 2009 08:11:24 -0700 (PDT) Subject: Fiber cut on Irish Sea In-Reply-To: <5b6f80200903290804v803ba7eh225b975333ddc350@mail.gmail.com> Message-ID: <416212.45432.qm@web52608.mail.re2.yahoo.com> Are you able to provide historical information on the incident/outgae you have experienced? Are you able to provide an egress and/or igress traffic coming in and out of your network to make sure your traffic was crossing that transmission path? I guess you must have visibility of planned work or outage notification if anything happen and you were directly affected- YES/NO? --- On Sun, 3/29/09, Ken Gilmour wrote: > From: Ken Gilmour > Subject: Re: Fiber cut on Irish Sea > To: isabeldias1 at yahoo.com > Cc: nanog at nanog.org > Date: Sunday, March 29, 2009, 5:04 PM > We received the report from Packet Exchange, however they > are not the > owners of the cable. I assume they just rent spectrum. > > 2009/3/29 isabel dias : > > > > affecting whom? and who's network? > > > > > > --- On Sun, 3/29/09, Ken Gilmour > wrote: > > > >> From: Ken Gilmour > >> Subject: Fiber cut on Irish Sea > >> To: nanog at nanog.org > >> Date: Sunday, March 29, 2009, 4:55 PM > >> Hi There, > >> > >> Since we use a vendor of "the vendor" of > two > >> Irish sea submarine > >> cables I am wondering if anyone has first hand > information > >> on the > >> fiber cut this morning? Does anyone have a status > update on > >> what is > >> happening? I am getting some Chinese whispers > going on > >> here. > >> > >> Thanks! > >> > >> Ken > > > > > > > > From ken.gilmour at gmail.com Sun Mar 29 10:42:42 2009 From: ken.gilmour at gmail.com (Ken Gilmour) Date: Sun, 29 Mar 2009 09:42:42 -0600 Subject: Fiber cut on Irish Sea In-Reply-To: <416212.45432.qm@web52608.mail.re2.yahoo.com> References: <5b6f80200903290804v803ba7eh225b975333ddc350@mail.gmail.com> <416212.45432.qm@web52608.mail.re2.yahoo.com> Message-ID: <5b6f80200903290842h3e55dd4fo329849812a935a5e@mail.gmail.com> Hi, This has been fixed now. I will follow up directly with PE for an RFO. Thanks for your help on and off list. Regards, Ken 2009/3/29 isabel dias : > > Are you able to provide historical information on the incident/outgae you have experienced? > > Are you able to provide an egress and/or igress traffic coming in and out of your network to make sure your traffic was crossing that transmission path? > > I guess you must have visibility of planned work or outage notification if anything happen and you were directly affected- YES/NO? > > > > --- On Sun, 3/29/09, Ken Gilmour wrote: > >> From: Ken Gilmour >> Subject: Re: Fiber cut on Irish Sea >> To: isabeldias1 at yahoo.com >> Cc: nanog at nanog.org >> Date: Sunday, March 29, 2009, 5:04 PM >> We received the report from Packet Exchange, however they >> are not the >> owners of the cable. I assume they just rent spectrum. >> >> 2009/3/29 isabel dias : >> > >> > affecting whom? and who's network? >> > >> > >> > --- On Sun, 3/29/09, Ken Gilmour >> wrote: >> > >> >> From: Ken Gilmour >> >> Subject: Fiber cut on Irish Sea >> >> To: nanog at nanog.org >> >> Date: Sunday, March 29, 2009, 4:55 PM >> >> Hi There, >> >> >> >> Since we use a vendor of "the vendor" of >> two >> >> Irish sea submarine >> >> cables I am wondering if anyone has first hand >> information >> >> on the >> >> fiber cut this morning? Does anyone have a status >> update on >> >> what is >> >> happening? I am getting some Chinese whispers >> going on >> >> here. >> >> >> >> Thanks! >> >> >> >> Ken >> > >> > >> > >> > > > > > From streiner at cluebyfour.org Sun Mar 29 11:44:13 2009 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Sun, 29 Mar 2009 12:44:13 -0400 (EDT) Subject: Fiber cut on Irish Sea In-Reply-To: <5b6f80200903290842h3e55dd4fo329849812a935a5e@mail.gmail.com> References: <5b6f80200903290804v803ba7eh225b975333ddc350@mail.gmail.com> <416212.45432.qm@web52608.mail.re2.yahoo.com> <5b6f80200903290842h3e55dd4fo329849812a935a5e@mail.gmail.com> Message-ID: On Sun, 29 Mar 2009, Ken Gilmour wrote: > This has been fixed now. I will follow up directly with PE for an RFO. If it was repaired that quickly it was probably not a cut or a 'wet' failure but maybe something like an electronics failure in a landing station or something similar. jms From ken.gilmour at gmail.com Sun Mar 29 12:10:54 2009 From: ken.gilmour at gmail.com (Ken Gilmour) Date: Sun, 29 Mar 2009 11:10:54 -0600 Subject: Fiber cut on Irish Sea In-Reply-To: References: <5b6f80200903290804v803ba7eh225b975333ddc350@mail.gmail.com> <416212.45432.qm@web52608.mail.re2.yahoo.com> <5b6f80200903290842h3e55dd4fo329849812a935a5e@mail.gmail.com> Message-ID: <5b6f80200903291010t29630956tdd244a9daaa02350@mail.gmail.com> 2009/3/29 Justin M. Streiner : > On Sun, 29 Mar 2009, Ken Gilmour wrote: > >> This has been fixed now. I will follow up directly with PE for an RFO. > > If it was repaired that quickly it was probably not a cut or a 'wet' failure > but maybe something like an electronics failure in a landing station or > something similar. > > jms > Hi Justin, It happened at 8:00AM Irish time (which is about 2:00 AM My time) I didn't get in to the office and notice the mail until 6 hours after it happened (In Central America) so it took about 7 hours and 30 minutes to fix. PE also reported that the problem started at 8:00 AM on the 29th and was repaired at 9:05 (no AM or PM) on the 26th (yes, three days in the past). I don't think their timing procedure is functioning correctly. Regards, Ken From jbfixurpc at gmail.com Sun Mar 29 12:31:25 2009 From: jbfixurpc at gmail.com (Joe Blanchard) Date: Sun, 29 Mar 2009 13:31:25 -0400 Subject: Fiber cut on Irish Sea In-Reply-To: <5b6f80200903291010t29630956tdd244a9daaa02350@mail.gmail.com> Message-ID: <000e01c9b094$31cc70e0$0101a8c0@E520> >PE also reported that the problem started at 8:00 AM on the >29th and was repaired at 9:05 (no AM or PM) on the 26th (yes, >three days in the past) Hey!?!?!? Where'd they get a time machine! lol, j/k You mean 26th at 8am to the 29th 9:05 M-less? regards > -----Original Message----- > From: Ken Gilmour [mailto:ken.gilmour at gmail.com] > Sent: Sunday, March 29, 2009 1:11 PM > To: Justin M. Streiner > Cc: nanog at nanog.org > Subject: Re: Fiber cut on Irish Sea > > 2009/3/29 Justin M. Streiner : > > On Sun, 29 Mar 2009, Ken Gilmour wrote: > > > >> This has been fixed now. I will follow up directly with PE > for an RFO. > > > > If it was repaired that quickly it was probably not a cut > or a 'wet' > > failure but maybe something like an electronics failure in > a landing > > station or something similar. > > From ken.gilmour at gmail.com Sun Mar 29 12:34:49 2009 From: ken.gilmour at gmail.com (Ken Gilmour) Date: Sun, 29 Mar 2009 11:34:49 -0600 Subject: Fiber cut on Irish Sea In-Reply-To: <000e01c9b094$31cc70e0$0101a8c0@E520> References: <5b6f80200903291010t29630956tdd244a9daaa02350@mail.gmail.com> <000e01c9b094$31cc70e0$0101a8c0@E520> Message-ID: <5b6f80200903291034w475301ek4a984181f54bc27b@mail.gmail.com> 2009/3/29 Joe Blanchard : > Hey!?!?!? Where'd they get a time machine! lol, j/k You mean 26th at 8am > to the 29th 9:05 M-less? I just received the corrected time: 02:58 BST to 09:03 BST. Regards, Ken From tony at swalter.com Sun Mar 29 12:54:41 2009 From: tony at swalter.com (Tony Patti) Date: Sun, 29 Mar 2009 13:54:41 -0400 Subject: cnn.com - Vast Spy System Loots Computers in 103 Countries Message-ID: <04eb01c9b097$6f6e7530$4e4b5f90$@com> I hope that today's cnn.com article cited below meets the criteria of sufficient "Internet operational and technical issues" pursuant to NANOG AUP criteria #1 http://www.nytimes.com/2009/03/29/technology/29spy.html?_r=2&hp Tony Patti CIO S. Walter Packaging Corp. tony at swalter.com March 29, 2009 Vast Spy System Loots Computers in 103 Countries By JOHN MARKOFF TORONTO - A vast electronic spying operation has infiltrated computers and has stolen documents from hundreds of government and private offices around the world, including those of the Dalai Lama, Canadian researchers have concluded. In a report to be issued this weekend, the researchers said that the system was being controlled from computers based almost exclusively in China, but that they could not say conclusively that the Chinese government was involved. The researchers, who are based at the Munk Center for International Studies at the University of Toronto, had been asked by the office of the Dalai Lama, the exiled Tibetan leader whom China regularly denounces, to examine its computers for signs of malicious software, or malware. Their sleuthing opened a window into a broader operation that, in less than two years, has infiltrated at least 1,295 computers in 103 countries, including many belonging to embassies, foreign ministries and other government offices, as well as the Dalai Lama's Tibetan exile centers in India, Brussels, London and New York. The researchers, who have a record of detecting computer espionage, said they believed that in addition to the spying on the Dalai Lama, the system, which they called GhostNet, was focused on the governments of South Asian and Southeast Asian countries. Intelligence analysts say many governments, including those of China, Russia and the United States, and other parties use sophisticated computer programs to covertly gather information. The newly reported spying operation is by far the largest to come to light in terms of countries affected. This is also believed to be the first time researchers have been able to expose the workings of a computer system used in an intrusion of this magnitude. Still going strong, the operation continues to invade and monitor more than a dozen new computers a week, the researchers said in their report, "Tracking 'GhostNet': Investigating a Cyber Espionage Network." They said they had found no evidence that United States government offices had been infiltrated, although a NATO computer was monitored by the spies for half a day and computers of the Indian Embassy in Washington were infiltrated. The malware is remarkable both for its sweep - in computer jargon, it has not been merely "phishing" for random consumers' information, but "whaling" for particular important targets - and for its Big Brother-style capacities. It can, for example, turn on the camera and audio-recording functions of an infected computer, enabling monitors to see and hear what goes on in a room. The investigators say they do not know if this facet has been employed. The researchers were able to monitor the commands given to infected computers and to see the names of documents retrieved by the spies, but in most cases the contents of the stolen files have not been determined. Working with the Tibetans, however, the researchers found that specific correspondence had been stolen and that the intruders had gained control of the electronic mail server computers of the Dalai Lama's organization. The electronic spy game has had at least some real-world impact, they said. For example, they said, after an e-mail invitation was sent by the Dalai Lama's office to a foreign diplomat, the Chinese government made a call to the diplomat discouraging a visit. And a woman working for a group making Internet contacts between Tibetan exiles and Chinese citizens was stopped by Chinese intelligence officers on her way back to Tibet, shown transcripts of her online conversations and warned to stop her political activities. The Toronto researchers said they had notified international law enforcement agencies of the spying operation, which in their view exposed basic shortcomings in the legal structure of cyberspace. The F.B.I. declined to comment on the operation. Although the Canadian researchers said that most of the computers behind the spying were in China, they cautioned against concluding that China's government was involved. The spying could be a nonstate, for-profit operation, for example, or one run by private citizens in China known as "patriotic hackers." "We're a bit more careful about it, knowing the nuance of what happens in the subterranean realms," said Ronald J. Deibert, a member of the research group and an associate professor of political science at Munk. "This could well be the C.I.A. or the Russians. It's a murky realm that we're lifting the lid on." A spokesman for the Chinese Consulate in New York dismissed the idea that China was involved. "These are old stories and they are nonsense," the spokesman, Wenqi Gao, said. "The Chinese government is opposed to and strictly forbids any cybercrime." The Toronto researchers, who allowed a reporter for The New York Times to review the spies' digital tracks, are publishing their findings in Information Warfare Monitor, an online publication associated with the Munk Center. At the same time, two computer researchers at Cambridge University in Britain who worked on the part of the investigation related to the Tibetans, are releasing an independent report. They do fault China, and they warned that other hackers could adopt the tactics used in the malware operation. "What Chinese spooks did in 2008, Russian crooks will do in 2010 and even low-budget criminals from less developed countries will follow in due course," the Cambridge researchers, Shishir Nagaraja and Ross Anderson, wrote in their report, "The Snooping Dragon: Social Malware Surveillance of the Tibetan Movement." In any case, it was suspicions of Chinese interference that led to the discovery of the spy operation. Last summer, the office of the Dalai Lama invited two specialists to India to audit computers used by the Dalai Lama's organization. The specialists, Greg Walton, the editor of Information Warfare Monitor, and Mr. Nagaraja, a network security expert, found that the computers had indeed been infected and that intruders had stolen files from personal computers serving several Tibetan exile groups. Back in Toronto, Mr. Walton shared data with colleagues at the Munk Center's computer lab. One of them was Nart Villeneuve, 34, a graduate student and self-taught "white hat" hacker with dazzling technical skills. Last year, Mr. Villeneuve linked the Chinese version of the Skype communications service to a Chinese government operation that was systematically eavesdropping on users' instant-messaging sessions. Early this month, Mr. Villeneuve noticed an odd string of 22 characters embedded in files created by the malicious software and searched for it with Google. It led him to a group of computers on Hainan Island, off China, and to a Web site that would prove to be critically important. In a puzzling security lapse, the Web page that Mr. Villeneuve found was not protected by a password, while much of the rest of the system uses encryption. Mr. Villeneuve and his colleagues figured out how the operation worked by commanding it to infect a system in their computer lab in Toronto. On March 12, the spies took their own bait. Mr. Villeneuve watched a brief series of commands flicker on his computer screen as someone - presumably in China - rummaged through the files. Finding nothing of interest, the intruder soon disappeared. Through trial and error, the researchers learned to use the system's Chinese-language "dashboard" - a control panel reachable with a standard Web browser - by which one could manipulate the more than 1,200 computers worldwide that had by then been infected. Infection happens two ways. In one method, a user's clicking on a document attached to an e-mail message lets the system covertly install software deep in the target operating system. Alternatively, a user clicks on a Web link in an e-mail message and is taken directly to a "poisoned" Web site. The researchers said they avoided breaking any laws during three weeks of monitoring and extensively experimenting with the system's unprotected software control panel. They provided, among other information, a log of compromised computers dating to May 22, 2007. They found that three of the four control servers were in different provinces in China - Hainan, Guangdong and Sichuan - while the fourth was discovered to be at a Web-hosting company based in Southern California. Beyond that, said Rafal A. Rohozinski, one of the investigators, "attribution is difficult because there is no agreed upon international legal framework for being able to pursue investigations down to their logical conclusion, which is highly local." From isabeldias1 at yahoo.com Sun Mar 29 17:16:23 2009 From: isabeldias1 at yahoo.com (isabel dias) Date: Sun, 29 Mar 2009 15:16:23 -0700 (PDT) Subject: Fiber cut on Irish Sea In-Reply-To: <373173782-1238340887-cardhu_decombobulator_blackberry.rim.net-415882138-@bxe1114.bisx.prod.on.blackberry> Message-ID: <644838.46768.qm@web52602.mail.re2.yahoo.com> ken, who's fiber on the ground was it after all? Roderick Beck wrote: > Probably Global Crossing. > > A very strong wager. > > -R. > ------Original Message------ > From: Ken Gilmour > To: isabeldias1 at yahoo.com > Cc: nanog at nanog.org > Subject: Re: Fiber cut on Irish Sea > Sent: 29 Mar 2009 16:04 > > We received the report from Packet Exchange, however they are not the > owners of the cable. I assume they just rent spectrum. > > 2009/3/29 isabel dias : >> >> affecting whom? and who's network? >> >> >> --- On Sun, 3/29/09, Ken Gilmour wrote: >> >>> From: Ken Gilmour >>> Subject: Fiber cut on Irish Sea >>> To: nanog at nanog.org >>> Date: Sunday, March 29, 2009, 4:55 PM >>> Hi There, >>> >>> Since we use a vendor of "the vendor" of two >>> Irish sea submarine >>> cables I am wondering if anyone has first hand information >>> on the >>> fiber cut this morning? Does anyone have a status update on >>> what is >>> happening? I am getting some Chinese whispers going on >>> here. >>> >>> Thanks! >>> >>> Ken >> >> >> >> > > > > Sent wirelessly via BlackBerry from T-Mobile. From ken.gilmour at gmail.com Sun Mar 29 17:19:05 2009 From: ken.gilmour at gmail.com (Ken Gilmour) Date: Sun, 29 Mar 2009 16:19:05 -0600 Subject: Fiber cut on Irish Sea In-Reply-To: <644838.46768.qm@web52602.mail.re2.yahoo.com> References: <373173782-1238340887-cardhu_decombobulator_blackberry.rim.net-415882138-@bxe1114.bisx.prod.on.blackberry> <644838.46768.qm@web52602.mail.re2.yahoo.com> Message-ID: <5b6f80200903291519s1483732at8130a99ba239e81f@mail.gmail.com> Hi Isabel, It hasn't been confirmed to me yet but some people have mentioned that it is most likely to belong to Global Crossing. Regards, Ken 2009/3/29 isabel dias : > > ken, who's fiber on the ground was it after all? > > Roderick Beck wrote: >> Probably Global Crossing. >> >> A very strong wager. >> >> -R. >> ------Original Message------ >> From: Ken Gilmour >> To: isabeldias1 at yahoo.com >> Cc: nanog at nanog.org >> Subject: Re: Fiber cut on Irish Sea >> Sent: 29 Mar 2009 16:04 >> >> We received the report from Packet Exchange, however they are not the >> owners of the cable. I assume they just rent spectrum. >> >> 2009/3/29 isabel dias : >>> >>> affecting whom? and who's network? >>> >>> >>> --- On Sun, 3/29/09, Ken Gilmour wrote: >>> >>>> From: Ken Gilmour >>>> Subject: Fiber cut on Irish Sea >>>> To: nanog at nanog.org >>>> Date: Sunday, March 29, 2009, 4:55 PM >>>> Hi There, >>>> >>>> Since we use a vendor of "the vendor" of two >>>> Irish sea submarine >>>> cables I am wondering if anyone has first hand information >>>> on the >>>> fiber cut this morning? Does anyone have a status update on >>>> what is >>>> happening? I am getting some Chinese whispers going on >>>> here. >>>> >>>> Thanks! >>>> >>>> Ken >>> >>> >>> >>> >> >> >> >> Sent wirelessly via BlackBerry from T-Mobile. > > > > > From jbfixurpc at gmail.com Sun Mar 29 18:43:15 2009 From: jbfixurpc at gmail.com (Joe Blanchard) Date: Sun, 29 Mar 2009 19:43:15 -0400 Subject: The Confiker Virus. In-Reply-To: <5b6f80200903291519s1483732at8130a99ba239e81f@mail.gmail.com> Message-ID: <002d01c9b0c8$2382eb20$0101a8c0@E520> Anyone have a copy of this? Would like to analyze it and understand its propagation. Thanks -Joe From bgreene at senki.org Sun Mar 29 18:47:56 2009 From: bgreene at senki.org (Barry Raveendran Greene) Date: Sun, 29 Mar 2009 16:47:56 -0700 Subject: The Confiker Virus. In-Reply-To: <002d01c9b0c8$2382eb20$0101a8c0@E520> References: <5b6f80200903291519s1483732at8130a99ba239e81f@mail.gmail.com> <002d01c9b0c8$2382eb20$0101a8c0@E520> Message-ID: <03AD93D590E44DCA986E2EAD7C6BD50B@jnpr.net> Visit the authority: http://www.confickerworkinggroup.org/wiki/ > -----Original Message----- > From: Joe Blanchard [mailto:jbfixurpc at gmail.com] > Sent: Sunday, March 29, 2009 4:43 PM > To: nanog at nanog.org > Subject: The Confiker Virus. > > > Anyone have a copy of this? Would like to analyze it and > understand its propagation. > > Thanks > -Joe > > > From mhuff at ox.com Sun Mar 29 18:54:54 2009 From: mhuff at ox.com (Matthew Huff) Date: Sun, 29 Mar 2009 19:54:54 -0400 Subject: The Confiker Virus. In-Reply-To: <002d01c9b0c8$2382eb20$0101a8c0@E520> References: <5b6f80200903291519s1483732at8130a99ba239e81f@mail.gmail.com> <002d01c9b0c8$2382eb20$0101a8c0@E520> Message-ID: <483E6B0272B0284BA86D7596C40D29F9BBBD6DE3B5@PUR-EXCH07.ox.com> SRI has a detailed analysis of conflicker at http://mtc.sri.com/Conficker/ ---- Matthew Huff?????? | One Manhattanville Rd OTA Management LLC | Purchase, NY 10577 http://www.ox.com? | Phone: 914-460-4039 aim: matthewbhuff? | Fax:?? 914-460-4139 -----Original Message----- From: Joe Blanchard [mailto:jbfixurpc at gmail.com] Sent: Sunday, March 29, 2009 7:43 PM To: nanog at nanog.org Subject: The Confiker Virus. Anyone have a copy of this? Would like to analyze it and understand its propagation. Thanks -Joe From jbfixurpc at gmail.com Sun Mar 29 19:04:02 2009 From: jbfixurpc at gmail.com (Joe Blanchard) Date: Sun, 29 Mar 2009 20:04:02 -0400 Subject: The Confiker Virus. In-Reply-To: <03AD93D590E44DCA986E2EAD7C6BD50B@jnpr.net> Message-ID: <002f01c9b0cb$0b0f6de0$0101a8c0@E520> Thanks, the only thing is that these, like most, websites are very vague about the mechanics behind the infiltration. Thus the reason why I asked about finding some source code/example code. Its pretty nice that these folks (symantics/trend) offer free help regarding these items, but the facts (TCP/UDP ports, DNS poisioning methods) are buried doesn't help much. Perhaps I am missing something though. Regards > -----Original Message----- > From: Barry Raveendran Greene [mailto:bgreene at senki.org] > Sent: Sunday, March 29, 2009 7:48 PM > To: 'Joe Blanchard'; nanog at nanog.org > Subject: RE: The Confiker Virus. From fergdawgster at gmail.com Sun Mar 29 19:11:12 2009 From: fergdawgster at gmail.com (Paul Ferguson) Date: Sun, 29 Mar 2009 17:11:12 -0700 Subject: The Confiker Virus. In-Reply-To: <483E6B0272B0284BA86D7596C40D29F9BBBD6DE3B5@PUR-EXCH07.ox.com> References: <5b6f80200903291519s1483732at8130a99ba239e81f@mail.gmail.com> <002d01c9b0c8$2382eb20$0101a8c0@E520> <483E6B0272B0284BA86D7596C40D29F9BBBD6DE3B5@PUR-EXCH07.ox.com> Message-ID: <6cd462c00903291711p1fe36530p1ed066c28a488eca@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sun, Mar 29, 2009 at 4:54 PM, Matthew Huff wrote: > SRI has a detailed analysis of conflicker at > http://mtc.sri.com/Conficker/ > The most relevant section the Conficker.C addendum -- this has been driving the April 1st hype. http://mtc.sri.com/Conficker/addendumC/index.html FYI, - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.3 (Build 5003) wj8DBQFJ0A4Uq1pz9mNUZTMRAlJbAJ9g8PgK+ttTz193mUTRzxhdN47QgQCdEASn hKy+B8H9BHprgaVpFKGIv0I= =RSKj -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/ From rgolodner at infratection.com Sun Mar 29 19:16:29 2009 From: rgolodner at infratection.com (Richard Golodner) Date: Sun, 29 Mar 2009 19:16:29 -0500 Subject: The Confiker Virus. In-Reply-To: <002f01c9b0cb$0b0f6de0$0101a8c0@E520> References: <03AD93D590E44DCA986E2EAD7C6BD50B@jnpr.net> <002f01c9b0cb$0b0f6de0$0101a8c0@E520> Message-ID: <000001c9b0cc$c6126100$52372300$@com> Joe said earlier today: > Thanks, the only thing is that these, like most, websites are very vague about the mechanics behind the infiltration Joe, the SRI report would be right up your alley as it is the most technical in its analysis of the variants A and B as well as an explanation of the algorithm it uses to determine domain names for future use of some kind. http://mtc.sri.com/Conficker/ Sincerely, Richard Golodner From jbfixurpc at gmail.com Sun Mar 29 22:43:47 2009 From: jbfixurpc at gmail.com (Joe Blanchard) Date: Sun, 29 Mar 2009 23:43:47 -0400 Subject: Oddly, this has been a complaint Message-ID: <003401c9b0e9$bdeec460$0101a8c0@E520> Not that I care one way or another, but since I've gotten 20+ complaints. going to www.whitehouse.org yields something else. I know I know, perhaps old news. Should I just redirect or is our DNS corrupt? Darn it Thanks in advance From smb at cs.columbia.edu Sun Mar 29 22:57:27 2009 From: smb at cs.columbia.edu (Steven M. Bellovin) Date: Sun, 29 Mar 2009 23:57:27 -0400 Subject: Oddly, this has been a complaint In-Reply-To: <003401c9b0e9$bdeec460$0101a8c0@E520> References: <003401c9b0e9$bdeec460$0101a8c0@E520> Message-ID: <20090329235727.36acb884@cs.columbia.edu> On Sun, 29 Mar 2009 23:43:47 -0400 "Joe Blanchard" wrote: > > > Not that I care one way or another, but since I've gotten 20+ > complaints. > > going to www.whitehouse.org yields something else. I know I know, > perhaps old news. > > Should I just redirect or is our DNS corrupt? > Should your users perhaps be going to whitehouse.gov? --Steve Bellovin, http://www.cs.columbia.edu/~smb From jlewis at lewis.org Sun Mar 29 23:02:57 2009 From: jlewis at lewis.org (Jon Lewis) Date: Mon, 30 Mar 2009 00:02:57 -0400 (EDT) Subject: Oddly, this has been a complaint In-Reply-To: <003401c9b0e9$bdeec460$0101a8c0@E520> References: <003401c9b0e9$bdeec460$0101a8c0@E520> Message-ID: On Sun, 29 Mar 2009, Joe Blanchard wrote: > Not that I care one way or another, but since I've gotten 20+ complaints. > > going to www.whitehouse.org yields something else. I know I know, perhaps > old news. > > Should I just redirect or is our DNS corrupt? There's something wrong with this reality. Maybe we can redirect that too. Domain Name:WHITEHOUSE.ORG Created On:05-Sep-1995 04:00:00 UTC Last Updated On:23-Jan-2006 19:17:13 UTC Expiration Date:04-Sep-2015 04:00:00 UTC Sponsoring Registrar:Network Solutions LLC (R63-LROR) Status:CLIENT TRANSFER PROHIBITED Registrant ID:23421300-NSI Registrant Name:Satire On-line Registrant Organization:Satire On-line Registrant Street1:245-M Mount Hermon Road, Suite 137 Registrant Street2: Registrant Street3: Registrant City:Scotts Valley Registrant State/Province:CA Registrant Postal Code:95066 Registrant Country:US Registrant Phone:+1.6502123765 Registrant Phone Ext.: Registrant FAX:+1.9999999999 Registrant FAX Ext.: Registrant Email:pace at ILLUMINATI.ORG Something tells me, this isn't the whitehouse your customers were looking for. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From jbfixurpc at gmail.com Sun Mar 29 23:04:08 2009 From: jbfixurpc at gmail.com (Joe Blanchard) Date: Mon, 30 Mar 2009 00:04:08 -0400 Subject: Oddly, this has been a complaint Message-ID: <003c01c9b0ec$950430a0$0101a8c0@E520> Opps my bad sorry for the static. gov/org I should have seen that. Sorry again. From jay at west.net Sun Mar 29 23:23:01 2009 From: jay at west.net (Jay Hennigan) Date: Sun, 29 Mar 2009 21:23:01 -0700 Subject: Oddly, this has been a complaint In-Reply-To: <003401c9b0e9$bdeec460$0101a8c0@E520> References: <003401c9b0e9$bdeec460$0101a8c0@E520> Message-ID: <49D04925.9070205@west.net> Joe Blanchard wrote: > > Not that I care one way or another, but since I've gotten 20+ complaints. > > going to www.whitehouse.org yields something else. I know I know, perhaps > old news. whitehouse.gov does not equal whitehouse.org . And some of us who have been around for a while can attest with some certainty that whitehouse.gov DEFINITELY doesn't equal whitehouse.com . :-) -- Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV From jlewis at lewis.org Sun Mar 29 23:27:55 2009 From: jlewis at lewis.org (Jon Lewis) Date: Mon, 30 Mar 2009 00:27:55 -0400 (EDT) Subject: Oddly, this has been a complaint In-Reply-To: <49D04925.9070205@west.net> References: <003401c9b0e9$bdeec460$0101a8c0@E520> <49D04925.9070205@west.net> Message-ID: On Sun, 29 Mar 2009, Jay Hennigan wrote: > And some of us who have been around for a while can attest with some > certainty that whitehouse.gov DEFINITELY doesn't equal whitehouse.com . :-) Oh I don't know...what about during the Clinton years? ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From j at arpa.com Mon Mar 30 00:33:20 2009 From: j at arpa.com (jamie rishaw) Date: Mon, 30 Mar 2009 00:33:20 -0500 Subject: Oddly, this has been a complaint In-Reply-To: <003401c9b0e9$bdeec460$0101a8c0@E520> References: <003401c9b0e9$bdeec460$0101a8c0@E520> Message-ID: whitehouse.org has had the same A record for quite some time, sharing the ip with a bunch of other .. interesting .. sites. It's been at 67.19.217.250 for years now. If your info matches that, there's no DNS issues to worry about. -j On Sun, Mar 29, 2009 at 10:43 PM, Joe Blanchard wrote: > > > Not that I care one way or another, but since I've gotten 20+ complaints. > > going to www.whitehouse.org yields something else. I know I know, perhaps > old news. > > Should I just redirect or is our DNS corrupt? > > Darn it > > Thanks in advance > > > -- Jamie Rishaw // .com.arpa at j <- reverse it. ish. [Impressive C-level Title Here], arpa / arpa labs From teun at moonblade.net Mon Mar 30 04:40:31 2009 From: teun at moonblade.net (Teun Vink) Date: Mon, 30 Mar 2009 11:40:31 +0200 Subject: Google Over IPV6 In-Reply-To: <016c01c9aeed$2245ed20$66d1c760$@edu> References: <00d601c9aed6$2fc517d0$8f4f4770$@edu> <1238158743.17980.10.camel@daniel.office.bit.nl> <49CCE8C0.9080707@Janoszka.pl> <016c01c9aeed$2245ed20$66d1c760$@edu> Message-ID: <1238406031.10265.37.camel@moridin.office.bit.nl.office.bit.nl> On Fri, 2009-03-27 at 11:03 -0400, Robert D. Scott wrote: > Their press would indicate that more than www is IPV6. > > When I posted my original note, I was not really looking for end user > feedback, but rather is anyone peering V6 with them on either a public > fabric or private peer. Any idea if they have native V6 transit, or are > tunneling, and to where. Yes, for example reader, maps, picasa and gmail have IPv6 enabled as well. Groups, youtube and orkut don't have IPv6 enabled, it seems. Funny thing to see is that IPv6 latency is lower than the IPv4 latency: --- www.l.google.com ping6 statistics --- 54 packets transmitted, 54 packets received, 0% packet loss round-trip min/avg/max/std-dev = 8.302/9.038/12.639/0.989 ms --- www.l.google.com ping statistics --- 57 packets transmitted, 57 packets received, 0% packet loss round-trip min/avg/max/stddev = 13.780/15.739/35.764/4.055 ms Regards, Teun From truman at suspicious.org Mon Mar 30 07:19:33 2009 From: truman at suspicious.org (Truman Boyes) Date: Mon, 30 Mar 2009 23:19:33 +1100 Subject: iBGP Scaling In-Reply-To: <450499.97499.qm@web26702.mail.ukl.yahoo.com> References: <450499.97499.qm@web26702.mail.ukl.yahoo.com> Message-ID: <7B9E2BD2-1E42-44D7-A356-EFFE9119D509@suspicious.org> Hi there, Interesting post. Couple things you touched on; firstly is your IGP having a scaling issue? I have seen networks with > 500 routers in area 0.0.0.0, however the LSDB was limited to links and loopbacks. Using route reflectors may help to some degree on memory, in that only the best route will be reflected to clients. If you are looking to do some things like MPLS IPVPNS or other TE stuff, you might want to stick with one AS / one IGP. It just makes things easier. If your routers can support MPLS VPNs, you may be able to leverage route target filtering on each PE device. If you are just memory starved and plan to continue with a standard Internet routing domain, I would look at tagging all routes on ingress and figuring out which routes can be summarized or filtered out on the border / aggregation routers. Kind regards, Truman On 29/03/2009, at 4:13 AM, tt tt wrote: > > Hi List, > > We are looking to move our non infrastructure routes into iBGP to > help with our IGP scalability (OSPF). We already run full BGP > tables on our core where we connect to multiple upstream and > downstream customers. Most of our aggregation and edge routers > cannot hold full tables and it's certainly not possible to upgrade > them. Is there any reason why we shouldn't filter iBGP routes > between our core and aggregation layers (we plan to use route > reflectors) or should we be look at using a private AS number per POP? > > Thanks > > Dave > > > > > From mastermind202 at gmail.com Mon Mar 30 07:42:49 2009 From: mastermind202 at gmail.com (mm_202) Date: Mon, 30 Mar 2009 08:42:49 -0400 Subject: Verizon fiber cut? Message-ID: <63de75710903300542o22376b2btb0aa152d35e8415f@mail.gmail.com> There seems to be a major fiber cut affecting New Jersey, (South Plainfield area). Its been down since yesterday morning. Our carriers (Paetec and Level3) say that its a Verizon fiber. Has anyone else heard anything on this?? Thank you, Sergei. From ge at linuxbox.org Mon Mar 30 07:43:53 2009 From: ge at linuxbox.org (Gadi Evron) Date: Mon, 30 Mar 2009 15:43:53 +0300 Subject: The Confiker Virus hype and measures In-Reply-To: <002d01c9b0c8$2382eb20$0101a8c0@E520> References: <002d01c9b0c8$2382eb20$0101a8c0@E520> Message-ID: <49D0BE89.6050006@linuxbox.org> Joe Blanchard wrote: > Anyone have a copy of this? Would like to analyze it and understand its > propagation. > > Thanks > -Joe I'm sure someone sent you a sample by now. As to the malware itself... I haven't personally been following conficker as I've been busy with other issues (as much as possible, anyway, with all the hype it's hard to escape), but I've been asking questions. I can try and speak on the matter from what I've learned by asking. Conficker is a real problem, but will the world end on April Fools? The answer I gather to be the most accurate is: "The conficker threat will be exactly the same as it is today, on April 1st." Perhaps putting a date on the threat makes people feel more comfortable. What if something happens on April 3rd? Whether we would be warned or not, we'll all likely ignore it if April 1st comes and goes quietly. As to the unknown, the author's mind, who can really tell what they will do come the 1st? But some of the hype I've seen is truly ridiculous. I am sure some of the protected hosting companies sold quite a bit with their "we defend against conficker" products. Is conficker a problem? Yes. Can we potentially face hardship on the 1xt? Yes. Is the rest complete bull? Yes. Gadi. From jmartinez at zero11.com Mon Mar 30 08:37:13 2009 From: jmartinez at zero11.com (John Martinez) Date: Mon, 30 Mar 2009 06:37:13 -0700 Subject: Fiber cut on Irish Sea + Verizon fiber cut In-Reply-To: <5b6f80200903291519s1483732at8130a99ba239e81f@mail.gmail.com> References: <373173782-1238340887-cardhu_decombobulator_blackberry.rim.net-415882138-@bxe1114.bisx.prod.on.blackberry> <644838.46768.qm@web52602.mail.re2.yahoo.com> <5b6f80200903291519s1483732at8130a99ba239e81f@mail.gmail.com> Message-ID: <49D0CB09.5080903@zero11.com> The two might be related since it was reported that both happened Sunday Morning. Ken Gilmour wrote: > Hi Isabel, > > It hasn't been confirmed to me yet but some people have mentioned that > it is most likely to belong to Global Crossing. > > Regards, > > Ken > > 2009/3/29 isabel dias : >> ken, who's fiber on the ground was it after all? >> >> Roderick Beck wrote: >>> Probably Global Crossing. >>> >>> A very strong wager. >>> >>> -R. >>> ------Original Message------ >>> From: Ken Gilmour >>> To: isabeldias1 at yahoo.com >>> Cc: nanog at nanog.org >>> Subject: Re: Fiber cut on Irish Sea >>> Sent: 29 Mar 2009 16:04 >>> >>> We received the report from Packet Exchange, however they are not the >>> owners of the cable. I assume they just rent spectrum. >>> >>> 2009/3/29 isabel dias : >>>> affecting whom? and who's network? >>>> >>>> >>>> --- On Sun, 3/29/09, Ken Gilmour wrote: >>>> >>>>> From: Ken Gilmour >>>>> Subject: Fiber cut on Irish Sea >>>>> To: nanog at nanog.org >>>>> Date: Sunday, March 29, 2009, 4:55 PM >>>>> Hi There, >>>>> >>>>> Since we use a vendor of "the vendor" of two >>>>> Irish sea submarine >>>>> cables I am wondering if anyone has first hand information >>>>> on the >>>>> fiber cut this morning? Does anyone have a status update on >>>>> what is >>>>> happening? I am getting some Chinese whispers going on >>>>> here. >>>>> >>>>> Thanks! >>>>> >>>>> Ken >>>> >>>> >>>> >>> >>> >>> Sent wirelessly via BlackBerry from T-Mobile. >> >> >> >> > From stasinia at msoe.edu Mon Mar 30 11:11:41 2009 From: stasinia at msoe.edu (Stasiniewicz, Adam) Date: Mon, 30 Mar 2009 11:11:41 -0500 Subject: The Confiker Virus hype and measures In-Reply-To: <49D0BE89.6050006@linuxbox.org> References: <002d01c9b0c8$2382eb20$0101a8c0@E520> <49D0BE89.6050006@linuxbox.org> Message-ID: <002001c9b152$36a530c0$a3ef9240$@edu> To the main stream media: Please leave your tin foil hats at the door... To my fellow NANOGers: I look at this virus from two perspectives. First the home computers (and small businesses without any real IT staff). And second the larger organizations with dedicated IT staff. Home Users: Many will agree that a large percent (>50%) of home computers are infected with some sort of malware. Everything from tracking cookies, to spam drones, to botnet clients. Home users are often too cheap/lazy to get antivirus/firewall protections. And many are scared to get updates from Microsoft because of some unrealized danger this might pose. As I see it, the virus is adding at most 9(?) million to the probable 175 million (350/2 ) malware infested hosts out there. In fact, it will probably be much less than that, as the people who are getting infected by this virus, are probably already affected by other malware. Everyone Else: If SQL Slammer has taught us anything, it is the importance of patch management and firewalls. And the unending stream of new malware has also taught us the importance of anti-virus software. With all the media hype and removal tools being made, there is no good reason any IT shop should be affected in any meaningful way. Invariably we will hear the stories of places that do get affected, but I doubt it will be anything overly large. So from a network operational perspective, unless the virus author decides to launch a DDOS on a single target (and one is either that network or its upstream) I predict this will have little, if any, effect. My $0.02, Adam Stasiniewicz -----Original Message----- From: Gadi Evron [mailto:ge at linuxbox.org] Sent: Monday, March 30, 2009 7:44 AM To: Joe Blanchard Cc: nanog at nanog.org Subject: The Confiker Virus hype and measures Joe Blanchard wrote: > Anyone have a copy of this? Would like to analyze it and understand its > propagation. > > Thanks > -Joe I'm sure someone sent you a sample by now. As to the malware itself... I haven't personally been following conficker as I've been busy with other issues (as much as possible, anyway, with all the hype it's hard to escape), but I've been asking questions. I can try and speak on the matter from what I've learned by asking. Conficker is a real problem, but will the world end on April Fools? The answer I gather to be the most accurate is: "The conficker threat will be exactly the same as it is today, on April 1st." Perhaps putting a date on the threat makes people feel more comfortable. What if something happens on April 3rd? Whether we would be warned or not, we'll all likely ignore it if April 1st comes and goes quietly. As to the unknown, the author's mind, who can really tell what they will do come the 1st? But some of the hype I've seen is truly ridiculous. I am sure some of the protected hosting companies sold quite a bit with their "we defend against conficker" products. Is conficker a problem? Yes. Can we potentially face hardship on the 1xt? Yes. Is the rest complete bull? Yes. Gadi. From fergdawgster at gmail.com Mon Mar 30 12:27:15 2009 From: fergdawgster at gmail.com (Paul Ferguson) Date: Mon, 30 Mar 2009 10:27:15 -0700 Subject: The Confiker Virus. In-Reply-To: <000001c9b0cc$c6126100$52372300$@com> References: <03AD93D590E44DCA986E2EAD7C6BD50B@jnpr.net> <002f01c9b0cb$0b0f6de0$0101a8c0@E520> <000001c9b0cc$c6126100$52372300$@com> Message-ID: <6cd462c00903301027y271d59b8x19387a00cca2419a@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sun, Mar 29, 2009 at 5:16 PM, Richard Golodner wrote: > > Joe said earlier today: >> Thanks, the only thing is that these, like most, websites are very vague > about the mechanics behind the infiltration > > Joe, the SRI report would be right up your alley as it is the most > technical in its analysis of the variants A and B as well as an > explanation of the algorithm it uses to determine domain names for future > use of some kind. > > http://mtc.sri.com/Conficker/ > Something folks might be interested in -- a way to detect Conficker-infected hosts in your network: https://www.honeynet.org/node/389 FYI, - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.3 (Build 5003) wj8DBQFJ0QDjq1pz9mNUZTMRAm7SAJ9MZo33Vok1uvyB4H7DML1gUKRlPQCggWtC bL4g6kI0sc75IDu/fYzv8yI= =HpOH -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/ From Skywing at valhallalegends.com Mon Mar 30 13:03:41 2009 From: Skywing at valhallalegends.com (Skywing) Date: Mon, 30 Mar 2009 13:03:41 -0500 Subject: The Confiker Virus hype and measures Message-ID: <982D8D05B6407A49AD506E6C3AC8E7D6E5092CE62B@caralain.haven.nynaeve.net> Actually, I can't remember the last cable/DSL ISP that I had seen solicit offers for service that didn't offer some level of free bundled AV. Most conventional AV software is oriented towards checking files for "badness" before the access is allowed, which doesn't really apply to the ms08-067 infection vector so much - at least, not in my experience with what most AV software does. That is more the domain of signature-based IPS's. But I think the real morale of the story is that end users want to see their computer like an every-day person sees a car: as a tool that works to get from A to B, and not what a mechanic would see a car as. Users don't want to have to deal with the nitty-gritty details of maintenance. Hence, why automatic updates are a good thing (*if implemented properly) in some cases (i.e. where there's no sysadmin to manage things). The AV folk have done that for a long time and it's been reasonably well accepted. - S -----Original Message----- From: Stasiniewicz, Adam Sent: Monday, March 30, 2009 09:11 To: nanog at nanog.org ; 'Gadi Evron' ; 'Joe Blanchard' Subject: RE: The Confiker Virus hype and measures To the main stream media: Please leave your tin foil hats at the door... To my fellow NANOGers: I look at this virus from two perspectives. First the home computers (and small businesses without any real IT staff). And second the larger organizations with dedicated IT staff. Home Users: Many will agree that a large percent (>50%) of home computers are infected with some sort of malware. Everything from tracking cookies, to spam drones, to botnet clients. Home users are often too cheap/lazy to get antivirus/firewall protections. And many are scared to get updates from Microsoft because of some unrealized danger this might pose. As I see it, the virus is adding at most 9(?) million to the probable 175 million (350/2 ) malware infested hosts out there. In fact, it will probably be much less than that, as the people who are getting infected by this virus, are probably already affected by other malware. Everyone Else: If SQL Slammer has taught us anything, it is the importance of patch management and firewalls. And the unending stream of new malware has also taught us the importance of anti-virus software. With all the media hype and removal tools being made, there is no good reason any IT shop should be affected in any meaningful way. Invariably we will hear the stories of places that do get affected, but I doubt it will be anything overly large. So from a network operational perspective, unless the virus author decides to launch a DDOS on a single target (and one is either that network or its upstream) I predict this will have little, if any, effect. My $0.02, Adam Stasiniewicz -----Original Message----- From: Gadi Evron [mailto:ge at linuxbox.org] Sent: Monday, March 30, 2009 7:44 AM To: Joe Blanchard Cc: nanog at nanog.org Subject: The Confiker Virus hype and measures Joe Blanchard wrote: > Anyone have a copy of this? Would like to analyze it and understand its > propagation. > > Thanks > -Joe I'm sure someone sent you a sample by now. As to the malware itself... I haven't personally been following conficker as I've been busy with other issues (as much as possible, anyway, with all the hype it's hard to escape), but I've been asking questions. I can try and speak on the matter from what I've learned by asking. Conficker is a real problem, but will the world end on April Fools? The answer I gather to be the most accurate is: "The conficker threat will be exactly the same as it is today, on April 1st." Perhaps putting a date on the threat makes people feel more comfortable. What if something happens on April 3rd? Whether we would be warned or not, we'll all likely ignore it if April 1st comes and goes quietly. As to the unknown, the author's mind, who can really tell what they will do come the 1st? But some of the hype I've seen is truly ridiculous. I am sure some of the protected hosting companies sold quite a bit with their "we defend against conficker" products. Is conficker a problem? Yes. Can we potentially face hardship on the 1xt? Yes. Is the rest complete bull? Yes. Gadi. From mike at rockynet.com Mon Mar 30 17:35:43 2009 From: mike at rockynet.com (Mike Lewinski) Date: Mon, 30 Mar 2009 16:35:43 -0600 Subject: Earthlink help needed Message-ID: <49D1493F.3040402@rockynet.com> One of our mail servers can't talk to any of the earthlink MX servers and after two weeks of trying I've got a queue full of undeliverable mail to their subs. Previous attempts at getting help via postmaster at earthlink.net are unanswered. INOC-DBA has no directory entry for them. This old NANOG post (http://www.merit.edu/mail.archives/nanog/msg01582.html) has a valid phone number but invalid extension. So I hit 0 and got a tech anyway. That tech instructed me to forward on my concerns to blockedbyearthlink at abuse.earthlink.net which I did, but nothing more than an auto-response has come back a week later now (and yes, I followed the instructions in the auto-responder and re-submitted in the requested format). Everything I've read indicates that if we are being blocked deliberately I should be getting a 550 SMTP error back. We do not even get a SYN/ACK back (nor ICMP unreachable/prohibited, nor RST) so no SMTP errors are generated from their servers. The MX are all pingable and traceable, so its not a routing problem AFAICT. The mailman server here has paranoid rDNS setup, does not appear on any blacklists, and has never been the subject of any spam complaints. It runs a listserv for a professional legal association which charges members a fee before they are allowed to join the list, so the possibility of unwanted third parties being subscribed is very near zero. TIA and sorry for the noise. We tried having an Earthlink subscriber work this from the other angle. All she got was "Earthlink has been blocking port 25 for years you should now this by now!" Mike Lewinski -- mike at rockynet.com POTS: 303-629-2860 INOC-DBA: 13345*mjl From joesox at gmail.com Mon Mar 30 17:46:27 2009 From: joesox at gmail.com (JoeSox) Date: Mon, 30 Mar 2009 15:46:27 -0700 Subject: The Confiker Virus. In-Reply-To: <6cd462c00903301027y271d59b8x19387a00cca2419a@mail.gmail.com> References: <03AD93D590E44DCA986E2EAD7C6BD50B@jnpr.net> <002f01c9b0cb$0b0f6de0$0101a8c0@E520> <000001c9b0cc$c6126100$52372300$@com> <6cd462c00903301027y271d59b8x19387a00cca2419a@mail.gmail.com> Message-ID: <785694cd0903301546r2b34e1e8kafdd1d2af3e988ef@mail.gmail.com> Has anyone tried the Python scs Network Scanner script? http://iv.cs.uni-bonn.de/wg/cs/applications/containing-conficker/ I have installed Impacket-0.9.6.0 library but it throws the following warning "WARNING: Crypto package not found. Some features will fail." Does anyone know if this effects the reliability of the scs script? I have it scanning but I don't like that warning. What other library is Impacket looking for to correct that warning? -- Thanks, Joe On Mon, Mar 30, 2009 at 10:27 AM, Paul Ferguson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > Something folks might be interested in -- a way to detect > Conficker-infected hosts in your network: > > https://www.honeynet.org/node/389 > > FYI, > > - - ferg > > > -----BEGIN PGP SIGNATURE----- > Version: PGP Desktop 9.5.3 (Build 5003) > > wj8DBQFJ0QDjq1pz9mNUZTMRAm7SAJ9MZo33Vok1uvyB4H7DML1gUKRlPQCggWtC > bL4g6kI0sc75IDu/fYzv8yI= > =HpOH > -----END PGP SIGNATURE----- > > > -- > "Fergie", a.k.a. Paul Ferguson > ?Engineering Architecture for the Internet > ?fergdawgster(at)gmail.com > ?ferg's tech blog: http://fergdawg.blogspot.com/ > > From mike at rockynet.com Mon Mar 30 19:15:50 2009 From: mike at rockynet.com (Mike Lewinski) Date: Mon, 30 Mar 2009 18:15:50 -0600 Subject: Earthlink help needed In-Reply-To: <49D1493F.3040402@rockynet.com> References: <49D1493F.3040402@rockynet.com> Message-ID: <49D160B6.5090205@rockynet.com> Within an hour of making this post I received a call from a very helpful engineer at Earthlink. The problem has been identified and a resolution is in the works. Mike Mike Lewinski wrote: > One of our mail servers can't talk to any of the earthlink MX servers > and after two weeks of trying I've got a queue full of undeliverable > mail to their subs. > > Previous attempts at getting help via postmaster at earthlink.net are > unanswered. INOC-DBA has no directory entry for them. This old NANOG > post (http://www.merit.edu/mail.archives/nanog/msg01582.html) has a > valid phone number but invalid extension. So I hit 0 and got a tech > anyway. That tech instructed me to forward on my concerns to > blockedbyearthlink at abuse.earthlink.net which I did, but nothing more > than an auto-response has come back a week later now (and yes, I > followed the instructions in the auto-responder and re-submitted in the > requested format). > > Everything I've read indicates that if we are being blocked deliberately > I should be getting a 550 SMTP error back. We do not even get a SYN/ACK > back (nor ICMP unreachable/prohibited, nor RST) so no SMTP errors are > generated from their servers. The MX are all pingable and traceable, so > its not a routing problem AFAICT. > > The mailman server here has paranoid rDNS setup, does not appear on any > blacklists, and has never been the subject of any spam complaints. It > runs a listserv for a professional legal association which charges > members a fee before they are allowed to join the list, so the > possibility of unwanted third parties being subscribed is very near zero. > > TIA and sorry for the noise. We tried having an Earthlink subscriber > work this from the other angle. All she got was "Earthlink has been > blocking port 25 for years you should now this by now!" > > Mike Lewinski > -- > mike at rockynet.com > POTS: 303-629-2860 > INOC-DBA: 13345*mjl > From netfortius at gmail.com Mon Mar 30 19:48:01 2009 From: netfortius at gmail.com (Stefan) Date: Mon, 30 Mar 2009 19:48:01 -0500 Subject: The Confiker Virus. In-Reply-To: <785694cd0903301546r2b34e1e8kafdd1d2af3e988ef@mail.gmail.com> References: <03AD93D590E44DCA986E2EAD7C6BD50B@jnpr.net> <002f01c9b0cb$0b0f6de0$0101a8c0@E520> <000001c9b0cc$c6126100$52372300$@com> <6cd462c00903301027y271d59b8x19387a00cca2419a@mail.gmail.com> <785694cd0903301546r2b34e1e8kafdd1d2af3e988ef@mail.gmail.com> Message-ID: Just FYI - I had a pretty high ratio of properly conficker-infected honeypots identified vs. false positives ratio, using nessus' appropriate signature, whereas I could never get the py script to properly run on my macbook pro ... -- Stefan On 3/30/09, JoeSox wrote: > Has anyone tried the Python scs Network Scanner script? > http://iv.cs.uni-bonn.de/wg/cs/applications/containing-conficker/ > > I have installed Impacket-0.9.6.0 library but it throws the following > warning > "WARNING: Crypto package not found. Some features will fail." > > Does anyone know if this effects the reliability of the scs script? I > have it scanning but I don't like that warning. > > What other library is Impacket looking for to correct that warning? > > -- > Thanks, Joe > > > On Mon, Mar 30, 2009 at 10:27 AM, Paul Ferguson > wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> >> Something folks might be interested in -- a way to detect >> Conficker-infected hosts in your network: >> >> https://www.honeynet.org/node/389 >> >> FYI, >> >> - - ferg >> >> >> -----BEGIN PGP SIGNATURE----- >> Version: PGP Desktop 9.5.3 (Build 5003) >> >> wj8DBQFJ0QDjq1pz9mNUZTMRAm7SAJ9MZo33Vok1uvyB4H7DML1gUKRlPQCggWtC >> bL4g6kI0sc75IDu/fYzv8yI= >> =HpOH >> -----END PGP SIGNATURE----- >> >> >> -- >> "Fergie", a.k.a. Paul Ferguson >> ?Engineering Architecture for the Internet >> ?fergdawgster(at)gmail.com >> ?ferg's tech blog: http://fergdawg.blogspot.com/ >> >> > > -- Sent from my mobile device ***Stefan http://twitter.com/netfortius From ge at linuxbox.org Mon Mar 30 20:25:46 2009 From: ge at linuxbox.org (Gadi Evron) Date: Tue, 31 Mar 2009 04:25:46 +0300 Subject: The Confiker Virus hype and measures In-Reply-To: <002001c9b152$36a530c0$a3ef9240$@edu> References: <002d01c9b0c8$2382eb20$0101a8c0@E520> <49D0BE89.6050006@linuxbox.org> <002001c9b152$36a530c0$a3ef9240$@edu> Message-ID: <49D1711A.5000007@linuxbox.org> Stasiniewicz, Adam wrote: > So from a network operational perspective, unless the virus author > decides to launch a DDOS on a single target (and one is either that > network or its upstream) I predict this will have little, if any, effect. > Agreed. Although being ready to answer your abuse mail to null-route on your networks could be helpful to the community. Gadi. From grinch at panix.com Mon Mar 30 20:30:44 2009 From: grinch at panix.com (grinch at panix.com) Date: Tue, 31 Mar 2009 01:30:44 +0000 Subject: Earthlink help needed Message-ID: <677720489-1238463070-cardhu_decombobulator_blackberry.rim.net-691094830-@bxe1280.bisx.prod.on.blackberry> I, for one, appreciate this type of feedback. Rgs, ------Original Message------ From: Mike Lewinski To: NANOG Subject: Re: Earthlink help needed Sent: Mar 30, 2009 5:15 PM Within an hour of making this post I received a call from a very helpful engineer at Earthlink. The problem has been identified and a resolution is in the works. Mike Mike Lewinski wrote: > One of our mail servers can't talk to any of the earthlink MX servers > and after two weeks of trying I've got a queue full of undeliverable > mail to their subs. > > Previous attempts at getting help via postmaster at earthlink.net are > unanswered. INOC-DBA has no directory entry for them. This old NANOG > post (http://www.merit.edu/mail.archives/nanog/msg01582.html) has a > valid phone number but invalid extension. So I hit 0 and got a tech > anyway. That tech instructed me to forward on my concerns to > blockedbyearthlink at abuse.earthlink.net which I did, but nothing more > than an auto-response has come back a week later now (and yes, I > followed the instructions in the auto-responder and re-submitted in the > requested format). > > Everything I've read indicates that if we are being blocked deliberately > I should be getting a 550 SMTP error back. We do not even get a SYN/ACK > back (nor ICMP unreachable/prohibited, nor RST) so no SMTP errors are > generated from their servers. The MX are all pingable and traceable, so > its not a routing problem AFAICT. > > The mailman server here has paranoid rDNS setup, does not appear on any > blacklists, and has never been the subject of any spam complaints. It > runs a listserv for a professional legal association which charges > members a fee before they are allowed to join the list, so the > possibility of unwanted third parties being subscribed is very near zero. > > TIA and sorry for the noise. We tried having an Earthlink subscriber > work this from the other angle. All she got was "Earthlink has been > blocking port 25 for years you should now this by now!" > > Mike Lewinski > -- > mike at rockynet.com > POTS: 303-629-2860 > INOC-DBA: 13345*mjl > Sent via BlackBerry by AT&T From David at sunshadeseyewear.com.au Tue Mar 31 01:10:03 2009 From: David at sunshadeseyewear.com.au (David Tebbutt) Date: Tue, 31 Mar 2009 16:10:03 +1000 Subject: The Confiker Virus. In-Reply-To: <785694cd0903301546r2b34e1e8kafdd1d2af3e988ef@mail.gmail.com> References: <03AD93D590E44DCA986E2EAD7C6BD50B@jnpr.net> <002f01c9b0cb$0b0f6de0$0101a8c0@E520> <000001c9b0cc$c6126100$52372300$@com> <6cd462c00903301027y271d59b8x19387a00cca2419a@mail.gmail.com> <785694cd0903301546r2b34e1e8kafdd1d2af3e988ef@mail.gmail.com> Message-ID: <49D24059.F1D8.006C.0@sunshadeseyewear.com.au> you need to add python-crypto with whatever package manager your OS uses, yast line in suse: ?python-crypto ?2.0.1 ?2.0.1 ?Collection of cryptographic algorithms and protocols, implemented for use from Python d >>> JoeSox 31/03/09 8:46 am >>> Has anyone tried the Python scs Network Scanner script? http://iv.cs.uni-bonn.de/wg/cs/applications/containing-conficker/ I have installed Impacket-0.9.6.0 library but it throws the following warning "WARNING: Crypto package not found. Some features will fail." Does anyone know if this effects the reliability of the scs script? I have it scanning but I don't like that warning. What other library is Impacket looking for to correct that warning? -- Thanks, Joe On Mon, Mar 30, 2009 at 10:27 AM, Paul Ferguson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > Something folks might be interested in -- a way to detect > Conficker-infected hosts in your network: > > https://www.honeynet.org/node/389 > > FYI, > > - - ferg > > > -----BEGIN PGP SIGNATURE----- > Version: PGP Desktop 9.5.3 (Build 5003) > > wj8DBQFJ0QDjq1pz9mNUZTMRAm7SAJ9MZo33Vok1uvyB4H7DML1gUKRlPQCggWtC > bL4g6kI0sc75IDu/fYzv8yI= > =HpOH > -----END PGP SIGNATURE----- > > > -- > "Fergie", a.k.a. Paul Ferguson > Engineering Architecture for the Internet > fergdawgster(at)gmail.com > ferg's tech blog: http://fergdawg.blogspot.com/ > > From jnzioka at gmail.com Tue Mar 31 05:05:06 2009 From: jnzioka at gmail.com (Joseph Nzioka) Date: Tue, 31 Mar 2009 13:05:06 +0300 Subject: Cacti Graphing Message-ID: <8f79f1230903310305u3557779ap47e88070269b3354@mail.gmail.com> Hi All, Has any one on this list graphed alcatel-lucent service routers succesfully using Cacti and if yes would you be kind enough to provide the base template or the how to.? -- Kind Regards ............................................ Joseph Nzioka, Cell:+254 735 452050 Cell:+254 711 968429 From eric-list at truenet.com Tue Mar 31 07:48:40 2009 From: eric-list at truenet.com (Eric Tykwinski) Date: Tue, 31 Mar 2009 08:48:40 -0400 Subject: The Confiker Virus. In-Reply-To: <49D24059.F1D8.006C.0@sunshadeseyewear.com.au> References: <03AD93D590E44DCA986E2EAD7C6BD50B@jnpr.net><002f01c9b0cb$0b0f6de0$0101a8c0@E520><000001c9b0cc$c6126100$52372300$@com><6cd462c00903301027y271d59b8x19387a00cca2419a@mail.gmail.com><785694cd0903301546r2b34e1e8kafdd1d2af3e988ef@mail.gmail.com> <49D24059.F1D8.006C.0@sunshadeseyewear.com.au> Message-ID: Joe, Here's the link for the Python Crypto toolkit: http://www.amk.ca/python/code/crypto.html I scanned our internal network and didn't find anything, so I can't really vouch for it's reliablity though. -----Original Message----- From: David Tebbutt [mailto:David at sunshadeseyewear.com.au] Sent: Tuesday, March 31, 2009 2:10 AM To: Paul Ferguson; JoeSox Cc: nanog at nanog.org Subject: Re: The Confiker Virus. you need to add python-crypto with whatever package manager your OS uses, yast line in suse: |python-crypto |2.0.1 |2.0.1 |Collection of cryptographic algorithms and protocols, implemented for use from Python d >>> JoeSox 31/03/09 8:46 am >>> Has anyone tried the Python scs Network Scanner script? http://iv.cs.uni-bonn.de/wg/cs/applications/containing-conficker/ I have installed Impacket-0.9.6.0 library but it throws the following warning "WARNING: Crypto package not found. Some features will fail." Does anyone know if this effects the reliability of the scs script? I have it scanning but I don't like that warning. What other library is Impacket looking for to correct that warning? -- Thanks, Joe On Mon, Mar 30, 2009 at 10:27 AM, Paul Ferguson wrote: From jason at biel-tech.com Tue Mar 31 07:56:42 2009 From: jason at biel-tech.com (Jason Biel) Date: Tue, 31 Mar 2009 07:56:42 -0500 Subject: The Confiker Virus. In-Reply-To: References: <03AD93D590E44DCA986E2EAD7C6BD50B@jnpr.net> <002f01c9b0cb$0b0f6de0$0101a8c0@E520> <000001c9b0cc$c6126100$52372300$@com> <6cd462c00903301027y271d59b8x19387a00cca2419a@mail.gmail.com> <785694cd0903301546r2b34e1e8kafdd1d2af3e988ef@mail.gmail.com> <49D24059.F1D8.006C.0@sunshadeseyewear.com.au> Message-ID: Anyone try the new nmap beta that includes the ability to detect it? nmap-4.85BETA5 ? I am looking for output from a scan on a known infected machine vs what I believe is a clean machine I have. Thanks, On Tue, Mar 31, 2009 at 7:48 AM, Eric Tykwinski wrote: > Joe, > > Here's the link for the Python Crypto toolkit: > http://www.amk.ca/python/code/crypto.html > > I scanned our internal network and didn't find anything, so I can't really > vouch for it's reliablity though. > > -----Original Message----- > From: David Tebbutt [mailto:David at sunshadeseyewear.com.au] > Sent: Tuesday, March 31, 2009 2:10 AM > To: Paul Ferguson; JoeSox > Cc: nanog at nanog.org > Subject: Re: The Confiker Virus. > > you need to add python-crypto with whatever package manager your OS uses, > yast line in suse: > > |python-crypto |2.0.1 |2.0.1 > |Collection of cryptographic algorithms and protocols, implemented for use > from Python > > d > > >>> JoeSox 31/03/09 8:46 am >>> > Has anyone tried the Python scs Network Scanner script? > http://iv.cs.uni-bonn.de/wg/cs/applications/containing-conficker/ > > I have installed Impacket-0.9.6.0 library but it throws the following > warning > "WARNING: Crypto package not found. Some features will fail." > > Does anyone know if this effects the reliability of the scs script? I have > it scanning but I don't like that warning. > > What other library is Impacket looking for to correct that warning? > > -- > Thanks, Joe > > > On Mon, Mar 30, 2009 at 10:27 AM, Paul Ferguson > wrote: > > > -- Jason Biel From netfortius at gmail.com Tue Mar 31 08:08:52 2009 From: netfortius at gmail.com (Stefan) Date: Tue, 31 Mar 2009 08:08:52 -0500 Subject: The Confiker Virus. In-Reply-To: References: <03AD93D590E44DCA986E2EAD7C6BD50B@jnpr.net> <002f01c9b0cb$0b0f6de0$0101a8c0@E520> <000001c9b0cc$c6126100$52372300$@com> <6cd462c00903301027y271d59b8x19387a00cca2419a@mail.gmail.com> <785694cd0903301546r2b34e1e8kafdd1d2af3e988ef@mail.gmail.com> <49D24059.F1D8.006C.0@sunshadeseyewear.com.au> Message-ID: Here is a pretty good recap of all options, including some useful comments: http://it.slashdot.org/article.pl?sid=09/03/30/090224 - including the specific one addressing the py script: http://it.slashdot.org/comments.pl?sid=1180397&cid=27387085 ) Stefan On Tue, Mar 31, 2009 at 7:48 AM, Eric Tykwinski wrote: > Joe, > > Here's the link for the Python Crypto toolkit: > http://www.amk.ca/python/code/crypto.html > > I scanned our internal network and didn't find anything, so I can't really > vouch for it's reliablity though. > > -----Original Message----- > From: David Tebbutt [mailto:David at sunshadeseyewear.com.au] > Sent: Tuesday, March 31, 2009 2:10 AM > To: Paul Ferguson; JoeSox > Cc: nanog at nanog.org > Subject: Re: The Confiker Virus. > > you need to add python-crypto with whatever package manager your OS uses, > yast line in suse: > > |python-crypto ? ? ? ? ? ? ? ? ? |2.0.1 ? ? ? ? ?|2.0.1 > |Collection of cryptographic algorithms and protocols, implemented for use > from Python > > d > >>>> JoeSox 31/03/09 8:46 am >>> > Has anyone tried the Python scs Network Scanner script? > http://iv.cs.uni-bonn.de/wg/cs/applications/containing-conficker/ > > I have installed Impacket-0.9.6.0 library but it throws the following > warning > "WARNING: Crypto package not found. Some features will fail." > > Does anyone know if this effects the reliability of the scs script? I have > it scanning but I don't like that warning. > > What other library is Impacket looking for to correct that warning? > > -- > Thanks, Joe > > > On Mon, Mar 30, 2009 at 10:27 AM, Paul Ferguson > wrote: > > > -- ***Stefan http://twitter.com/netfortius From smb at cs.columbia.edu Tue Mar 31 08:22:32 2009 From: smb at cs.columbia.edu (Steven M. Bellovin) Date: Tue, 31 Mar 2009 09:22:32 -0400 Subject: The Confiker Virus. In-Reply-To: References: <03AD93D590E44DCA986E2EAD7C6BD50B@jnpr.net> <002f01c9b0cb$0b0f6de0$0101a8c0@E520> <000001c9b0cc$c6126100$52372300$@com> <6cd462c00903301027y271d59b8x19387a00cca2419a@mail.gmail.com> <785694cd0903301546r2b34e1e8kafdd1d2af3e988ef@mail.gmail.com> <49D24059.F1D8.006C.0@sunshadeseyewear.com.au> Message-ID: <20090331092232.5d21f508@cs.columbia.edu> Also see http://arstechnica.com/security/news/2009/03/new-method-for-detecting-conficker-discovered-debuted.ars From joesox at gmail.com Tue Mar 31 08:31:00 2009 From: joesox at gmail.com (JoeSox) Date: Tue, 31 Mar 2009 06:31:00 -0700 Subject: The Confiker Virus. In-Reply-To: <49D24059.F1D8.006C.0@sunshadeseyewear.com.au> References: <03AD93D590E44DCA986E2EAD7C6BD50B@jnpr.net> <002f01c9b0cb$0b0f6de0$0101a8c0@E520> <000001c9b0cc$c6126100$52372300$@com> <6cd462c00903301027y271d59b8x19387a00cca2419a@mail.gmail.com> <785694cd0903301546r2b34e1e8kafdd1d2af3e988ef@mail.gmail.com> <49D24059.F1D8.006C.0@sunshadeseyewear.com.au> Message-ID: <785694cd0903310631n66c6e00fs34e5adef648bb15b@mail.gmail.com> I forgot to mention that I have had python-crypto already installed before I posted. I was still getting the WARNING. -- Joe On Mon, Mar 30, 2009 at 11:10 PM, David Tebbutt wrote: > you need to add python-crypto with whatever package manager your OS > uses, > yast line in suse: > > ?python-crypto ? ? ? ? ? ? ? ? ? ?2.0.1 ? ? ? ? ??2.0.1 > ?Collection of cryptographic algorithms and protocols, implemented > for use from Python > > d > From alex.wilkinson at dsto.defence.gov.au Tue Mar 31 08:33:41 2009 From: alex.wilkinson at dsto.defence.gov.au (Wilkinson, Alex) Date: Tue, 31 Mar 2009 21:33:41 +0800 Subject: The Confiker Virus. In-Reply-To: <20090331092232.5d21f508@cs.columbia.edu> References: <03AD93D590E44DCA986E2EAD7C6BD50B@jnpr.net> <002f01c9b0cb$0b0f6de0$0101a8c0@E520> <000001c9b0cc$c6126100$52372300$@com> <6cd462c00903301027y271d59b8x19387a00cca2419a@mail.gmail.com> <785694cd0903301546r2b34e1e8kafdd1d2af3e988ef@mail.gmail.com> <49D24059.F1D8.006C.0@sunshadeseyewear.com.au> <20090331092232.5d21f508@cs.columbia.edu> Message-ID: <20090331133341.GC87477@stlux503.dsto.defence.gov.au> 0n Tue, Mar 31, 2009 at 09:22:32AM -0400, Steven M. Bellovin wrote: Honeynet Project has released Know Your Enemy: Containing Conficker: Our "Know Your Enemy: Containing Conficker" whitepaper was released on March 30th as a PDF only. You can download the full paper from the link below. Paper Abstract The Conficker worm has infected several million computers since it first started spreading in late 2008 but attempts to mitigate Conficker have not yet proved very successful. In this paper we present several potential methods to contain Conficker. The approaches presented take advantage of the way Conficker patches infected systems, which can be used to remotely detect a compromised system. Furthermore, we demonstrate various methods to detect and remove Conficker locally and a potential vaccination tool is presented. Finally, the domainname generation mechanism for all three Conficker variants is discussed in detail and an overview of the potential for upcoming domain collisions in version .C is provided. Tools for all the ideas presented here are freely available for download including source code. In addition, as a result of this paper and the hard work of Dan Kaminsky, most vulnerability scanning tools (including Nmap) should now have a plugin or signatures that allow you to remotely detect infected Conficker systems on your networks. Finally, we would like to recognize and thank the tremendous help and input of the Conficker Working Group. Paper last updated March 30th 2009, 23:00 GMT (rev1) http://www.honeynet.org/files/KYE-Conficker.pdf -aW IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914. If you have received this email in error, you are requested to contact the sender and delete the email. From jason at biel-tech.com Tue Mar 31 08:37:41 2009 From: jason at biel-tech.com (Jason Biel) Date: Tue, 31 Mar 2009 08:37:41 -0500 Subject: The Confiker Virus. In-Reply-To: <785694cd0903310631n66c6e00fs34e5adef648bb15b@mail.gmail.com> References: <03AD93D590E44DCA986E2EAD7C6BD50B@jnpr.net> <002f01c9b0cb$0b0f6de0$0101a8c0@E520> <000001c9b0cc$c6126100$52372300$@com> <6cd462c00903301027y271d59b8x19387a00cca2419a@mail.gmail.com> <785694cd0903301546r2b34e1e8kafdd1d2af3e988ef@mail.gmail.com> <49D24059.F1D8.006C.0@sunshadeseyewear.com.au> <785694cd0903310631n66c6e00fs34e5adef648bb15b@mail.gmail.com> Message-ID: >From what I can find with the nmap way, You don't want to see *Conficker: LIKELY INFECTED* or *Conficker: VULNERABLE*. 2009/3/31 JoeSox > I forgot to mention that I have had python-crypto already installed > before I posted. I was still getting the WARNING. > -- > Joe > > On Mon, Mar 30, 2009 at 11:10 PM, David Tebbutt > wrote: > > you need to add python-crypto with whatever package manager your OS > > uses, > > yast line in suse: > > > > ?python-crypto ?2.0.1 ?2.0.1 > > ?Collection of cryptographic algorithms and protocols, implemented > > for use from Python > > > > d > > > > -- Jason Biel From joesox at gmail.com Tue Mar 31 08:41:17 2009 From: joesox at gmail.com (JoeSox) Date: Tue, 31 Mar 2009 06:41:17 -0700 Subject: The Confiker Virus. In-Reply-To: References: <03AD93D590E44DCA986E2EAD7C6BD50B@jnpr.net> <002f01c9b0cb$0b0f6de0$0101a8c0@E520> <000001c9b0cc$c6126100$52372300$@com> <6cd462c00903301027y271d59b8x19387a00cca2419a@mail.gmail.com> <785694cd0903301546r2b34e1e8kafdd1d2af3e988ef@mail.gmail.com> <49D24059.F1D8.006C.0@sunshadeseyewear.com.au> Message-ID: <785694cd0903310641x325d14fct687ca85e04c8051f@mail.gmail.com> I am uncertain also. I scan a subnet on my network with Axence NetTools looking for 445 port and I receive some hits. I perform a netstat -a some of those results but don't really see any 445 activity. The SCS script doesn't find anything either. The PCs are patched and virusscan updated. One PC when I connected to it did not navigate to Windowsupdate website. I scheduled a Full McAfee scan as their documentation suggests (http://download.nai.com/products/mcafee-avert/documents/combating_w32_conficker_worm.pdf), and sometime through the scan I was able to reach windowsupdate. I don't know if it was a coincidence or not that I was not able to reach the website. I haven't looked into the registry and any other places for evidence of conficker. I will probably today but I am afraid it maybe a waste of time since they are already patched and updated. -- Joe On Tue, Mar 31, 2009 at 5:48 AM, Eric Tykwinski wrote: > Joe, > > Here's the link for the Python Crypto toolkit: > http://www.amk.ca/python/code/crypto.html > > I scanned our internal network and didn't find anything, so I can't really > vouch for it's reliablity though. From maillist at webjogger.net Tue Mar 31 10:18:03 2009 From: maillist at webjogger.net (Adam Greene) Date: Tue, 31 Mar 2009 11:18:03 -0400 Subject: TWC outage Message-ID: <3D4E543D15AB477DBD13B4C4C0F687FD@GINKGO> Seems to be an outage with Time Warner Cable in the upstate New York area ... As far as I can tell, it's on AS7843. I'm awaiting callback from an engineer for details .... Adam -- Webjogger (845) 757-4000 ASN 20208 ====== C:\>tracert www.authorize.net Tracing route to www.authorize.net [64.94.118.77] over a maximum of 30 hops: 1 38 ms 1 ms 2 ms 10049.webjogger.net [204.8.80.49] 2 6 ms 6 ms 7 ms cpe-24-29-112-25.nyc.res.rr.com [24.29.112.25] 3 8 ms 7 ms 6 ms gig-12-2-nycmnyrdc-rtr1.nyc.rr.com [24.29.104.97] 4 7 ms 7 ms 8 ms gig1-0-0-nwrknjmd-rtr1.nyc.rr.com [24.29.130.182] 5 7 ms 7 ms 6 ms ae-4-0.cr0.nyc30.tbone.rr.com [66.109.6.78] 6 9 ms 8 ms 8 ms ae-1-0.pr0.nyc20.tbone.rr.com [66.109.6.163] 7 8 ms 9 ms 8 ms 66.109.9.210 8 * * * Request timed out. 9 * * * Request timed out. 10 * * * Request timed out. 11 * * * Request timed out. 12 * * * Request timed out. 13 * * * Request timed out. 14 * * * Request timed out. 15 * * * Request timed out. 16 * * * Request timed out. 17 * * * Request timed out. 18 * * * Request timed out. 19 * * * Request timed out. 20 * * * Request timed out. 21 * * * Request timed out. 22 * * * Request timed out. 23 * * * Request timed out. 24 * * * Request timed out. 25 * * * Request timed out. 26 * * * Request timed out. 27 * * * Request timed out. 28 * * * Request timed out. 29 * * * Request timed out. 30 * * * Request timed out. Trace complete. From rbeverly at rbeverly.net Tue Mar 31 10:36:18 2009 From: rbeverly at rbeverly.net (Robert Beverly) Date: Tue, 31 Mar 2009 11:36:18 -0400 Subject: Spoofer project update Message-ID: <20090331153618.GA5260@rbeverly.net> Hi, as many of you are acutely aware, IP source spoofing is still a common attack vector. The ANA spoofer project: http://spoofer.csail.mit.edu first began quantifying the extent of source verification in 2005. We've amassed several years worth of data -- data that has become particularly interesting in light of recent attacks. However, our data raised as many questions as it answered. Hence, we have developed a new version of the tester designed to answer these questions and improve our Internet-wide inferences. What's New: In addition to new tests, we've hooked into CAIDA's Ark infrastructure which allows us to perform multiple path-based measurements. This information is presented to the client now in visual form; see the screenshots for an example report: http://spoofer.csail.mit.edu/example/example.php How you can help: Simple -- take a few minutes to download and run the tester. The more points you can run the tester from, the better. Comments/Flames: Welcome, and we appreciate all feedback. Be sure to read the FAQ: http://spoofer.csail.mit.edu/faq.php Many thanks, rob -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From rmacharia at gmail.com Tue Mar 31 10:53:18 2009 From: rmacharia at gmail.com (Raymond Macharia) Date: Tue, 31 Mar 2009 18:53:18 +0300 Subject: Cacti Graphing In-Reply-To: <8f79f1230903310305u3557779ap47e88070269b3354@mail.gmail.com> References: <8f79f1230903310305u3557779ap47e88070269b3354@mail.gmail.com> Message-ID: Hi Nzioka, the appropriate place for your request is http://forums.cacti.net/. Or you can also check http://sourceforge.net/mailarchive/forum.php?forum_name=cacti-user Regards Raymond Macharia On Tue, Mar 31, 2009 at 1:05 PM, Joseph Nzioka wrote: > Hi All, > > Has any one on this list graphed alcatel-lucent service routers succesfully > using Cacti and if yes would you be kind enough to provide the base > template > or the how to.? > > -- > Kind Regards > ............................................ > Joseph Nzioka, > Cell:+254 735 452050 > Cell:+254 711 968429 > From rcorbin at traffiq.com Tue Mar 31 13:44:59 2009 From: rcorbin at traffiq.com (Ray Corbin) Date: Tue, 31 Mar 2009 13:44:59 -0500 Subject: Earthlink help needed In-Reply-To: <49D160B6.5090205@rockynet.com> Message-ID: Hey, I'm also having an issue with mail delivery to earthlink. It seems some of the messages to earthlink are not reaching the inbox post the initial acceptance. Can an earthlink administrator confirm off-list if this is something the client can control? The few that I have examples of swear they never receive the message but our logs show it was accepted for delivery. Thanks, Raymond Corbin 443.866.6048 > -----Original Message----- > From: Mike Lewinski [mailto:mike at rockynet.com] > Sent: Monday, March 30, 2009 8:16 PM > To: nanog at nanog.org > Subject: Re: Earthlink help needed > > Within an hour of making this post I received a call from a very helpful > engineer at Earthlink. The problem has been identified and a resolution > is in the works. > > Mike > > Mike Lewinski wrote: > > One of our mail servers can't talk to any of the earthlink MX servers > > and after two weeks of trying I've got a queue full of undeliverable > > mail to their subs. > > > > Previous attempts at getting help via postmaster at earthlink.net are > > unanswered. INOC-DBA has no directory entry for them. This old NANOG > > post (http://www.merit.edu/mail.archives/nanog/msg01582.html) has a > > valid phone number but invalid extension. So I hit 0 and got a tech > > anyway. That tech instructed me to forward on my concerns to > > blockedbyearthlink at abuse.earthlink.net which I did, but nothing more > > than an auto-response has come back a week later now (and yes, I > > followed the instructions in the auto-responder and re-submitted in the > > requested format). > > > > Everything I've read indicates that if we are being blocked deliberately > > I should be getting a 550 SMTP error back. We do not even get a SYN/ACK > > back (nor ICMP unreachable/prohibited, nor RST) so no SMTP errors are > > generated from their servers. The MX are all pingable and traceable, so > > its not a routing problem AFAICT. > > > > The mailman server here has paranoid rDNS setup, does not appear on any > > blacklists, and has never been the subject of any spam complaints. It > > runs a listserv for a professional legal association which charges > > members a fee before they are allowed to join the list, so the > > possibility of unwanted third parties being subscribed is very near > zero. > > > > TIA and sorry for the noise. We tried having an Earthlink subscriber > > work this from the other angle. All she got was "Earthlink has been > > blocking port 25 for years you should now this by now!" > > > > Mike Lewinski > > -- > > mike at rockynet.com > > POTS: 303-629-2860 > > INOC-DBA: 13345*mjl > > > From martin at theicelandguy.com Tue Mar 31 13:49:55 2009 From: martin at theicelandguy.com (Martin Hannigan) Date: Tue, 31 Mar 2009 14:49:55 -0400 Subject: Cacti Graphing In-Reply-To: <8f79f1230903310305u3557779ap47e88070269b3354@mail.gmail.com> References: <8f79f1230903310305u3557779ap47e88070269b3354@mail.gmail.com> Message-ID: Hi Joe, I sent you some links offline as well, but make sure the polling host can talk to the target: IIRC, the Alcatel/Lucent device(s) default to snmp v2. IIRC, Cacti is defaulted to v1. At the CLI of the [hopefully] nix device: snmpwalk -v 2c $community ip_addr 1.3.6 That should prove that you can talk to and walk the device. If that works and the poller doesn't, investigate host poller settings or options for v2. That and ACL's have been typical root causes of problems whenever I have had issues with polling a target device. Best, Martin On Tue, Mar 31, 2009 at 6:05 AM, Joseph Nzioka wrote: > Hi All, > > Has any one on this list graphed alcatel-lucent service routers succesfully > using Cacti and if yes would you be kind enough to provide the base > template > or the how to.? > > -- > Kind Regards > ............................................ > Joseph Nzioka, > Cell:+254 735 452050 > Cell:+254 711 968429 > -- Martin Hannigan martin at theicelandguy.com p: +16178216079 Power, Network, and Costs Consulting for Iceland Datacenters From sfischer1967 at gmail.com Tue Mar 31 15:37:48 2009 From: sfischer1967 at gmail.com (Steven Fischer) Date: Tue, 31 Mar 2009 16:37:48 -0400 Subject: The Confiker Virus. In-Reply-To: <785694cd0903310641x325d14fct687ca85e04c8051f@mail.gmail.com> References: <03AD93D590E44DCA986E2EAD7C6BD50B@jnpr.net> <002f01c9b0cb$0b0f6de0$0101a8c0@E520> <000001c9b0cc$c6126100$52372300$@com> <6cd462c00903301027y271d59b8x19387a00cca2419a@mail.gmail.com> <785694cd0903301546r2b34e1e8kafdd1d2af3e988ef@mail.gmail.com> <49D24059.F1D8.006C.0@sunshadeseyewear.com.au> <785694cd0903310641x325d14fct687ca85e04c8051f@mail.gmail.com> Message-ID: <500ffb690903311337h79de52d7vaacbbd449fed2ff@mail.gmail.com> Is anyone aware of any network-based signatures that could be used to identify and tag IP traffic, for dropping at the ingress/egress points? On Tue, Mar 31, 2009 at 9:41 AM, JoeSox wrote: > I am uncertain also. I scan a subnet on my network with Axence > NetTools looking for 445 port and I receive some hits. I perform a > netstat -a some of those results but don't really see any 445 > activity. The SCS script doesn't find anything either. The PCs are > patched and virusscan updated. One PC when I connected to it did not > navigate to Windowsupdate website. I scheduled a Full McAfee scan as > their documentation suggests > ( > http://download.nai.com/products/mcafee-avert/documents/combating_w32_conficker_worm.pdf > ), > and sometime through the scan I was able to reach windowsupdate. I > don't know if it was a coincidence or not that I was not able to reach > the website. I haven't looked into the registry and any other places > for evidence of conficker. I will probably today but I am afraid it > maybe a waste of time since they are already patched and updated. > -- > Joe > > > > On Tue, Mar 31, 2009 at 5:48 AM, Eric Tykwinski > wrote: > > Joe, > > > > Here's the link for the Python Crypto toolkit: > > http://www.amk.ca/python/code/crypto.html > > > > I scanned our internal network and didn't find anything, so I can't > really > > vouch for it's reliablity though. > > -- To him who is able to keep you from falling and to present you before his glorious presence without fault and with great joy From sauron at the-infinite.org Tue Mar 31 15:43:19 2009 From: sauron at the-infinite.org (Dominic J. Eidson) Date: Tue, 31 Mar 2009 15:43:19 -0500 (CDT) Subject: The Confiker Virus. In-Reply-To: <500ffb690903311337h79de52d7vaacbbd449fed2ff@mail.gmail.com> References: <03AD93D590E44DCA986E2EAD7C6BD50B@jnpr.net> <002f01c9b0cb$0b0f6de0$0101a8c0@E520> <000001c9b0cc$c6126100$52372300$@com> <6cd462c00903301027y271d59b8x19387a00cca2419a@mail.gmail.com> <785694cd0903301546r2b34e1e8kafdd1d2af3e988ef@mail.gmail.com> <49D24059.F1D8.006C.0@sunshadeseyewear.com.au> <785694cd0903310641x325d14fct687ca85e04c8051f@mail.gmail.com> <500ffb690903311337h79de52d7vaacbbd449fed2ff@mail.gmail.com> Message-ID: See http://honeynet.org/node/388 for snort signatures for .a and .b variants. - d. On Tue, 31 Mar 2009, Steven Fischer wrote: > Is anyone aware of any network-based signatures that could be used to > identify and tag IP traffic, for dropping at the ingress/egress points? > > On Tue, Mar 31, 2009 at 9:41 AM, JoeSox wrote: > >> I am uncertain also. I scan a subnet on my network with Axence >> NetTools looking for 445 port and I receive some hits. I perform a >> netstat -a some of those results but don't really see any 445 >> activity. The SCS script doesn't find anything either. The PCs are >> patched and virusscan updated. One PC when I connected to it did not >> navigate to Windowsupdate website. I scheduled a Full McAfee scan as >> their documentation suggests >> ( >> http://download.nai.com/products/mcafee-avert/documents/combating_w32_conficker_worm.pdf >> ), >> and sometime through the scan I was able to reach windowsupdate. I >> don't know if it was a coincidence or not that I was not able to reach >> the website. I haven't looked into the registry and any other places >> for evidence of conficker. I will probably today but I am afraid it >> maybe a waste of time since they are already patched and updated. >> -- >> Joe >> >> >> >> On Tue, Mar 31, 2009 at 5:48 AM, Eric Tykwinski >> wrote: >> > Joe, >>> >>> Here's the link for the Python Crypto toolkit: >>> http://www.amk.ca/python/code/crypto.html >>> >>> I scanned our internal network and didn't find anything, so I can't >> really >>> vouch for it's reliablity though. >> >> > > > -- Dominic J. Eidson "Baruk Khazad! Khazad ai-menu!" - Gimli ---------------------------------------------------------------------------- http://www.dominiceidson.com/ From maillist at webjogger.net Tue Mar 31 16:43:01 2009 From: maillist at webjogger.net (Adam Greene) Date: Tue, 31 Mar 2009 17:43:01 -0400 Subject: TWC outage References: <3D4E543D15AB477DBD13B4C4C0F687FD@GINKGO> Message-ID: Thanks for various replies off-list which helped to troubleshoot this issue and possibly accelerate resolution. Time Warner attributed the issue to a routing loop on the Level 3 network caused by some work last night. Based on a traceroute from a Webjogger customer, the loop was in Chicago. As of about 4:45pm EDT things seem back to normal. Thanks! Adam -- Webjogger (845) 757-4000 ASN 20208 ----- Original Message ----- From: Adam Greene To: outages at outages.org ; nanog at nanog.org Sent: Tuesday, March 31, 2009 11:18 AM Subject: [outages] TWC outage Seems to be an outage with Time Warner Cable in the upstate New York area ... As far as I can tell, it's on AS7843. I'm awaiting callback from an engineer for details .... Adam -- Webjogger (845) 757-4000 ASN 20208 ====== C:\>tracert www.authorize.net Tracing route to www.authorize.net [64.94.118.77] over a maximum of 30 hops: 1 38 ms 1 ms 2 ms 10049.webjogger.net [204.8.80.49] 2 6 ms 6 ms 7 ms cpe-24-29-112-25.nyc.res.rr.com [24.29.112.25] 3 8 ms 7 ms 6 ms gig-12-2-nycmnyrdc-rtr1.nyc.rr.com [24.29.104.97] 4 7 ms 7 ms 8 ms gig1-0-0-nwrknjmd-rtr1.nyc.rr.com [24.29.130.182] 5 7 ms 7 ms 6 ms ae-4-0.cr0.nyc30.tbone.rr.com [66.109.6.78] 6 9 ms 8 ms 8 ms ae-1-0.pr0.nyc20.tbone.rr.com [66.109.6.163] 7 8 ms 9 ms 8 ms 66.109.9.210 8 * * * Request timed out. 9 * * * Request timed out. 10 * * * Request timed out. 11 * * * Request timed out. 12 * * * Request timed out. 13 * * * Request timed out. 14 * * * Request timed out. 15 * * * Request timed out. 16 * * * Request timed out. 17 * * * Request timed out. 18 * * * Request timed out. 19 * * * Request timed out. 20 * * * Request timed out. 21 * * * Request timed out. 22 * * * Request timed out. 23 * * * Request timed out. 24 * * * Request timed out. 25 * * * Request timed out. 26 * * * Request timed out. 27 * * * Request timed out. 28 * * * Request timed out. 29 * * * Request timed out. 30 * * * Request timed out. Trace complete. _______________________________________________ outages mailing list outages at outages.org https://puck.nether.net/mailman/listinfo/outages From schnizlein at isoc.org Tue Mar 31 16:49:18 2009 From: schnizlein at isoc.org (John Schnizlein) Date: Tue, 31 Mar 2009 17:49:18 -0400 Subject: TWC outage In-Reply-To: References: <3D4E543D15AB477DBD13B4C4C0F687FD@GINKGO> Message-ID: are you just a little early for April Fools? :-) On 2009Mar31, at 5:43 PM, Adam Greene wrote: > Based on a traceroute from a Webjogger customer, the loop was in > Chicago. From paul at ibsys.com Tue Mar 31 17:26:24 2009 From: paul at ibsys.com (Weier, Paul) Date: Tue, 31 Mar 2009 17:26:24 -0500 Subject: Hotmail/MSN/Live help? Message-ID: <514B41B4EB0E834EAFB17FA73E263B701B2F14D3@exch001.ibsys.com> My mail server is currently being blocked by Windows/Live/Hotmail even though I am (and have been for years) a member of Microsoft's JMRP and SNDS services. Not sure what changed after years of peaceful co-existence. Could someone from Windows Live Hotmail please contact me off list? TIA -- Paul Senior System Administrator Internet Broadcasting paul at ibsys.com Visit us at: www.ibsys.com This message may contain information that is privileged or confidential. If you receive this transmission in error, please notify the sender by reply email and delete the message and any attachment; and be advised that disclosing, copying, distributing or taking any action in reliance upon the content is prohibited. -- From joelja at bogus.com Tue Mar 31 18:11:46 2009 From: joelja at bogus.com (Joel Jaeggli) Date: Tue, 31 Mar 2009 16:11:46 -0700 Subject: Google Over IPV6 In-Reply-To: <49CCF9F7.8050704@foobar.org> References: <00d601c9aed6$2fc517d0$8f4f4770$@edu> <1238158743.17980.10.camel@daniel.office.bit.nl> <49CCE8C0.9080707@Janoszka.pl> <016c01c9aeed$2245ed20$66d1c760$@edu> <20090327152614.GB53235@ussenterprise.ufp.org> <49CCF9F7.8050704@foobar.org> Message-ID: <49D2A332.50703@bogus.com> Nick Hilliard wrote: > On 27/03/2009 15:26, Leo Bicknell wrote: >> AFAIK you have to have native peering with them to be part of the >> pilot. At least, you did when we signed up. They may have relaxed >> that since. > > According to a Google IPv6 talk I attended yesterday, they don't intend > to relax that rule. Tunneling ipv6 connectivity over ipv4 is trash > quality engineering and to be honest, its not a credible substitute for > adequate ipv6 infrastructure. Tunneling ipv4 over mpls is trash quality engineering and it's not a credible substitute for adequate ipv4 infrastructure. Everything is a tunnel... > Nick > From mmc at internode.com.au Tue Mar 31 19:56:27 2009 From: mmc at internode.com.au (Matthew Moyle-Croft) Date: Wed, 1 Apr 2009 11:26:27 +1030 Subject: Google Over IPV6 In-Reply-To: <49D2A332.50703@bogus.com> References: <00d601c9aed6$2fc517d0$8f4f4770$@edu> <1238158743.17980.10.camel@daniel.office.bit.nl> <49CCE8C0.9080707@Janoszka.pl> <016c01c9aeed$2245ed20$66d1c760$@edu> <20090327152614.GB53235@ussenterprise.ufp.org> <49CCF9F7.8050704@foobar.org> <49D2A332.50703@bogus.com> Message-ID: > > > Everything is a tunnel... Tube man. Everything is a tube... and Al Gore invented tubes. MMC > > >> Nick >> > > -- Matthew Moyle-Croft Internode/Agile Peering and Core Networks From kch670 at eecs.northwestern.edu Tue Mar 31 21:56:22 2009 From: kch670 at eecs.northwestern.edu (Kai Chen) Date: Tue, 31 Mar 2009 21:56:22 -0500 Subject: Can you see these AS links:) Message-ID: Hello folks, As part of a research project here at Northwestern, we have found quite a few unexpected AS-level links that do not appear in public available BGP tables. We really need your help in validating them; for anyone who knows links associated with any AS, if you can assist us with this please contact us off list. Thanks! - Kai From patrick at ianai.net Tue Mar 31 22:07:42 2009 From: patrick at ianai.net (Patrick W. Gilmore) Date: Tue, 31 Mar 2009 23:07:42 -0400 Subject: Can you see these AS links:) In-Reply-To: References: Message-ID: <88D03E61-31C6-455D-8055-A926D720DB95@ianai.net> On Mar 31, 2009, at 10:56 PM, Kai Chen wrote: > As part of a research project here at Northwestern, we have found > quite a > few unexpected AS-level links that do not appear in public available > BGP > tables. We really need your help in validating them; for anyone who > knows > links associated with any AS, if you can assist us with this please > contact > us off list. That's an interesting request. Most network operators know about AS adjacencies, since it is hard to be on the Internet without your AS having a link to at least one other. Do you expect everyone to ping you back? Also, what makes you think all adjacencies appear in "public available BGP tables"? Most do not. This is not surprising, it is expected. I'm interested to know why you think they would. -- TTFN, patrick