- NANOG - lists.nanog.org

Question about operational concerns with Routing Protocol Security
by Christopher Morrow 16 Nov '11

16 Nov '11

Howdy, while enjoying some (oddly not controversial) meeting time at the IETF, one of the presenters (Sam Hartman[1]) noted he's looking for some people to chat with with respect to 'deployment scenarios' surrounding network gear and protocol security. Today that probably takes the form of things like: "Hey, be sure to copy the password into the config before turning up the interfaces!" I can imagine other methods as well, for things like: eBGP iBGP ISIS OSPF would any of the folks on-list that currently have key material (passwords and such) configured for these protocols AND who also deploy new gear into the field be willing to chat some with Sam? (Note, you don't have to tell Sam your passwds/keys, and you don't have to tell anyone else that the passwd is 'chocolate' either...) Thanks! -Chris (also, note that I copied in at least one of Sam's emails, maybe this one won't get too filtered...) [1]: The draft Sam could use some advice on: <http://tools.ietf.org/id/draft-ietf-karp-ops-model-01.txt>

1 0

Minimum Allocation Size by RIRs (IPv4)
by Fredy Kuenzler 16 Nov '11

16 Nov '11

I'm trying to compile a comprehensive and up-to-date list of Minimum Allocation Sizes by the various RIRs. Any hint would be appreciated. I have so far: ARIN: https://www.arin.net/knowledge/ip_blocks.html APNIC: http://www.apnic.net/publications/research-and-insights/ip-address-trends/m… (seems that they have recently changed from /22 to /24, which is not too helpful...) RIPE NCC: http://www.ripe.net/ripe/docs/ripe-510#5 Nothing found for AFRINIC and LACNIC yet, and legacy space, too. -- Fredy Künzler Init Seven AG AS13030 Elias-Canetti-Strasse 7 CH-8050 Zürich Skype: flyingpotato Phone: +41 44 315 4400 Fax: +41 44 315 4401 Twitter: @init7 http://www.init7.net/

6 5

FW: Savvis broken link / underperforming between DC and Atlanta?
by Lorell Hathcock 16 Nov '11

16 Nov '11

All: I did not see a reply to this. Anyone else having a problem on this link? Lorell From: Lorell Hathcock [mailto:lorell@hathcock.org] Sent: Friday, November 11, 2011 9:10 AM To: nanog(a)nanog.org Subject: Savvis broken link / underperforming between DC and Atlanta? Any one else seeing this? This was done yesterday from Hawaii. tracert speedtest.saas.infor.com 3 5 ms 5 ms 4 ms ip64-75-240-210.aloha.net [64.75.240.210] 4 5 ms 5 ms 5 ms hnl-edge-02.inet.qwest.net [67.129.94.69] 5 * * * Request timed out. 6 56 ms 56 ms 56 ms 63-235-40-18.dia.static.qwest.net [63.235.40.18] 7 58 ms 58 ms 59 ms cr1-tenge-0-3-5-0.sanfrancisco.savvis.net [204.70.200.198] 8 138 ms 138 ms 138 ms cr1-bundle-pos2.Washington.savvis.net [204.70.200.90] 9 135 ms 136 ms 136 ms hr1-tengig-2-0-0.sterling2dc2.savvis.net [204.70.197.74] 10 139 ms 136 ms 137 ms 165.193.78.106 11 * * * Request timed out. 12 * * * Request timed out. 13 * * * Request timed out. But from Houston it was fine yesterday. It took a different route. Today I have the same problem from Houston. tracert speedtest.saas.infor.com 4 2 ms 2 ms 2 ms te4-1.3509.ccr01.iah02.atlas.cogentco.com [66.28.6.21] 5 3 ms 2 ms 2 ms te0-2-0-4.ccr21.iah01.atlas.cogentco.com [154.54.3.149] 6 9 ms 10 ms 8 ms te0-1-0-5.ccr21.dfw01.atlas.cogentco.com [154.54.2.225] 7 8 ms 8 ms 8 ms te7-3.mpd01.dfw03.atlas.cogentco.com [154.54.6.66] 8 15 ms 8 ms 12 ms aer1-ge-4-2.dallasequinix.savvis.net [208.175.175.5] 9 17 ms 8 ms 15 ms 204.70.207.182 10 10 ms 9 ms 10 ms cr1-tengig0-7-5-0.Dallas.savvis.net [204.70.200.170] 11 37 ms 37 ms 37 ms cr1-tengig-0-7-0-0.Washington.savvis.net [204.70.196.105] 12 36 ms 36 ms 36 ms hr1-tengig-2-0-0.sterling2dc2.savvis.net [204.70.197.74] 13 37 ms 36 ms 37 ms 165.193.78.106 14 * * * Request timed out. 15 * * * Request timed out. 16 * * * Request timed out. This the end IP address is in Rackspace in Atlanta I am told. Known issues out there? Any de-peering going on? Or is this just a firewall or private IP space that is not responding to traceroute information requests? Thanks for any help, Lorell Hathcock

