- NANOG - lists.nanog.org

Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space
by Roger Marquis 10 Feb '09

10 Feb '09

Seth Mattinen wrote: > Far too many people see NAT as synonymous with a firewall so they think > if you take away their NAT you're taking away the security of a firewall. NAT provides some security, often enough to make a firewall unnecessary. It all depends on what's inside the edge device. But really, I've never heard anyone seriously equate a simple NAT device with a firewall. People do, and justifiably, equate NAT with the freedom to number, subnet, and route their internal networks however they choose. To argue against that freedom is anti-consumer. Continue to ignore consumer demand and the marketplace will continue to respond accordingly. Give consumers a choice (of NAT or not) and they will come (to IPv6). It's just about as simple as that. Well, that and a few unresolved issues with CAMs, routing tables, and such. Roger Marquis

18 37

unsolicited name transfers from Godaddy
by Zaid Ali 10 Feb '09

10 Feb '09

I have been receiving a high number of unsolicited domain transfer requests from Godaddy and have also written to Godaddy support about unsolicited domain transfer requests. Since I am not a Godaddy customer I got a standard talk to the hand. I have colleagues confirming that some similar chatter is also happening in the ICANN space with respect to Godaddy. Are folks here experiencing this also? Thanks, Zaid

1 0

Re: BGP Session Teardown due to AS_CONFED_SEQUENCE in AS4_PATH
by Eloy Paris 10 Feb '09

10 Feb '09

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Rob, Eloy Paris from the Cisco PSIRT here. Please see below (inline) for some comments regarding the issue you brought up in your email to the cisco-nsp and nanog mailing lists this past Jan. 16th: On Fri Jan 16 07:57:52 2009, Rob Shakir wrote: > Strict RFC 4893 (4-byte ASN support) BGP4 implementations are > vulnerable to a session reset by distant (not directly connected) > ASes. This vulnerability is a feature of the standard, and unless > immediate action is taken an increasingly significant number of > networks will be open to attack. Accidental triggering of this > vulnerability has already been seen in the wild, although the limited > number of RFC 4893 deployments has limited its effect. > > Summary: > It is possible to cause BGP sessions to remotely reset by injecting > invalid data into the AS4_PATH attribute provided to store 4-byte ASN > paths. Since AS4_PATH is an optional transitive attribute, the invalid > data will be transited through many intermediate ASes which will not > examine the content. To be vulnerable, an operator does not have to > be actively using 4-byte AS support. This problem was first reported > by Andy Davidson on NANOG in December 2008 [0], furthermore we have > been able to demonstrate that a device running Cisco IOS release > 12.0(32)S12 behaves as per this description. > > Details: [...] Cisco Bug CSCsx10140 was filed for Cisco IOS. Cisco IOS behaves exactly as you described - upon receipt of AS_CONFED_SEQUENCE data in the AS4_PATH attribute IOS will send a NOTIFICATION message to the peer, which causes a termination of the BGP session. After the fix for this bug IOS will ignore AS_CONFED_SEQUENCE data in the AS4_PATH attribute of received BGP UPDATE messages and continue to process the UPDATE. This is the new behavior that the revised RFC 4893 will require. CSCsx18598 was filed for Cisco IOS XR. Cisco IOS XR doesn't reset the session but accepts and forwards the invalid AS4_PATH data, so this bug was filed to change this behavior. CSCsx23179 was filed for Cisco NX-OS (for the Nexus switches.) Cisco NX-OS behaves like IOS (it will reset the BGP session when it sees AS_CONFED_SEQUENCE data in the AS4_PATH attribute), and this bug was filed to change this and have the BGP implementation in Cisco NX-OS follow the revised RFC 4893. The Release Notes for each bug may have some additional information. These are available via the Bug Toolkit on cisco.com (http://tools.cisco.com/Support/BugToolKit) To date, the only version of Cisco IOS that supports 4-byte AS numbers is 12.0(32)S12, released in late December. A fix to the 12.0(32)Sxx branch has been committed so the next 12.0(32)S-based release will have the fix. 12.0(32)SY8 is coming out soon, and it will also have support for 4-byte AS numbers, as well as the fix for the problem. Thanks for bringing attention to this issue and for working with us, specifically with the Cisco TAC, to get to the bottom of it and test the proposed fix. Cheers, - -- Eloy Paris Cisco PSIRT -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkmR9OoACgkQagjTfAtNY9jv5ACgg3fKuuWKv38h8F8d8QHBML5J CTsAnAnGMB/fBIQhk5z4E922JlhHVU5A =FSOP -----END PGP SIGNATURE-----

1 0

[NANOG-announce] NANOG45 Updates
by Betty J. Burke 10 Feb '09

10 Feb '09

