- NANOG - lists.nanog.org

Re: [Fwd: Kremen VS Arin Antitrust Lawsuit - Anyone have feedback?]
by Johnny Eriksson 13 Sep '06

13 Sep '06

"D'Arcy J.M. Cain" <darcy(a)druid.net> wrote: > If we were still calling central and asking "Hi Mabel, can you put me > through to Doc," no one would give a rat's ass about phone number > portability. Notice that no one is getting worked up about circuit > number portability. ... or street number portability. Thanks $deity. --Johnny

4 3

Re: [routing-wg]BGP Update Report
by Vince Fuller 13 Sep '06

13 Sep '06

On Mon, Sep 11, 2006 at 12:32:57PM +0200, Oliver Bartels wrote: > Hi Gert, > On Fri, 8 Sep 2006 18:06:00 +0200, Gert Doering wrote: > >Ummm, well, this is a damn fast plane if it will reach another continent > >1843 times per day (or even "per week")... - which should be the only > >time the BGP announcement moves. > > > >Sounds more like "the BGP-follows-plane system has some stability problems". > > Nack. > > Probably they are using low or medium earth orbit satellites, which > _are_ damn fast in orbit. Otherwise the round trip time would be > unacceptably high. > > As the whole thing is 3D, some of them might have contact to > ground stations on this or the other side of the great lake, > depending on their 3D position, even thru the plane travels > on a well defined track (probably a 3D circle, too) in just one > direction only. > > Ceterum censeo: Nevertheless this moving-clients application shows > some demand for a true-location-independend IP-addresses > announcement feature (provider independend "roaming") in IPv6, > as in v4 (even thru this isn't the "standard" way, but Connexion is > anything but standard). Shim etc. is not sufficient ... One might also imagine that more globally-friendly way to implement this would have been to build a network (VPN would be adequate) between the ground stations and assign each plane a prefix out of a block whose subnets are only dynamically advertsed within that network/VPN. Doing that would prevent the rest of the global Internet from having to track 1000+ routing changes per prefix per day as satellite handoffs are performed. --Vince

2 1

Re: [routing-wg]BGP Update Report
by Vince Fuller 13 Sep '06

13 Sep '06

> On Mon, Sep 11, 2006 at 10:28:49AM -0700, Vince Fuller wrote: > > One might also imagine that more globally-friendly way to implement this > > would have been to build a network (VPN would be adequate) between the > > ground stations and assign each plane a prefix out of a block whose subnets > > are only dynamically advertsed within that network/VPN. Doing that would > > prevent the rest of the global Internet from having to track 1000+ routing > > changes per prefix per day as satellite handoffs are performed. > > As has been said before, and is also readable in that blog entry: the > system is supposed to create *one* advertisement change when the plane > is crossing from the "Europe" to the "US" ground station (etc.), not > 1000+. The comment still applies. Imagine that this system were implemented globally on all international/intercontinental air routes. It would still be nice to avoid having each of those airplanes cause a globally-visible routing update whenever it crosses some geographical boundary. --Vince

3 2

Re: Kremen's Buddy?
by Scott Weeks 13 Sep '06

13 Sep '06

----- Original Message Follows ----- From: Stephane Bortzmeyer <bortzmeyer(a)nic.fr> > On Tue, Sep 12, 2006 at 08:46:11PM -0400, > Joe Abley <jabley(a)ca.afilias.info> wrote > > to dissect a core dump, or how BGP works, but who at the > > same time are not interested in reading the ARIN policy > manual before making a request for resources. > > I may be very special but I find learning a new > programming language or a new protocol much more fun than > reading thick and boring policy documents. Have you read the ARIN info regarding IPv4 allocations? If so, you're calling a few pages 'thick'. scott

1 0

Senate Hearings on ICANN
by Fergie 13 Sep '06

13 Sep '06

I only post this becuase of the ongoing thread re: Kremin v. ARIN. The Senate Committee on Commerce, Science and Transportation Subcommittee on Trade, Tourism, and Economic Development has announced a hearing on Internet Governance: The Future of ICANN. Wednesday, September 20th at 10:00 a.m. http://commerce.senate.gov/public/index.cfm?FuseAction=Hearings.Hearing&Hea… (Props to Bret Fausett.) - ferg -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/

1 0

allocations from ARIN was Re: Kremen's Buddy?
by Scott Weeks 13 Sep '06

13 Sep '06

----- Original Message Follows ----- From: Richard A Steenbergen <ras(a)e-gerbil.net> > Ever notice the only folks happy with the status quo are > the few who have already have an intimate knowledge of > the ARIN allocation process, and/or have the right > political connections to resolve the "issues" that come up > when dealing with them? > > Try looking at it from an outsider's point of view > instead. If you're new to dealing with ARIN, it is not > uncommon to find the process is absolutely baffling, > frustrating, slow, expensive, and requiring intrusive > disclosure just shy of an anal cavity probe. I am new to personally dealing with ARIN as of 1.5 years ago. I have had to get 5 seperate allocations in that time. I don't find this to be the case at all. They were very helpful and I was diligent in getting the things together necessary for the allocations and in my responses. It felt to me like teamwork rather than me against them. And, no, I didn't have to offer anyone free trips to Hawaii. ;-) scott

