- NANOG - lists.nanog.org

NANOG 11 Registration Refund
by Pam Ciesla 04 Nov '97

04 Nov '97

For those of you who prepaid, but were unable to attend the meeting please contact me for a refund. There will be a $20 charge and request must be received by Friday, November 28. Thanks xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Pam Ciesla 313-936-0172 - phone Merit Network, Inc. 313-647-3185 - fax University of Michigan 4251 Plymouth Road Bldg. I, Suite C Ann Arbor, MI 48105-2785 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

1 0

Lost transciever adapter
by Chris A. Icide 04 Nov '97

04 Nov '97

During the NANOG cleanup, we found a Xircom PCMCIA RJ45 ethernet adapter. If you believe it may be yours, please send me a note and a simple description of the item. ---------------------------------------------------------------------- Chris A. Icide Genuity, Inc. / Nap.Net, L.L.C. Sr. Network Engineer 4041 North Central Ave. Suite 400 602-207-6409 Phoenix, AZ 85012 - Notice: NVRAM invalid, possibly due to write erase. Press RETURN to get started! - PGP Keys located at pgpkeys.mit.edu or http://nap.net/~chris/keys.html ----------------------------------------------------------------------

1 0

Re: moving to IPv6
by Pedro Marques 04 Nov '97

04 Nov '97

randy(a)psg.com (Randy Bush) writes: > if global name to 'address' resolution is desired, then the directory > mechanism protocols, currently dns, need to be translated at address > and/or name domain boundaries. some nats currently do this. That is smaller problem compared to translating application protocol information. > > are there other protocols/data which *must* be translated at boundaries? There are a full bunch of protocols that do include addresses FTP control information for instance... For FTP when translating between v4 and v6 the NAT box has to translate commands as well as addresses... PORT <-> LPRT PASV <-> LPSV etc... > should kink such as cuseeme be left to die? Newer videoconferencing software does the same mistakes unfortunatly... H.323 for instance requires snooping of several streams to be able to translate packets. Pedro.

1 0

Hello, MAE-East?!
by Alex Rubenstein 04 Nov '97

04 Nov '97

MAE-East, from what I can tell, has bounced two times in the past hour. nitrous.digex.net confirms my beliefs. <rant> What is being done to repair this? It is one of the few things that can actually affect a LOT OF PEOPLE at the same time. And, to worsen the effect, MFS seems unwilling/unable to fess up and *really* say what is going on. </rant>

3 2

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