Dear Community... One more thank you to Terremark for hosting NANOG45, and to all those in the Dominican Republic who made our stay a bit more enjoyable. However, it sure is nice to be home. Before moving on to our next adventure together, a few pieces of closure information for NANOG45 follows: <http://www.surveymonkey.com/s.aspx?sm=xAI_2bhyaMaWjl2diOG8lBKQ_3d_3d> Survey open until Friday, February 13, be sure you completed yours!! http://nanog.org/meetings/nanog45/agenda.php Now includes the video archive Meeting attendance and survey information will be posted in approximately 2 weeks. Moving forward, we are excited about NANOG46 in Philly! and look forward to seeing everyone there. Sincerely, Betty Merit NANOG Community Project Manager _______________________________________________ NANOG-announce mailing list NANOG-announce(a)nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce

1 0

Is whois.apnic.net down?
by Dale Carstensen 10 Feb '09

10 Feb '09

I get "Connection timed out" on whois commands to it.

2 1

New IPv4 blocks allocated to RIPE NCC
by Alex Le Heux 10 Feb '09

10 Feb '09

[Apologies for duplicate mails] Dear Colleagues, The RIPE NCC received the IPv4 address ranges 109/8 and 178/8 from the IANA in January 2009. We will begin allocating from these ranges in the near future. The minimum allocation size from these two /8s has been set at /21. You may wish to adjust any filters you have in place accordingly. More information on the IP space administered by the RIPE NCC can be found at: https://www.ripe.net/ripe/docs/ripe-ncc-managed-address-space.html Please also note that several "pilot" prefixes are being announced from each /8. These prefixes are: 178.0.0.0/16, pingable 178.0.0.1 178.1.0.0/21, pingable 178.1.0.1 178.1.24.0/24, pingable 178.1.24.1 109.0.0.0/16, pingable 109.0.0.1 109.1.0.0/21, pingable 109.1.0.1 109.1.24.0/24, pingable 109.1.24.1 They all originate in AS12654. More information on this "pilot" activity is available in the document "De-Bogonising New Address Blocks", which can be found at: http://www.ripe.net/ripe/docs/ripe-351.html Best regards, Alex Le Heux RIPE NCC Policy Implementation Co-ordinator

1 0

IPv6 delivery model to end customers
by Mikael Abrahamsson 10 Feb '09

10 Feb '09

I didn't know where to jump in in the current discussion and what I wanted to discuss was quite general, so I thought I'd create a new thread instead. So, anyone saying IPv6 is ready for prime-time whereever IPv4 is used, has a very simplified view of the world. Yes, IPv6 works in the classic routed network model where everything is statically set up (often manually), for example with an ISP run CPE and static/dynamic routing and a fixed /48 issued for that customer and SWIPed. Then it's easy to delegate reverse-DNS etc to the customer DNS. Now, take for instance the residential LAN case. There are several models on how to do this, but they all (that I know of) reside around the fact that each customer gets one or more globally routed IP address via DHCP, and security against spoofing and "man in the middle"-attacks is either done via forced-forwarding in the L2 device the customer connects to, or it's done via setting L3 accesslists learnt via DHCP snooping that inspect L2-packets in that same device. Often both is done, and also things like "ARP inspection", rogue dhcp server protection, MAC-rewrite etc is used. These are essential security mechanisms because customers should be protected from each other when it comes to these types of L2 attacks. Tracability (who had what IP at what time) is done via DHCP option82 and logging of this information. So, the L2 devices closest to the customer does a lot of "magic". All of these mechanisms were developed in the first half of the last decade. Now, with IPv6 this model changes drastically. The proposed mechanisms for IP number handout etc, is RA and DHCPv6. How does that fit into the model above? It doesn't, and the L2 devices surely won't "sniff" it and enforce security measures mentioned above. My ideal model would be to replace the above mentioned L2 device with a small and simple L3 device (L3 switch) with very small TCAM (TCAM size 6-8 times port number should be enough), where this device uses link-local with the CPEs (would require all customers to actually have a router at home), hands out prefixes via DHCPv6-PD, inserts route towards customer link-local address, provisions anti-spoofing ACLs on that port, logs what prefix was given out to each port at what time, and off we go. (Rationale for link-local only is to have only customer devices in "Customer IP space" and only ISP infrastructure in that IP-space. This is equivalent to "ip unnumbered" in IPv4 in my view.) I have pitched this idea in the IETF v6ops list and it's now included in a draft that lists different models of IPv6 delivery. As far as I know, this IPv6 L3 device doesn't exist (in the pricerange needed for massive residential roll-out anyhow). So, in the meantime, to get IPv6 to the end customers I see two ways (because they need to fit into the IPv4 security model mentioned above). We have either 6to4 tunneling (Cisco 7600 does this very well and code for Linux CPEs exist already), or we try to fit IPv6 into the IPv4 security model. Current recommendation from the swedish "city networks association" (they consists mostly of entities running LANs to residential, I believe there are approx 400-500k ports of that in Sweden at this time) is that if you don't know if your network is secure against IPv6, block it at the ethertype level (I'll come back to the security risks later). So, how can we fit current IPv6 into the IPv4 security model? We can't. Current L2 devices won't do any of the IPv6 security stuff needed, and just turning on RA/DHCPv6 would make it work from a "let's move packets"-aspect, but it wouldn't be secure (perhaps in some forced-forwarding cases there might be a possibility of doing it securely, but what devices will log what customer had what IP at what time when it's done via RA?). So, what is the security problem with IPv6 in an IPv4 network? Well, imagine an IPv4 network where security is done via ARP inspection, DHCP snooping and L3 ACLs. Now, insert rogue customer who announces itself via RA/DHCPv6 and says it's also DNS. Vista machines will get itself an IPv6 address via RA, ask for DNS-server via DHCPv6, so if the rogue customer can do some NAT-PT like functionality, they are now man in the middle for all the IPv4 traffic (because between the customers it's IPv6 and the L2 device doesn't know anything about that). I don't know if this has actually been done, but I see no theoretical problem with it, if someone can come up with something, please do tell. So, my view on IPv6 is that I would love to roll it out to all residential customers, but unfortunately all the development done for IPv4 security has gone unnoticed by the people developing IPv6 and now it's behind and needs to catch up, or pitch a different model and then get vendors to develop products that do this. In the mean time, we do (and I encourage everybody else to do the same) support 6to4 and Teredo, plus we do IPv6 native in the core and peering where possible plus we give IPv6 to customers where we're able to securely (mostly transit customers and corporate customers with IPv6 capable CPEs). -- Mikael Abrahamsson email: swmike(a)swm.pp.se

