- Test - lists.nanog.org

Sausage making, SS7 and protocols
by Sean Donelan 04 Nov '97

04 Nov '97

>In a world where the internet industry is becoming >more and more like the telecoms industry, the >necessity of users to have protocol level access >to the network is diminishing, and the dangers >of doing so are becoming greater. Which telcos >will blithely hand out SS7 interconnects to >users? Without (routable) IP access, there >would be no SYN floods of distant networks, no >source spoofing, less hacking, easier traceability, >and the BGP table need only be OTO 1 entry per >non-leaf node on a provider interconnection >graph. Strange how people in the telecom industry think they need to become more like the internet industry, and people in the internet industry think they need to become more like the telecom industry. If you want to see some sausage being made, take a look at the "Advance Intelligent Network" and the Internet interface working group PINT. In the US, with telecom deregulation, the distinction between 'users' and 'telephone companies' is becoming less distinct. When an insurance company, an university, or an ISP files the paperwork to become a CLEC, are they a 'user' or a 'telco?' What telco would refuse SS7 interconnects to a CLEC? The trust model in SS7 makes rlogin look like a high-security protocol. SS7 was developed in an environment where there would be a few trusted 'users.' As the number of 'telco'-like entities explodes, you might see some interesting security issues showing up with SS7. There is some 'screening' between networks, but gateway STP nodes have many of the same problems as Internet firewalls. Internet providers give both less and more access to their networks than telcos. Generally ISPs don't give other ISPs more access to their networks than any other untrusted user. Even read-only SNMP between providers is almost non-existant. Most ISPs would probally consider giving SS7 level access into their network to another ISP a huge security hole. In some sense, interconnecting ISPs is easier than telcos because the security risk of connecting to another ISP is the same as connecting to a user. Today's SS7 network is far more risky than anything Capt. Crunch could do with his whistle. On the other hand, it seems like many ISPs don't consider it a duty to screen or filter their customer's ingress or their own egress. While telco's almost always screen information such as directory numbers when they originate from a customer PBX. This has less to do with the SS7 protocol, than the trust relationship between telcos. Telcos trust other telcos to only send SS7 packets with screened customer phone numbers. This 'trust' is formalized into extremely complicated agreements between telcos, especially who is liable when the trust is broken. ISPs have very simple 'trust' relationships (i.e. trust no one), and correspondingly simple agreements between them. Since there is a much lower trust relationship between ISPs, tracing malicious behavior is much more difficult. At a simple level, look how caller-id information is treated between telcos. Telcos pass caller-id information, more or less, on an end-to-end basis through the SS7 network 'sharing' it with all the telco's along the way. However, telcos don't pass the caller-id information to the 'user' if the presentation-restricted flag is set. ISPs don't normally provide any more information to another ISP than they do to an user. Which model causes less problems when the CLEC turns out to be an private investigative company, or a university. It will be interesting to see which trust model works better as the number of CLECs grows or the number of ISPs shrinks, depending on which consulting group you want to believe. Will ISPs start trusting each other more, or will telcos start trusting each other less? At some companies, the Internet connection is the most secure outside communications connection they have. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

2 1

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