- Test - lists.nanog.org

Re: Spam Control Considered Harmful
by David R. Conrad 04 Nov '97

04 Nov '97

Hi, Of course, static IP address assignment is wasteful -- as demonstrated by your case (and justifying ones actions by pointing to others doing worse is seldom very effective), however a couple of questions/points: >Until IPv6 is widely used Are any ISPs seriously considering deploying IPv6 in the forseeable future (e.g., what level of demand are ISPs in the US seeing for IPv6)? >and address space is not so critical, we have to >conserve address space and using it wisely. Address space will (presumably) always be critical -- after all, it is a bit hard to connect to the Internet without it. As such, using it wisely would seem a good idea. Of course, whether one needs to "conserve" address space and whether conservation implies wise use would depend on the answer to the question above and what one thinks will happen when the free address pool approaches exhaustion. >Perhaps in the UK there are different requirements for allocation of address >space than InterNIC/ARIN. Of course there are (look at why there are different regional registries in the first place). For example, what happens when a new ISP with no previous allocation history starts up in the US as compared to what happens when it starts up in Europe or the AP region. Other examples exist (the static IP address assignment issue isn't one of them -- all the registries have a similar policy now). These differences, however, are something the registries try to minimize and work to resolve internally. Too bad there can't be a public forum in which such stuff is worked on without the raving lunatics coming out of the woodwork and turning the forum into meaningless repetitive dribble. In response to the original statement that started this thread, I'd be interested to know how one would go about putting technological djinn back into their respective bottles. Blackhole feeds, et al, exist because they serve a purpose. Like any tool, they can be misused. I'm sort of suprised that some governments haven't already required ISPs in their countries to accept "official" black hole feeds, but I suspect it'll happen within the next year or so. Of course, many people wish nuclear weapons weren't invented too... Regards, -drc

8 8

IPsec processing & NAT (was Re: moving to IPv6)
by rja＠corp.home.net 03 Nov '97

03 Nov '97

>> I agree 100% when it comes to payload, but network addresses serve >> the network as much as the packet. To the extent that we start >> deploying networks with more functionality (such as mail relaying >> and web caching), then the same logic applies to DNS names. >One big problem we have today is that transport addresses have >embedded within them network addresses. To cryptographically protect >transport-level connections in practice means that network level >addresses (i.e., those in the IP header) cannot be safely modified. % I don't think that this is correct. IPsec relies on IP in IP tunneling, % thus the transport level identifiers can be modified without affecting % the payload. Since I don't think we have any boxes doing signatures % on single packets, I don't see a problem here. Unless you are modifying % the addresses presented to the application insided the NATed network, % during the session interval, you will be able to use the transport level % indentifiers as a session tag for the decryption. Wrong. IPsec input processing (regardless of transport/tunnel-mode and regardless of ESP/AH) always requires that the Destination IP Address in the outer IP header be used to locate the correct IPsec Security Association for the received packet. If the NAT function changes that Destination Address, the attempt to locate the IPsec Security Association will fail and the received packet will be dropped. If the NAT function changes the Source Address, then the required (to prevent IP spoofing attacks on IPsec) Source Address check will fail and again the received packet will be dropped. The only way to make IPsec work through a NAT box is to have the NAT box participate in the IPsec session(s). Sample topology follows: NOTATION: = IPsec protected traffic flow - unprotected IP traffic flow [] delimiters for a single box Hn Arbitrary IP host Nn Interface "n" on the NAT device TOPOLOGY DIAGRAM: [H1]======[N1----N2]======[H2] COMMENTS: Traffic is unencrypted between interfaces N1 and N2. NAT function occurs somewhere between N1 and N2. IPsec protects traffic between (H1 and N1) and between (N2 and H2). The NAT device N could modify the unencrypted traffic and {H1, H2} have no method of determining whether modification happened -- hence {H1,H2} are forced to trust N whether or not they desire to do so. % If you have a payload that is encrypted and signed, there is % fundementally no reason for the application to know anything other than a % magic cookie return address. False, at a minimum the identity of the signer needs to be known (so the signature can be verified if appropriate). A key identifier or other attributes might also be needed, depending on your precise meaning. Ran rja(a)home.net

1 0

Re: NAT etc. (was: Spam Control Considered Harmful)
by Sean M. Doran 03 Nov '97

03 Nov '97

"Jay R. Ashworth" <jra(a)scfn.thpl.lib.fl.us> writes: > This is a question of _trust_, and if I don't wish to > allow the operator of a NAT box to proxy my trust in a > nameserver operator, there really isn't any good way > around that. You could change your connectivity such that there is no NAT between you and the set of nameservers from which you feel you must have untouched responses. In a "NAT Everywhere" world with a sufficiently large set of such nameservers this may be completely impractical. Given that not trusting the DNS is the default mode of operation for the current Internet, the question is whether the advantages of NAT justify a constraint on DNSSEC or whether the advantages of DNSSEC justify a constraint on NAT. The problem seems simpler with a "NAT in some places" model, especially where "some places" is mostly at the borders of big corporations, however strings of NATs do and will happen, and there will be these trust issues to deal with in some places anyway. I would perfer to avoid constraining the problem just because it makes the NIMBY folks more quiescent, to be honest, since it rankles as much the concept of "only some people have to renumber to conserve address space and preserve the scalable properties of hierarchical routing. we won't, we're privileged (or too big or too understaffed)". Like renumbering, NAT is out there, and making it seamless and easy strikes me as a good and useful goal, even if it complicates other good and useful goals. One of the ways to make it and renumbering seamless is to understand that IP addresses are subject to change over time and topological distance. Sean.

4 4

Re: moving to IPv6
by Sean M. Doran 03 Nov '97

03 Nov '97

Phil Howard <phil(a)charon.milepost.com> writes: > Test market a dialup service at a reduced rate that gives people a > private space address behind a proxy server. No, implement NAT in such a way that you can roll this service out without anyone noticing, except in the difficult case where an "inside" and "outside" address collision is triggered by using IP addresses rather than DNS names. Then once you've rolled it out, you can assign static IP addresses, large address ranges, and other popular shopping-list items that a number of users seem to want, to the extent that they are a market differentiator that in the absence of NAT favours less-conserving ISPs. Sean.

2 2

Re: NAT etc. (was: Spam Control Considered Harmful)
by Havard.Eidnes＠runit.sintef.no 03 Nov '97

03 Nov '97

> > Security based on IP address. > > Here I disagree, not only for the obvious reason that > forgery is easy, but also because basing anything on IP > address that does not involve looking back up through the > DNS (which is also not yet safe) is incompatible with NAT. ...which brings me to think if it isn't so that Secure DNS (at least as currently specified) and widespread deployment of NAT boxes which fiddle with the contents of DNS reply/request packets isn't exactly a properly working combination. As I understand it you can have NAT or Secure DNS with e.g. signed A records but you can't (easily?) have both. (Which brings us even further afield from the original subject... ;-) Regards, - Håvard

8 12

Re: moving to IPv6
by jnc＠ginger.lcs.mit.edu 03 Nov '97

03 Nov '97

From: Randy Bush <randy(a)psg.com> there was an increasing sensationalist panic in the half-informed press that the internet was going to run out of address space in the next fifteen minutes. There is a certain amount of evidence that this was fanned, in times prior to IPv6, by people in whose interest it was to promote interest in protocols with a larger address space. So I don't think you lay all the blame on the press. The IPv6 decision immediately solved that problem. Victory over the address space problem was declared. I've heard that rationale from a number of people (incudling some who held it at the time). The only problem with it is that the cost to the IETF community, in a variety of ways, including damaged personal interactions, and diverted energy (the "B Ark" phenomenon notwithstanding) has been very, very high indeed. There were better ways to i) assuage the panic (by doing things that did provide more useable addresses), and ii) did something useful for the future of the Internet, but they didn't get picked. Noel