1 0

Packets dropped passing from Qwest to Verizon
by Tim Heckman 15 Nov '11

15 Nov '11

Hello, I'm looking looking for a POC at Qwest (AS209) or Verizon (AS701) to help diagnose what looks like a stale bogon filter. The packets drop where Qwest (63.146.26.210) peers with Verizon (152.63.2.130). Thanks in advance! Regards, Tim H.

1 0

Re: Cell-based OOB management devices
by rcheung＠rochester.rr.com 15 Nov '11

15 Nov '11

David, a Sprint aircard can be had with a static-ip, so that should ease remote connectivity requirements. Or, you can opt for the Datalink (private VPN) service, which separates your aircard traffic from other customers within a VRF, obviating the need to run a separate VPN client. -RC ---- David Hubbard <dhubbard(a)dino.hostasaurus.com> wrote: > Hi all, I am looking at cellular-based devices as a higher > speed alternative to dial-up backup access methods for > out of band management during emergencies. I was > wondering if anyone had experiences with such devices > they could share? > > Devices I've found include Sierra Wireless AirLink Raven X, > Digi's ConnectWAN 3G or 4G and Opengear's ACM5004-G. I > have no experience with any but they all appear to support > the Sprint network which I assume would be ideal due to > not having usage caps on data (currently). The Opengear > device runs linux and has four serial ports, a usb port > for additional storage and ethernet, so it seems to have > some small advantages over the others since it could double > as an emergency self-contained management station you can > SSH into and run diagnostics from. All appear to have > VPN/gateway support. > > What none of them are clear on is how you would connect > to it over cellular since I assume you're just paying for > a typical data plan and it will randomly obtain IP > addresses. Maybe some type of dynamic dns service so you > can easily figure out your device's current IP? How > stable is the access to the device? Any idea if any of > them can do ipv6? > > Thanks! > > David > >

3 3

Ok; let's have the "Does DNAT contribute to Security" argument one more time...
by Jay Ashworth 15 Nov '11

15 Nov '11

