June 2007 - Test - lists.nanog.org

Re: Security gain from NAT (was: Re: Cool IPv6 Stuff)
by Brandon Butterworth 04 Jun '07

04 Jun '07

> I posit that a screen door does not provide any security. A lock and > deadbolt provide some security. NAT/PAT is a screen door. > Not having public addresses is a screen door. A stateful inspection > firewall is a lock and deadbolt. It's tedious getting in and out with a lock and a deadbolt so we don't bother. The screen door stops some bugs flying in. I don't see why people make a big deal of this, to the extent of trying to stop people doing NAT if they want to in v6. People can break their connection if they want, for some a box that does what a pre configured NAT box does is more security than they would have if left to configure something else (child wants some p2p, child opens ports and a few others over time, firewall is pointless) Assuming NAT cannot exist is what annoys me as it also breaks a lot of proxy firewalls too by trying to force an end to end model that doesn't suit all. Back to "rabbit season" "duck season" discussion... brandon

1 0

NIST Special Publication 800-54 Draft - BGP Security
by ksriram＠nist.gov 04 Jun '07

04 Jun '07

I made an announcement today during the ISP Security session (at NANOG40) about the release the following publication from NIST: Special Publication 800-54 Draft Version 2, Border Gateway Protocol Security http://csrc.nist.gov/publications/drafts/800-54/Draft-SP800-54-version2-Jun… This is a revised version incorporating many comments received on the first version that was issued in September 2006. The document remains open for comments and further revisions. Please email comments/suggestions to the authors: kuhn(a)nist.gov, ksriram(a)nist.gov, dougm(a)nist.gov Thank you. Sriram K. Sriram, Ph.D. Advanced Network Technologies Division National Institute of Standards and Technology 100 Bureau Drive, Stop 8920 Gaithersburg, MD 20899-8920 Phone: (301) 975-3973 E-Mail: ksriram(a)nist.gov Web: http://www.antd.nist.gov/~ksriram/

1 0

RFC4864 - Local Network Protection for IPv6
by Jeroen Massar 04 Jun '07

04 Jun '07

For all you "NAT is soo secure I need to NAT" folks please take the time and read the following RFC that the IETF has carefully put together to address all those arguments. URL: http://myietf.unfix.org/documents/rfc4864.txt Abstract: 8<---------------------------------------------------------------------------- Although there are many perceived benefits to Network Address Translation (NAT), its primary benefit of "amplifying" available address space is not needed in IPv6. In addition to NAT's many serious disadvantages, there is a perception that other benefits exist, such as a variety of management and security attributes that could be useful for an Internet Protocol site. IPv6 was designed with the intention of making NAT unnecessary, and this document shows how Local Network Protection (LNP) using IPv6 can provide the same or more benefits without the need for address translation. ---------------------------------------------------------------------------->8 Now, if you have a problem with that document and the way it solves your problems, please raise them in the v6ops WG of the IETF so that they know about them and can address your concerns. Greets, Jeroen

1 0

Avaya CNA 336 questions from other users.
by Drew Weaver 04 Jun '07

04 Jun '07

I have a hard time finding people who know what an Avaya converged network analyzer is in my social circle, so I turn to you folks to see if anyone has any experience with them. We have had one deployed at our edge for awhile and I wanted to compare notes on performance with other folks who also use this product. Any off-list contact would be appreciated. Thanks, Andrew

1 0

Re: Security gain from NAT (was: Re: Cool IPv6 Stuff)
by Robert Bonomi 04 Jun '07

04 Jun '07

> From owner-nanog(a)merit.edu Mon Jun 4 13:54:55 2007 > Subject: Re: Security gain from NAT (was: Re: Cool IPv6 Stuff) > Date: Mon, 4 Jun 2007 14:47:06 -0400 > > On 4-Jun-2007, at 14:32, Jim Shankland wrote: > > > Shall I do the experiment again where I set up a Linux box > > at an RFC1918 address, behind a NAT device, publish the root > > password of the Linux box and its RFC1918 address, and invite > > all comers to prove me wrong by showing evidence that they've > > successfully logged into the Linux box? > > Perhaps you should run a corresponding experiment whereby you set up > a linux box with a globally-unique address, put it behind a firewall > which blocks all incoming traffic to that box, and issue a similar > invitation. > > Do you think the results will be different? Consider the possible *FAILURE* modes. e.g. (1) where somebody brings up _another_ path between the LAN that that box is onn, and the public internet, with no translations or other protections whatsoever. (2) where the 'protection box' "fails open" -- e.g. passes all traffic without modification. NAT/PAT is 'belt and suspenders', but it *does* provide an additional layer of protection, _if_the_primary_protection_fails_. That 'additional protection' may or may not be 'significant', depending on one's viewpoint.

1 0

NANOG40 agenda changes
by Steve Feldman 04 Jun '07

04 Jun '07

Since the first session went long, we are rearranging things a bit: - This morning's session will resume at 11:40 - Randy Bush's talk moves from today to Wednesday at 10:30, and the rest of the agenda shifts 15 minutes later that day. The complete updated agenda is at: http://www.nanog.org/mtg-0706/topics.html Steve

1 0

Re: NAT Multihoming
by Stephane Bortzmeyer 04 Jun '07