9 17

Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space
by Scott Howard 10 Feb '09

10 Feb '09

On Mon, Feb 9, 2009 at 9:54 PM, John Osmon <josmon(a)rigozsaurus.com> wrote: > It isn't SOX, but sadly enough, PCI DSS Requirement 1.5 says: > Implement IP address masquerading to prevent internal addresses from > being translated and revealed on the Internet. Use technologies that > implement RFC 1918 address space, such as port address translation (PAT) > or network address translation (NAT) It's moved to Requirement 1.3.8 of the current PCI DSS (V1.2, October 2008), and has been reworded slight : *1.3.8 Implement IP masquerading to prevent internal addresses from being translated and revealed on the Internet, using RFC 1918 address space. Use network address translation (NAT) technologies—for example, port address translation (PAT).* However the PCI DSS does contain a "Compensating controls" section, which allows for the use of functionality which "provide[s] a similar level of defense" to the stated requirements, where the stated requirements can not be followed due to "legitimate technical or documented business constraints" Now the fact that RFC1918 addresses don't work with IPv6 is clearly a "legitimate technical ... constraint", so as long as you could successfully argue that a stateful firewall or other measures in place provided equivalent security as NAT you should be fine. Scott.

2 1

Network equipments process utilization
by 정치영 10 Feb '09

10 Feb '09

Hi everyone, I wonder which percentage is good level of CPU and Memory util of network equipment ? In my case, I try to keep under 30% cpu util and 70% memory util. My most equipment are Cisco product. I have no technical reference about that, it is just a rule of mine or my predecessor. Could you tell me how other operators are doing ? what is your operation baseline ? or is there any guideline about process utilization ? Best regards, Chiyoung ============================================= Chi-Young Joung SAMSUNG NETWORKS Inc. Email: lionair(a)samsung.com Tel +82 70 7015 0623, Mobile +82 17 520 9193 Fax +82 70 7016 0031 =============================================

4 5

Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space
by Nuno Vieira - nfsi telecom 10 Feb '09

10 Feb '09

security by obscurity is not the way, everyone knows it. those guys will figure it out sooner or later (where later, might take ages). in the meanwhile, a lot have pseudo-secured networks thru triple-nat, quadruple-nat, multiple ipsec'd layered and so, and others live with the hammer in their suitcase for fixing things around when the clue is gone. often they forgot the neat webserver box that run's some strange software, which no one updates, and... in the end is the cheese hole around their network... but, in the other end, money talks, and bulls**t walks, so, we might be all wrong, and they might be right, who knows ? who cares anyway ? :-) --nvieira ----- "John Osmon" <josmon(a)rigozsaurus.com> wrote: > > It isn't SOX, but sadly enough, PCI DSS Requirement 1.5 says: > Implement IP address masquerading to prevent internal addresses > from > being translated and revealed on the Internet. Use technologies > that > implement RFC 1918 address space, such as port address translation > (PAT) > or network address translation (NAT) > > I know that some auditors want to hold people to that standard. > > I stopped working with the credit card people at that point...

1 0