1 0

Re: ip reclamation was Re: Kremen's Buddy?
by Scott Weeks 13 Sep '06

13 Sep '06

----- Original Message Follows ----- From: "william(at)elan.net" <william(a)elan.net> > >> The fact that there is a lot of space > assigned/allocated >> and not used in any easily > observable way is well known >> to those who track the > address exhaustion issue, I >> think. > > How much, though, is used, but not routed publically? > Simple math from above: > Allocated & Not Routed: 3118838 (/24 blocks) - 21% I believe I wasn't clear. I meant to say, what fraction of this is in actual use, but not publically routed as opposed to the percent allocated and not in use, say, by defunct companies. > > Something that has been brought up from time to time > > here. It's not easily observable, but allowed. > > Not easily observable means some ip blocks maybe used but > are not adverised in public BGP. This is a bit of an > issue with certain part of US Gov. This is what I was getting at, but you've given an upper bound (21%) and I'm positive it's not even close to that. Still, it reduces the 21% to a amaller number. scott

1 0

Cisco IOS VTP issues (fwd)
by Gadi Evron 13 Sep '06

13 Sep '06

---------- Forwarded message ---------- Date: Wed, 13 Sep 2006 14:18:41 +0200 From: FX <fx(a)phenoelit.de> To: bugtraq(a)securityfocus.com, full-disclosure(a)lists.grok.org.uk, darklab(a)darklab.org Subject: Cisco IOS VTP issues Phenoelit Advisory <wir-haben-auch-mal-was-gefunden #0815 +---+> [ Title ] Cisco Systems IOS VTP multiple vulnerabilities [ Authors ] FX <fx(a)phenoelit.de> Phenoelit Group (http://www.phenoelit.de) Advisory http://www.phenoelit.de/stuff/CiscoVTP.txt [ Affected Products ] Cisco IOS and CatOS Tested on: C3550 IOS 12.1(19) Cisco Bug ID: CSCei54611 CERT Vu ID: <not assinged> [ Vendor communication ] 06.07.05 Initial Notification, gaus(a)cisco.com 12.07.05 PSIRT member Wendy Garvin <wgarvin(a)cisco.com> took over 14.07.05 Wendy states the there is a fix for one of the issues 19.07.05 According to Wendy, Cisco has trouble reproducing the issues and finding the affected code 27.07.05 Wendy notifies FX about fixed code 12.09.06 Phenoelit advisory goes to Cisco (FX just forgot about it, too much to hack, too little time, but the PSIRT party in Vegas was a good reminder) 13.09.06 Final advisory going public as coordinated release [ Overview ] Cisco Systems IOS contains bugs when handling the VLAN Trunking Protocol (VTP). Specially crafted packets may cause Denial of Service conditions, confusion of the network operator and a heap overflow with the possibility for arbitrary code execution. [ Description ] Cisco IOS suffers from several bugs in the VTP handling code. All issues require VTP to be in server or client mode. Transparent mode (default) is not affected. Issue 1: Denial of Service When sending a VTP version 1 summary frame to a Cisco IOS device and setting the VTP version field to value 2, the device stops working. Apparently, the VTP handling process will loop and is terminated by the systems watchdog process, reloading the device. Issue 2: Integer wrap in VTP revision If an attacker can send VTP updates (summary and sub) to a Cisco IOS or CatOS device, he can choose the revision of the VTP information. A revision of 0x7FFFFFFF will be accepted by IOS. When the switchs VLAN configuration is changed by an operator, IOS increases the revision, which becomes 0x80000000 and seems to be internally tracked by a signed integer variable. The revision is therefore seen as large negative value. From this point in time on, the switch will not be able to communicate changed VLAN configurations, since the generated updates will be rejected by all other switches. Issue 3: VLAN name heap overflow If an attacker can send VTP updates to a Cisco IOS device, the type 2 frames contain records for each individual VLAN in the update. One field of the VTP records contains the name of the VLAN, another field the length of this name. Sending an update with VLAN name above 100 bytes and correctly reflecting the length in the VLAN name length field causes a heap overflow. The overflow can be exploited to execute arbitrary code on the receiving switch. The maximum length of a VLAN name in VTP is 255 bytes. [ Example ] The following is an example frame for issue 3. The appropriate VTP summary advertisement (type 1) must be sent before this frame. IEEE 802.3 Ethernet Destination: CDP/VTP (01:00:0c:cc:cc:cc) Source: <any> Length: 260 Logical-Link Control Virtual Trunking Protocol Version: 0x01 Code: Subset-Advert (0x02) Sequence Number: 1 Management Domain Length: 5 Management Domain: AAAAA Configuration Revision Number: 3 VLAN Information VLAN Information Length: 212 Status: 0x00 VLAN Type: Ethernet (0x01) VLAN Name Length: 200 ISL VLAN ID: 0x0001 MTU Size: 1500 802.10 Index: 0x000186a1 VLAN Name: AAAAA[...]AAAAAA (200 in total) 0000 01 00 0c cc cc cc 00 fe fe c0 01 00 01 04 aa aa ...........^.... 0010 03 00 00 0c 20 03 01 02 01 05 41 41 41 41 41 00 .... .....AAAAA. 0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0030 00 00 00 00 00 00 00 00 00 00 00 00 00 03 d4 00 ................ 0040 01 c8 00 01 05 dc 00 01 86 a1 41 41 41 41 41 41 ..........AAAAAA 0050 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA 0060 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA 0070 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA 0080 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA 0090 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA 00a0 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA 00b0 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA 00c0 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA 00d0 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA 00e0 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA 00f0 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA 0100 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA 0110 41 41 AA [ Notes ] The VTP management domain is needed for the summary advertisement to be correct. This information is distributed via CDP if enabled. The attacker has to be on a trunk port for VTP frames to be accepted. The Dynamic Trunk Protocol (DTP) can be used to become a trunking peer. [ Solution ] Cisco Systems provides fixed software, which can be found based on the following bug IDs: CSCsd52629/CSCsd34759 -- VTP version field DoS CSCse40078/CSCse47765 -- Integer Wrap in VTP revision CSCsd34855/CSCei54611 -- Buffer Overflow in VTP VLAN name In general, it is recommended to configure a shared VTP password, which will be used in an MD5 hash to protect the summary advertisement. [ end of file ($Revision: 1.1 $) ] -- FX <fx(a)phenoelit.de> Phenoelit (http://www.phenoelit.de) 672D 64B2 DE42 FCF7 8A5E E43B C0C1 A242 6D63 B564