Kill this subject if you're sick of it. ----- Original Message ----- > From: "Gabriel McCall" <Gabriel.McCall(a)thyssenkrupp.com> > If your firewall is working > properly, then having public addresses behind it is no less secure > than private. And if your firewall is not working properly, then > having private addresses behind it is no more secure than public. This assertion is frequently made -- it was made a couple other times this morning -- but I continue to think that it doesn't hold much water, primarly because it doesn't take into account *the probability of various potential failure modes in a firewall*. The basic assertion made by proponents of this theory, when analyzed, amounts to "the probability that a firewall between a publicly routable internal network and the internet will fail in such a fashion as to pass packets addressed to internal machines is of the same close order as the probability that a DNAT router will fail in such a fashion as to allow people outside it to address packets to *arbitrary* internal machine IP addresses (assuming they have any way to determine what those are)." Hopefully, my rephrasing makes it clearer why those of us who believe that there is, in fact, *some* extra security contributed by RFC 1918 and DNAT in the over all stack tend not to buy the arguments of those who say that in fact, it contributes none: they never show their work, so we cannot evaluate their assertions. But in fact, as someone pointed out this morning in the original thread: even if you happen to *know* the internal 1918 IP of the NATted target, the default failure mode of the NAT box is "stop forwarding packets into private network at all". Certainly, individual NAT boxes can have other failure modes, but each of those extra layers adds at least another 0 to the probability p-number, in my not-a-mathematician estimation. On the other hand, since a firewall's job is to stop packets you don't want, if it stops doing it's just as a firewall, it's likely to keep on doing it's other job: passing packets. It certainly depends on the fundamental design of the firewall, which I can't speak to generally... but you proponents of "NAT contributes no security" can't, either. > That makes sense, but I'm wondering if that should be considered correct > behavior. Obviously a non-consumer grade router can have rules defining > what is/isn't PATed in or out, but a Linksys/D-Link/etc should expect > everything coming from the outside in to either a) match up with > something in the translation table, b) be a service the router itself is hosting > (http, etc), or c) be a port it explicitly forwards to the same inside > host. > Anything not matching one of those 3 categories you'd think could be > dropped. Routing without translating ports and addresses seems like > the root of the issue. It is. And IME, the people who think NAT provides no security rarely if ever seem to address that aspect of the issue. And, for what it's worth, I'm discussing the common case: 1-to-many incoming DNAT; rerouting specific TCP or UDP ports to internal machines, possibly on other ports. Cheers, -- jra -- Jay R. Ashworth Baylink jra(a)baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274

14 16

Cell-based OOB management devices
by David Hubbard 15 Nov '11

15 Nov '11

Hi all, I am looking at cellular-based devices as a higher speed alternative to dial-up backup access methods for out of band management during emergencies. I was wondering if anyone had experiences with such devices they could share? Devices I've found include Sierra Wireless AirLink Raven X, Digi's ConnectWAN 3G or 4G and Opengear's ACM5004-G. I have no experience with any but they all appear to support the Sprint network which I assume would be ideal due to not having usage caps on data (currently). The Opengear device runs linux and has four serial ports, a usb port for additional storage and ethernet, so it seems to have some small advantages over the others since it could double as an emergency self-contained management station you can SSH into and run diagnostics from. All appear to have VPN/gateway support. What none of them are clear on is how you would connect to it over cellular since I assume you're just paying for a typical data plan and it will randomly obtain IP addresses. Maybe some type of dynamic dns service so you can easily figure out your device's current IP? How stable is the access to the device? Any idea if any of them can do ipv6? Thanks! David

7 6

Re: airgap / negligent homicide charge
by Mickey Fox 15 Nov '11

15 Nov '11

The determination of whether a failure rises to the level of negligent homicide will require a review of industry standards, company standards and sometimes straight common-sence. If the industry standard is airgap re security you are probably okay so long as you review and address the very concerns and questions you are raising in a responsible fashion that does not rely solely on expediency, cost, etc., but looks to real-world scenarios and emergency / backup procedures, equipment, testing and training. Mickey Fox CMK Consulting Services On Nov 14, 2011 9:00 AM, <nanog-request(a)nanog.org> wrote: > Send NANOG mailing list submissions to > nanog(a)nanog.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://mailman.nanog.org/mailman/listinfo/nanog > or, via email, send a message with subject or body 'help' to > nanog-request(a)nanog.org > > You can reach the person managing the list at > nanog-owner(a)nanog.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of NANOG digest..." > > > Today's Topics: > > 1. Re: Arguing against using public IP space > (Valdis.Kletnieks(a)vt.edu) > 2. Re: Arguing against using public IP space (Joel jaeggli) > 3. Re: Arguing against using public IP space (Jimmy Hess) > 4. Re: Arguing against using public IP space (Owen DeLong) > 5. Re: Arguing against using public IP space (Dobbins, Roland) > 6. Cable standards question (Sam (Walter) Gailey) > 7. Re: Cable standards question (Daniel Seagraves) > 8. Re: Arguing against using public IP space (Joe Greco) > 9. Re: Arguing against using public IP space (Ray Soucy) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 13 Nov 2011 21:43:32 -0500 > From: Valdis.Kletnieks(a)vt.edu > To: Brett Frankenberger <rbf+nanog(a)panix.com> > Cc: NANOG <nanog(a)nanog.org> > Subject: Re: Arguing against using public IP space > Message-ID: <81357.1321238612(a)turing-police.cc.vt.edu> > Content-Type: text/plain; charset="us-ascii" > > On Sun, 13 Nov 2011 19:14:59 CST, Brett Frankenberger said: > > > What if you air-gap the SCADA network of which you are in > > administrative control, and then there's a failure on it, and the people > > responsible for troubleshooting it can't do it remotely (because of the > > air gap), so the trouble continues for an extra hour while they drive > > to the office, and that extra hour of failure causes someone to die. > > Should that result in a homicide charge? > > If you designed a life-critical airgapped network that didn't have a > trained > warm body at the NOC 24/7 with an airgapped management console, and hot > (or at > least warm) spares for both console and console monkey, yes, you *do* > deserve > that negligent homicide charge. > > >