04 Jun '07

On Sun, Jun 03, 2007 at 07:33:45PM -0700, Stephen Satchell <list(a)satchell.net> wrote a message of 29 lines which said: > The last time I renumbered, I found that quite a few people were not > honoring the TTLs I put in my DNS zone files. [...] Custom customer > zone files hosted elsewhere? Do not forget that applications have their own caches, too, and they typically ignore completely the DNS TTL. A typical Web brower calls getaddrinfo() once and use the IP address as long as it is not restarted.

2 1

Re: NAT Multihoming
by Iljitsch van Beijnum 04 Jun '07

04 Jun '07

On 4-jun-2007, at 4:33, Stephen Satchell wrote: > The last time I renumbered, I found that quite a few people were > not honoring the TTLs I put in my DNS zone files. I would clone > the new address and monitor traffic to the old address -- and it > took up to seven days for the traffic to the old address to die > down enough that I could take it out. Are you sure this was the result of DNS servers increasing the TTL, not simply applications doing their own caching?

1 0

Re: Providers that carry IPv6
by Jeroen Massar 04 Jun '07

04 Jun '07

Antonio Querubin wrote: > On Mon, 4 Jun 2007, Jeroen Massar wrote: > >> Please at least honor: ip6.de.easynet.net/ipv6-minimum-peering.txt > > A typical trans-Pacific path is significantly longer than a typical > trans-Atlantic path. The < 40 ms policy recommendation in the above is > unrealistically small for those of us out here in the Pacific Ocean > where it takes roughly 50 ms just to reach only halfway across the > ocean. It also favors a system of short IPv6 paths through multiple > tunnels that add significant latency which is somewhat self-defeating. > Ideally you want an IPv6 path between point A and point B to be > reasonably close in latency to the IPv4 path. That is indeed the intention of that document, therefor that "<40ms policy" can be mostly ignored for that type of links. > In the absence of > ubiquitous, diverse, native IPv6 peering between Tier 1 providers, which > I suspect will still take a while to develop, currently the only > realistic way of keeping the latency delta minimized between an IPv4 > path and an IPv6 path is to have your own diverse set of tunnels, even > if it means tunnels that go halfway around the world. I don't see a real reason why one needs to tunnel around the world. Unless you are indeed in a very remote location where no transit provider is providing IPv6 yet. If that is still the case though I definitely would suggest that you start kicking your current IPv4 transits *VERY* hard in several naughty places to get them going and start providing it. At the very least they can do a tunnel over their own infrastructure and terminate you at their ends. > The alternative > is IPv6 connectivity that really stinks because packets have to bounce > through multiple tunnels unnecessarilly. Try to avoid that at all cost of course. But if that is the only way, then for the time being that is then the only solution. Of course document it properly and kick upstreams to fix it. Greets, Jeroen

1 0

Peering Personals@Peering BOF XV at NANOG 40 in Bellevue
by William B. Norton 03 Jun '07

03 Jun '07

[ If you are NOT ATTENDING this NANOG in Bellevue, please disregard ] We have some time at this Peering BOF XV for some Peering Coordinator introductions. This is a chance for Peering Coordinators to introduce themselves to the group before we break for beers. How does this work? We solicit Peering Coordinators (with this note), asking them to characterize their networks and peering policies in general ways ("content heavy" or "access (eyeball) -heavy," "Open" vs. "Selective" vs. "Restrictive" policies etc.). >From the answers we will select a set of ISP Peering Coordinators to share a short (2-3 minute) description of their network, what they look for in a peer, etc., allowing the audience to put a face with the name of the ISP. At the end of the Peering BOF, Peering Coordinators will have time to speak with Peering Coordinators of ISPs they seek to interconnect with. The expectation is that these interactions will lead to the Peering Negotiations stage, the first step towards a more fully meshed and therefore resilient Internet. If you are a Peering Coordinator and wish to participate in the Peering Personals section of the Peering BOF, please reply to me (privately) with the answers the following 8 questions: ------------------------------ 1) Name: ____________________ 2) Title: ___________________ 3) Company: _________________ 4) AS#: _____________________ 5) Check which one best applies: ___ We are an ISP (sell access to the Internet) --OR-- ___ We are a Non-ISP (content company, etc.) ___ We are Content-Heavy --OR-- ___ We are Access-Heavy 6) Check whichever ones apply: ___ We are an "Open" peer (The answer to peering requests is YES) ___ We are a "Selective" peer (The answer to peering requests is YES but we may have a few 'objective and meetable' pre-requisites such as "three geographically diverse locations with 10Mbps on each coast") ___ We are a "Restrictive" peer (The answer to peering requests is generally NO) ___ We have huge volumes of traffic (lots of users and/or lots of content) (huge: > 1 Gbps total outbound traffic to peers and transit providers) ___ We have a global network ___ We require Contracts for Peering 7) Current Peering Locations: _______________________ 8) Planned (3-6 mos) Peering Locations: _______________________________ Bill -- //------------------------------------------------ // William B. Norton <wbn at equinix.com> // Co-Founder and Chief Technical Liaison, Equinix // GSM Mobile: 650-315-8635 // Skype, Y!IM: williambnorton

1 0