1 0

Re: Watch your replies (was Kremen....)
by Frank Coluccio 13 Sep '06

13 Sep '06

Perhaps the list should be turned into a wiki; and no, while I'd like to, I'm not at this time volunteering to admin ;) Frank A. Coluccio DTI Consulting Inc. 212-587-8150 Office 347-526-6788 Mobile On Wed Sep 13 15:43 , Michael.Dillon(a)btradianz.com sent: > >> It's insulting >> when you trim the message to a shorter statement that you are >> responding to. The other 18 lines may not have been important to this >> particular response but they were not content free. > >If your content was in any way, interesting, then people >will have read it in the message that you posted. I see >no need to repeat a bunch of irrelevant text when I am >only replying to one point in your email. > >Personally, I wish more people would trim away all the >irrelevant junk when replying. > >On the other hand, in the corporate world I find that >the habit of top posting is very useful to me. I often >see things that were never intended to be sent to me >and I often discover that the previous replies in a thread >betray the fact that the writer did not read or did not >understand the original message. > >But on a mailing list, trimmed replies are superior. > >--Michael Dillon > >P.S. are the standards of this list so unclear that >Darcy and I have to discuss this? Who is right? > >

1 0

Bandwidth accounting recommendation?
by Drew Weaver 13 Sep '06

13 Sep '06

Hi, I have been scouring the net searching for a good bandwidth accounting solution that would be appropriate for a hosting provider/carrier. We are more interested in the total amount of bandwidth the user has utilized in a 7/30/90/365 (whatever) day period of time than a Mbps 'graph' which MRTG would give you. It would also be great if it could allow us to assign logins to our users so they can view their utilization. So far I've looked at MRTG, Cacti, and RTG. Cacti was pretty good execept it doesn't appear to notice changes in a switch, sometimes more than 30 ports on 5 different switches change a day and we'd like something that automatically starts/stops monitoring utilization when the port status changes. I havent found a Netflow tool yet that I really like. Any suggestions? Thanks, Andrew

2 1