3 2

equinix sv3 provider recommendations
by Jon Heise 15 Nov '11

15 Nov '11

I'm setting up internet connectivity in the equinix SV3 datacenter, we are already a level3 customer what other providers have been reliable from sv3.

1 0

Re: packet loss out of Texas on Cogent and GlobalCrossing
by Charles Gagnon 15 Nov '11

15 Nov '11

Good point, I can't seem to reproduce with the looking glass interfaces out there. They either don't use enough packets in sequence or don't through the problem hops. On this path: Send ICMP echos to 24.227.216.194, timeout is 2 seconds, maximum hops are 32,1 0ms 1ms 0ms 74.201.153.2212 143ms 10ms 0ms 216.52.95.893 1ms 1ms 1ms 77.67.70.974 1ms 1ms 1ms 213.200.66.2105 3ms 1ms 2ms 66.198.111.976 19ms 7ms 7ms 216.6.87.97 7ms 7ms 7ms 216.6.87.28 6ms 7ms 7ms 66.198.154.149 6ms 7ms 6ms 107.14.19.13210 107ms 108ms 113ms 66.109.10.1111 118ms 144ms 120ms 107.14.17.13912 119ms 120ms 120ms 72.179.205.5913 115ms 115ms 114ms 24.73.240.19514 115ms 115ms 115ms 24.73.240.252 I re-tested and using 100 msg counts, I get 3-6% packet loss on anything after 10. On hops 1-10, I'm all clean. That 66.109.10.11 address is inside TimeWarner/RR so I'll keep trying to contact them. On Mon, Nov 14, 2011 at 2:23 PM, Eric Tykwinski <eric-list(a)truenet.com> wrote: > Have you check the relevant looking glass sites? > > http://www.cogentco.com/en/network/looking-glass > http://www.globalcrossing.com/network/network_looking_glass.aspx > > We are connected to both providers, so everything is looking clean for us. > > Sincerely, > > Eric Tykwinski > TrueNet, Inc. > P: 610-429-8300 > F: 610-429-3222 > > -----Original Message----- > From: Charles Gagnon [mailto:charlesg@unixrealm.com] > Sent: Monday, November 14, 2011 2:11 PM > To: nanog(a)nanog.org > Subject: packet loss out of Texas on Cogent and GlobalCrossing > > I need the Nanog intellect, > > We are seeing packet loss in certain scenarios only on traffic to and from > Austin, TX. The local provider is Time Warner and they are not having > (obvious) problems. We ran tests from NY and NJ over Internap and AboveNet > connections.We only see problems when the traffic goes over gblx or cogent. > Has anyone heard of problem with these carriers out of Texas? > -- > Charles Gagnon > charlesg at unixrealm.com > > > -- Charles Gagnon charlesg at unixrealm.com

2 1