1 0

Re: moving to IPv6
by Sean M. Doran 03 Nov '97

03 Nov '97

Alex Bligh <amb(a)gxn.net> writes: > Sean seems to predicts death of end to end > network layer addressing. How about the > death of end to end internet? Instead > run with a core of IPv4 numbered routers > and application layer gateways. Run everything > else in private address space. 10.0.0.0/8 > has pleny of room. Alex has followed things closely and has just moved back into the realm of the smart ALG, which is another of my favourite topics. As his message is something I cannot really improve upon, let me just say that I completely agree that for many protocols, his end is a good one, and has the benefit not only of conserving IP addresses to the point that IPv4ever looks likely but also reducing unecessary duplicate traffic. The one clarification, though, is that running everything in private address space does not imply the end of end-to-end Internetworking; it is dropping in smart ALGs that means the death of the inefficient end-to-end nature of several popular protocols. Sean.

1 0

Re: moving to IPv6
by Sean M. Doran 03 Nov '97

03 Nov '97

Rodney Joffe <rjoffe(a)genuity.net> writes: > It seems to me that if there is going to be a change in the way that we > look at addresses, routing, and NAT, it would be in everyone's interest > if we were able to build border NAT devices that besides telling an > incoming packet where to go, was also able to tell it what route to take > through the internal network. Not just relying on the internal routing > data, but also making decisions based on the real-time performance > inside the network, and the nature of the traffic (TCP vs. UDP, HTTP vs > FTP vs TELNET vs MAIL). I know it touches on QOS, but QOS is reactive, > this could be proactive. > > Once the box has to do the work, and look at each packet and address, > why not add smarts? Note that with respect to the idea that one can make interesting forwarding decisions across a routing domain based on such things as source address, input interface, packet size, protocol, etc., there is a strong conceptual affinity between NAT and MPLS. Wheras MPLS is a protocol-neutral map-and-encapsulate system, NAT is a protocol-specific translation. There are enormous potential synergies between the two, particularly when, as Rodney suggests, one starts considering policy based on what MPLS calls FECs (Forwarding Equivalency Classes). However, the two are not interchangeable; MPLS should not modify payloads (it should not KNOW what the payload is) and doing lots of packet-munging at the NAT level is a poor (and in some cases extremely difficult) way to propagate policy information from router to router. You are the second sound person recently to suggest routing based on observed load. This sort of thing scares me (cf. Peter Lothberg's 101-is-full-use-280-280-is-full-use-101-repeat San Francisco Bay Area highway analogy in the past, and Radia Perlman's "congestion control is a very difficult problem in a network" et succ., s. 9.12 in _Interconnections_). Frankly I am worried that the amount of control traffic and processing needed to implement fine-grain congestion avoiding forwarding will overwhelm network devices. A better approach is probably to run with Van Jacobson's recent appeals to use intelligence in gateways to make non-high-quality traffic fairer so that for that traffic no congestion-avoiding forwarding needs to be done. High-quality (i.e., extra $) traffic could then be dealt with in a variety of ways ranging from queue manipulation and selective disabling of fairness-enforcement to using MPLS or an equivalent to direct traffic across different infrastructure. Sean.

1 0

Re: Communities
by Sean M. Doran 03 Nov '97

03 Nov '97

The route object found via 'whois -h whois.ripe.net AS1755' may serve as a useful case study for people interested in using communities to influence routing policy. Sean. P.S.: whois.ra.net will work too for those of you with poor connectivity to Europe or scratching your heads about why whois.ripe.net doesn't seem to work right now...

1 0

Hello, mci?
by Alex Rubenstein 02 Nov '97

02 Nov '97

http://www.security.mci.net/dostrack Not Found The requested object was not found on this server. Hrmph. Where?

4 3