November 1997 - Test - lists.nanog.org

Operational issues: AS10297 leaking routes
by dlr＠bungi.com 04 Nov '97

04 Nov '97

AS10297 is leaking routes to sprint from AS7018/6478/... Sprint has been alerted. No answer at the NOC phones for AS10297. Dave Rand +1 408 254-7111 -- Dave Rand dlr(a)bungi.com http://www.bungi.com

3 4

route-views.oregon-ix.net back up
by David M. Meyer 04 Nov '97

04 Nov '97

Thanks to a generous grant from Cisco Systems and cooperation from many people around the network, route-views.oregon-ix.net is back up. route-views.oregon-ix.net currently has the following views: CERFnet (San Diego) 134.24.127.3 through AS1740 Europe (RIPE) 193.0.0.242 through AS3333 IAGnet (Chicago) 131.103.20.49 through AS1225 LINX (London) 194.68.130.254 through AS5459 MCI (San Francisco) 204.70.4.89 through AS3561 PIPEX (London) 158.43.133.48 through AS1849 Sprint (Stockton) 144.228.240.93 through AS1239 Verio (MAE-WEST) 205.238.48.3 through AS2914 blackrose.org (Ann Arbor) 204.212.44.128 through AS234 Please have a look and let me know if there are ways we might improve the service (or if you have any other questions or comments). Thanks, Dave

1 0

A First Byte of IPv8
by Jim Fleming 04 Nov '97

04 Nov '97

To NANOG list members... Thanks for the interesting comments on IPv6 and IPv4. It is always interesting to see why IPv6 is the way it is. As you might know, IPv8 is not that way... All you have to do is look at the first byte of IPv8 to realize that it was designed for performance, not to satisfy or calm the press. There are 8 bits in that byte and they have been carefully allocated as follows: 1OSSSDDD 1 - The IPv8 flag bit (IPv4 and IPv6 are 0) O - Options Present (0 - no, 1 - yes) SSS - Source Galaxy DDD - Destination Galaxy By looking at only this first byte, routers can sort packets destined for one of the 8 Galaxies very quickly. Routers can also discover whether the header contains options and route those packets locally for further processing. IPv8 has exactly the same size header as IPv4. It is therefore easy to learn and understand. IPv8 has been designed with 48 byte ATM payloads in mind. Therefore, the performance people and QOS people will be happy. IPV8 has been designed for the emerging world of circuit switched routing, where packets are moved a long way without "hops" so that they can be delivered to their intended destination as quickly as possible. IPv8 was designed to address the routing problem as well as the Address Management and Governance problems. The 11 bits of addressing added to the 32 bit IPv4 addresses are divided into 3 bits and 8 bits and a natural hierarchy takes shape. The core has 8 regions each with 256 distribution centers and from there full 32 bit Internets. This is 2,048 address spaces. If these address spaces are managed well, they can be used in IPv6 addressing. NANOG people may want to consider focusing on address space management without being concerned about the protocol header format. NANOG could help to make a contribution in making sure these emerging address spaces are managed the way your members desire. That would be a major contribution to the future of all the 2,048 Internets. Jim Fleming Unir Corporation IBC, Tortola, BVI

4 4

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 03 Nov '97

03 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 03 Nov '97

03 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