jrr@NCNOC.TUCC.EDU (Joe Ragland) (12/24/88)
Mark: A local VMS host running CMU-TEK TCP/IP has revealed an interesting routing situation with the p4200s. Turns out that if one says 'telnet 127.0.0.1' to the local host loopback address, CMU-TEK forwards the packets to suranet-gw.tucc.edu (p4200) which then forwards the packets down the default route. Since Virginia is advertising default, the packets land on uvaarpa.virginia.edu and uvaarpa answers the telnet request. Question: Should the p4200s be forwarding packets for net 127.0? It may be that this is one of those situations not explicitly covered in IP routing RFCs. Whether or not this is the case, I think the p4200s should discard such packets with an appropriate error message. --Joe
sklower@rosemary.Berkeley.EDU (Keith Sklower) (12/26/88)
In article <8812241440.AA05001@ncnoc.tucc.edu> jrr@NCNOC.TUCC.EDU (Joe Ragland) writes:
](With some editing!)... If one says 'telnet 127.0.0.1'
]to the local host loopback address, CMU-TEK forwards the packets to
](p4200) which then forwards the packets down the default route.
]
]I think the p4200s should discard such packets with an appropriate error
] message.
I do not speak in an official capacity for the 4.3 people, but it is
my strong prejudice that the proteon routers should be doing exactly
what they do now. It was fairly easy for you to diagnose the problem,
wasn't it? If the p4200 had discarded the packets, how long would
it have taken you to think about looking at the error logs there?
I'm not sure I would have ever thought about looking off the machine
myself if loopback had (silently) not worked. [We did have this problem
here once when we were changing some stuff about the way loopback
worked]. If you want somebody to complain about the illegality,
it would seem to me to be the recipient of the bogon, rather than
the forwarder. (And don't forgot that the the check would be applied
to EVERY packet forwarded.)
[I have the impression that the original intent at Berkeley was to
have the loopback address configurable, rather than cast in stone,
and was something of a local experiment, which is why nobody here
officially applied for a network number for that purpose. It was
just ``borrowed'', since people here thought it would be a long time
before network number 127 was likely to be assigned. After some of
the loopback packets escaped onto the arpanet (be it noted from other
places than berkeley itself), other more official raised some sort of
hue and cry about making this all legal]
types raised a hue and cry ]jrr@NCNOC.TUCC.EDU (Joe Ragland) (12/26/88)
sklower@rosemary.Berkeley.EDU (Keith Sklower) Message-ID: <27249@ucbvax.BERKELEY.EDU> says in response to my comments about p4200s forwarding net 127 packets: >I do not speak in an official capacity for the 4.3 people, but it is >my strong prejudice that the proteon routers should be doing exactly >what they do now.... >If you want somebody to complain about the illegality, >it would seem to me to be the recipient of the bogon, rather than >the forwarder. I understand, but then you mention: >After some of the loopback packets escaped onto the arpanet (be it >noted from other places than berkeley itself), other more official >(types) raised some sort of hue and cry about making this all legal] Yes, and I'd rather no loopback packets be allowed to escape from our NC network thru a gateway for which I am responsible. That's why the forwarder is complaining. Besides direct Berkeley Unix implementations there are many derivatives that have replicated using net 127 for loopback. After a while widespread general practice moves into the realm of defacto standard whether carefully planned that way or not. As to the p4200s having to examine every packet, extensive validity/ conformance examinations are already being made by p4200 logic. We regularily examine p4200 error messages. This procedure is often the first indicator of a mis-configured host on the network. With numerous campus departmental host and LAN administrators (with a great range of experience and inexperience) I find p4200 error diagnostics quite valuable. One more check could hardly make much performance difference. Thanks Keith for your comments.
medin@NSIPO.NASA.GOV ("Milo S. Medin", NASA ARC NSI Project Office) (12/27/88)
Joe, if you feel that strongly about grounding net 127 datagrams, and are willing to check every packet to make sure none get through, then just add 127 to the filtered networks list, and the p4200 will ground all those packets. Personally, I'm with Keith. The network 127 loopback functionality is a BSD'ism, and hardly something a generic gateway like a p4200 should be concerned with. The p4200 does provide you the tools to address the problem, but I don't think the default value should be to filter... Thanks, Milo
jrr@NCNOC.TUCC.EDU (Joe Ragland) (12/27/88)
Milo, yes net 127 loopback is a BSD-ism. But, it is now an Ultrix-ism, a SunOS-ism, an etc-ism... I can appreciate having a 'clean' generic gateway uncorrupted by -isms but maybe somebody ought to redefine what generic means occasionally as the IP world evolves. As I recall the last time I found it necessary to use the filter list to protect my net from some bogon generator (or to relieve another net from our bogons) one does not get 'process 2' diagnostic messages relating to the filter at default log level (76). I'd like to know in such cases if the filter is being used (or when the bogons cease). Also, adding filters or changing log level requires a restart or reboot of the gateway for changes to take effect, an event I'd rather avoid especially at busy times. Maybe a message stating 'packet filtered' would be beneficial in such cases without having to lower the log level to the point that you are done in with too much info. I suspect there is a bit of tweaking of p4200 logic in this area that might make the process easier to deal with and less disruptive. We'll let the 127 loopback issue be. Thanks for your and Keith's input. --Joe
eshop@JUPITER.UCSC.EDU (Jim Warner) (12/28/88)
>Personally, I'm with Keith. The network 127 loopback functionality is >a BSD'ism, and hardly something a generic gateway like a p4200 >should be concerned with. > Thanks, > Milo ------------------------------------------- The status of 127 is now something more than a BSD'ism. RFC1009 says in section 4.4 "It is the responsibility of a gateway to avoid propagating such erroneous addresses;..." The section contains a reference to section 2.1(g) which specifically mentions (127, <any>). jim warner
jrr@NCNOC.TUCC.EDU (Joe Ragland) (12/28/88)
Thanks Jim for the RFC1009 references. Looks like Bob Braden and Jon Postel are ahead of me. A copy of RFC1009 is maintained on this host (ncnoc) for anonymous ftp but this discussion has progressed while I am at home for the holidays with a slow modem and no printer. Was just applying some 'country' logic which says we have no business zinging packets for net 127 towards the Internet without some bells ringing or buzzers sounding.
fedor@PATTON.NYSER.NET (12/28/88)
>Date: Sat, 24 Dec 88 09:40:02 EST >From: Joe Ragland <jrr@ncnoc.tucc.edu> >Subject: p4200 routing > >Mark: > >A local VMS host running CMU-TEK TCP/IP has revealed an interesting routing >situation with the p4200s. Turns out that if one says 'telnet 127.0.0.1' >to the local host loopback address, CMU-TEK forwards the packets to >suranet-gw.tucc.edu (p4200) which then forwards the packets down the >default route. Since Virginia is advertising default, the packets land >on uvaarpa.virginia.edu and uvaarpa answers the telnet request. > >Question: Should the p4200s be forwarding packets for net 127.0? It >may be that this is one of those situations not explicitly covered in >IP routing RFCs. Whether or not this is the case, I think the p4200s >should discard such packets with an appropriate error message. > >--Joe >>> Joe, Way back in the beginning of NYSERNet the same situation happened, but it wasn't with mail, it was with the syslog messages. Seems as if some ultrix machines were sending their syslog messages to localhost (127.0.0.1). The ultrix machines didn't have a route to the loopback interface (it was config'ed down). So, the syslog messages happened to follow the default path of NYSERNet until it got to a machine that had a route to 127.0.0.1. Unfortunately, that was my machine! :^) Kind of amusing, but a definate pain. To answer your question, looking at my copy of RFC 1009: in section 2.1: (g) [127, <any>] Internal host loopback address. Should never appear outside host. Then, in section 4.4 "Special addresses and Filters": "We can distinquish two classes of these special cases. The first (cases (a), (b), (c), (g), (h), and (i) in section 2.1) contains addresses which should never appear in the destination address field of any IP datagram, so a gateway should never be asked to route one of these addresses. However, in the real world of imperfect implementation and configuration errors, such bad destination addresses do occur. It is the responsibility of the gateway to avoid propogating such erroneous addresses; this is especially important for gateways included in the global interconnect system. In particular, a gateway which receives a datagram with one of these forbidden addresses should: 1. Avoid inserting that address into its routing database and avoid including it in routing updates to any other gateway. 2. Avoid forwarding a datagram containing that address as a destination. To enforce these restrictions, it is suggested that a gateway include a configurable filter for datagrams and routing updates. ......" So, it seems as if the P4200 is compliant with the RFC as it has a filter mechanism available. The question is, should the filter for 127.0.0.0 be automatically enabled or should it be a manual thing like it is now. Maybe a line in the proteon users manual about "recommending this filter" if the gateway is participating in the internet. What do you think? Mark P.S. If you want to get picky, your CMU-TEK IP is broken.
fedor@PATTON.NYSER.NET (12/29/88)
>Date: Tue, 27 Dec 88 09:45:49 PST >From: Jim Warner <eshop@jupiter.ucsc.edu> >Subject: Re: p4200 routing > >>Personally, I'm with Keith. The network 127 loopback functionality is >>a BSD'ism, and hardly something a generic gateway like a p4200 >>should be concerned with. >> Thanks, >> Milo >------------------------------------------- >The status of 127 is now something more than a BSD'ism. RFC1009 >says in section 4.4 "It is the responsibility of a gateway to >avoid propagating such erroneous addresses;..." The section >contains a reference to section 2.1(g) which specifically mentions >(127, <any>). > >jim warner > > >> After posting my initial message on this subject, I bounced the RFC text off of someone here. I think the wording in the RFC in section 4.4 is ambiguous, contradictory, whatever. In the excerpt that jim provided above, it seems to imply that the gateway should never forward 127.0.0.1 regardless of the configuration. It is the responsibility of the gateway, not the network administrator. But.... the following paragraph begins something like: "To enforce these restrictions, it is suggested that a gateway include a configurable filter for datagrams and routing updates." Now after thinking about it for a whole ten minutes, I would say that the P4200 is compliant to the wording of the RFC, but not the "spirit" of section 4.4 in RFC 1009. And so it goes, Mark
jrr@ncnoc.tucc.edu (Joe Ragland) (12/29/88)
Hello Mark (Fedor this time, not Oros): Yea, ain't running a gateway wonderful. Before last Fall when we lost our ARPANET line we occasionally got somebody's syslog records, usually from some SURANET site. Guess advertising default is like asking your neighbors (near and far) for their IP garbage. If you don't know where to send it, then send it here and maybe we'll do something with it! We might even answer your localhost telnet request... Gateways have got to be rather tough beasts, prepared for whatever. This CMU-TEK IP may be broken but it sure is not mine eventhough I have to deal with the results. With seven campuses in seven cities, over a 1000 hosts (don't count PCs) I have enough trouble keeping up with the various LAN administrators (their name, telephone number, and e-mail address). Make no attempt to keep up with host administrators. When I get back at my office next week I'll take a close look at RFC 1009 but it seems you have conveyed the essence rather clear. How the p4200 complies leaves some room for opinion. Without my p4200 documentation in hand I seem to recall the filter mechanism works only for explicit IP addresses, not network classes. That is you can filter 127.0.0.1, 127.0.0.2, etc. but can not filter all possible 127 addresses by filtering for 127.0.0.0. If this is the case then some situations would be more difficult to specify. However, loopback in most Unix implementations is explicitly 127.0.0.1 as far as I know. Yes, some discussion in the p4200 user's manual on specific internet filtering would be appropriate. But, I would prefer the default be something other than forwarding packets destined for 127.0.0.1 without a whimper. Happy New Year, Joe
medin@nsipo.nasa.gov ("Milo S. Medin", NASA ARC NSI Project Office) (12/29/88)
Joe, the filter command works ONLY on network classes. If you want host level granularity, you have to resort to using the access control system... Thanks, Milo
jrr@NCNOC.TUCC.EDU (Joe Ragland) (12/29/88)
p4200 folks, I think I am ready to draw this recent discussion to an end or at least my participation in it by saying thanks to all who took their time to give us their input. Also, I've learned some things I'd like to share with you. When I was drug into the IP world I was first told that one most important functions of a gateway was the firewall function. It protects your network from mine and my network from yours and forwards only those packets or datagrams that meet some test of conformity and validity. Then, there was no definitive document that detailed what is involved in the process, only general notions of routing and some discussion of various protocols involved. Now we have RFC-1009 and I am pleased it is explicit in marking packets addresses to net 127 as bogons to be short circuited at the gateway. When RFC-1009 came out I retrieved a copy, printed a copy, and then set it aside saying I should read it some day when I get the time. My thinking then was that this RFC is important to those designing gateways and writing code for such purposes but since I am doing neither it is of less importance to me. That was a mistake. If I had read it I at least might have remembered some reference to net 127. What I reacted to was a crack in the p4200 firewall. As I reflect on this discussion I come to the conclusion that all of us involved directly in the gateway game need to read carefully RFC-1009. It is up to those of us with networking responsibilities to enforce standards and requirements as they evolve by insisting that vendors have met those standards when we are out to procure the next set of gateway boxes. Otherwise, Braden and Postel have wasted their time and we are in for a heap of trouble down the road trying to interoperate especially in view of plans for NSFNET, RIB, DRI, various agency and academic networks. In general the p4200 does a good job of firewalling and a nice job of reporting events in this regard. It could use a bit more attention in this respect so I trust someone at Proteon is listening. I'd be surprised if Cisco and other gateway vendors don't read comp.sys.proteon too so there is some message here I think for all. Happy gatewaying in the new year. Joe
jnc@BRUBECK.PROTEON.COM (12/30/88)
I'm just going to make a quick comment about standards documents, wearing my Standards Committee hat. One of the problems with RFC-1009 is the amount of ambiguity about exactly what you must, should and may do. As some of the previous messages on this issue indicate, there is some confusion and contradiction in the document as to how gateways should handle net 127. I think RFC1009 is the among the last of the 'old-style' RFC's, which were written in a breezy, informal style suitable to researchers. With the larger deployment of TCP/IP as a service which people depend on, this style had to be modified a bit, and I think there is general agreement that we need a little more formality (although not ISO-ese :-). There is a group working under Bob Braden to produce the host equivalent of RFC-1009 (of which I am a member), and as those of you who have seen drafts of this can attest, it works much harder to be explicit and consistent. There will probably be a revision of 1009 to match the same standards (and to catch up with changes) once the Host one is done. At that time, it should be much easier to determine whether or not a given implementation is abiding by the spec. What to do with ones which do abide by the spec but don't do what you want will still be an issue, of course, but at least users will have a mechanism for legitimate gripes with vendors who aren't following specs, and vendors will have a bit of protection from unwarranted angst if they are following the spec. So, I think (and hope) that the situation in the future will improve wth regard to standards, and people following them. The Internet, as a large, multi-vendor system, will not work unless things do improve. Noel -------
lekash@ORVILLE.NAS.NASA.GOV (John Lekashman) (12/31/88)
As to the p4200s having to examine every packet, extensive validity/ conformance examinations are already being made by p4200 logic. We regularily examine p4200 error messages. This procedure is often the first indicator of a mis-configured host on the network. With numerous campus departmental host and LAN administrators (with a great range of experience and inexperience) I find p4200 error diagnostics quite valuable. One more check could hardly make much performance difference. I also have found that Proteon Gateway complaints are an excellent source for determining misconfigured hosts. Proteon might consider more extensive filtering capability and information about traffic activity. However, the key is the degree of user configurability of it. The statement that one more check could hardly make a difference can just lead on forever. We also use Vitalink bridge products a great deal, and have found one of the major wins on these pieces of equipment is the ability to create user defined packet characteristics about what gets forwarded. john
jqj@oregon.uoregon.edu (J Q Johnson) (01/17/89)
Two questions on Proteon routing and RIP: NorthWestNet is built with Proteon P4200s connected by 19.2Kb trellis on voice grade lines and 56Kb digital lines. We use RIP as our IGP. With two different line speeds and redundant paths, we sometimes have problems getting the default paths to be the least cost. Cursory reading of the P4200 manual indicates that there is no way to assign a higher than 1 cost to a serial line (so as to make a slow link appear to be 2 or 3 hops compared to a fast link). Am I correct, or is there some way to do this I don't see? Also, we're interested in investigating higher speed modems on voice grade lines as a way to reduce inequity. Does anyone have any experience with Microcom MNP level 9 modems (the things that are claimed to get 38.4Kb on voice grade lines) between Proteon routers?
louie@TRANTOR.UMD.EDU ("Louis A. Mamakos") (01/17/89)
I've also wanted the capability of assigning a metric of greater than 1 to a network interface. In my case, I have a choice between rundendent paths of pronet-80 and a ethernet-over-broadband. I'd like to force routes to the pronet unless its down. Also, has anyone got a tool to manage and load configurations of P4200's? It would sure be nice if you could configure them the say way we manage our Encore Annex terminal servers; they use an RPC based mechanism to set all of the vital parameters in the box. Maybe we can hope something will come of SNMP SETs... louie
CLIFF@UCBCMSA.BITNET (Cliff Frost {415} 642-5360) (01/18/89)
Hi,
Are you sending a whole pile of routes across your serial links, or
just default and possibly a couple of others? If just default and
one or two others, it's fairly easy to do what you want. If it's a
whole pile of routes it might be simple or impractical.
How to do it (if it's even possible) depends a lot on your specific
topology. Send me a note if you want to discuss it more.
Cliff Frost (415) 642-5360
Central Computing Services <cliff@berkeley.edu>
University of California CLIFF AT UCBCMSA
Berkeley, CA 94720
Re:
> NorthWestNet is built with Proteon P4200s connected by 19.2Kb trellis on
> voice grade lines and 56Kb digital lines. We use RIP as our IGP. With
> two different line speeds and redundant paths, we sometimes have
> problems getting the default paths to be the least cost. Cursory
> reading of the P4200 manual indicates that there is no way to assign a
> higher than 1 cost to a serial line (so as to make a slow link appear to
> be 2 or 3 hops compared to a fast link). Am I correct, or is there some
> way to do this I don't see?