- NANOG - lists.nanog.org

Re: Maybe I'm misreading this but...
by Darrell Fuhriman 17 Oct '98

17 Oct '98

I Am Not An Isp <patrick(a)ianai.net> writes: > However, there is nothing to distinguish a packet with RFC1918 space as the > source address from any other "legal" packet on the 'Net other than your > own administrative policies - which can break *anything* on the 'Net, not > just PMTU with RFC1918 space. Sorry, but I have no control over your > policy. So, if someone asks "does this break...", the answer is no. except that it is still a violation of RFC1918 to be using them in that manner, as they clearly excluded from category 1 (by virtue of being used in transit), and are clearly in Category 3. Category 1: hosts that do not require access to hosts in other enterprises or the Internet at large; hosts within this category may use IP addresses that are unambiguous within an enterprise, but may be ambiguous between enterprises. Category 2: hosts that need access to a limited set of outside services (e.g., E-mail, FTP, netnews, remote login) which can be handled by mediating gateways (e.g., application layer gateways). For many hosts in this category an unrestricted external access (provided via IP connectivity) may be unnecessary and even undesirable for privacy/security reasons. Just like hosts within the first category, such hosts may use IP addresses that are unambiguous within an enterprise, but may be ambiguous between enterprises. Category 3: hosts that need network layer access outside the enterprise (provided via IP connectivity); hosts in the last category require IP addresses that are globally unambiguous. We will refer to the hosts in the first and second categories as "private". We will refer to the hosts in the third category as "public". It's also a violation of RFC1918 to be using them in any way which will generate packets with those source addresses, which would mean traceroutes and using PMTU discovery. Because private addresses have no global meaning, routing information about private networks shall not be propagated on inter-enterprise links, and packets with private source or destination addresses should not be forwarded across such links. Routers in networks not using private address space, especially those of Internet service providers, are expected to be configured to reject (filter out) routing information about private networks. If such a router receives such information the rejection shall not be treated as a routing protocol error. So, if the question is "does using RFC1918 address break PMTU discovery?" the answer should be "maybe it won't, break it, but it's supposed to" Darrell

1 0

Re: Internet 1, Backhoe 0
by David Lesher 17 Oct '98

17 Oct '98

seen: Moore's Law does not apply to backhoes -- Aaron Goldberg -- A host is a host from coast to coast.................wb8foz(a)nrk.com & no one will talk to a host that's close........[v].(301) 56-LINUX Unless the host (that isn't close).........................pob 1433 is busy, hung or dead....................................20915-1433

2 1

Re: Maybe I'm misreading this but...
by Dean Anderson 16 Oct '98

16 Oct '98

You are correct in that there is nothing a-priori magical about RFC1918 addresses. "If you route them, they will pass". This is why one shouldn't make security assumptions about using "unrouteable" address space. It is no more or less secure than the routers leading to the network. But Path MTU discovery is a bit more complicated. I'm not looking at any docs at the moment, so I hope I'm not completely wrong about this, but as I recall the discovery process tries to send packets to each hop. First discovering the route path, and then trying to determine the mtu of each hop. While the intermediate RFC1918 addresses can reply to things they happen to get, you can't directly send a packet to them to see if they will want to fragment it. But perhaps it would work if everyone accepted rfc1918 sourced packets. However this isn't the case either. So I think it is safe to assume that PMTU is broken whenever RFC1918 networks are touched. --Dean At 12:08 PM 10/16/98 -0700, I Am Not An Isp wrote: >At 01:12 PM 10/16/98 -0400, tvo wrote: >>Doesn't this break MTU path discovery though? > >No, it wouldn't. Those addresses are not routable on the global 'Net, >however, there is nothing stopping a device with an RFC1918 address from >sending a packet onto the 'Net. > >Assume you have a T1 between two routers, but you are out of 'normal' >addresses. So you make the two serial ports 10.1.1.1 and 10.1.1.2. >Simple, huh? Well, anyone outside your network attempting to reach those >addresses will fail - there is no route to 10.x.x.x on the Internet. (At >least not in *my* network. :) Let's further assume there's a LAN on the >other side of this T1 with a MTU below 1500 bytes. Now, when you attempt >PMTU discovery to a device on that small MTU LAN (going through the T1 of >course), what happens? When the router on the opposite end of the T1 gets >the packet, it sees that the packet is "too big" and DF bit is set (as per >PMTU rules) and cannot send the packet. So what should it do? Why send an >ICMP "Datagram Too Big" error message, of course. (Type 3, "Destination >Unreachable", Code 4, "fragmentation needed and DF set". See RFC 1191, >http://www.pmg.lcs.mit.edu/cgi-bin/rfc/view-plain?number=1191, and RFC 792, >http://www.pmg.lcs.mit.edu/cgi-bin/rfc/view?792, for more info.) Just like >any other (properly functioning) router on the Internet. But what's the >source address? Why 10.1.1.1 of course. So you get a packet from RFC1918 >space. Perfectly normal, perfectly acceptable, perfectly legitimate. > >See, when a router gets a packet, it does not look at the source IP for >routing info. (Unless you're doing something weird like policy routing.) >So the source IP is irrelevant to a router. Hell, even the destination IP >is irrelevant as long as it's 32 bits and matches something in the router's >table (including a possible default route). I have never seen a router >vendor treat a packet with RFC1918 space in source or destination any >differently than any other packet. Unless, of course, the user manually >modifies the default behavior with filters or something - which can be done >to any address just as easily. > >The point is, there is magical router fairy looking for RFC1918 space and >removing all those packets from your network. Those addresses are treated >by your router just like *any other address*. Forwarded, filtered, >whatever depending upon the rules you set up and the information it >receives dynamically. > >I hope that explains everything. > >TTFN, >patrick > >I Am Not An Isp >www.ianai.net >"Think of it as evolution in action." - Niven & Pournelle > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Plain Aviation, Inc dean(a)av8.com LAN/WAN/UNIX/NT/TCPIP http://www.av8.com ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

5 5

Re: Maybe I'm misreading this but...
by I Am Not An Isp 16 Oct '98

16 Oct '98

At 04:27 PM 10/16/98 -0500, John A. Tamplin wrote: >Well, with this definition, I could just decide to start using someone >else's address space and if you filter it your policies have broken >things, not me. Private address space is intended to be used for networks >not directly connected to the Internet. We filter every external link to >prevent private addresses flowing in either direction, outside packets >claiming to be from our address space, inside packets not coming from our >address space (and transit customers), and inside packets going to our >address space. Until router CPU or number of filter entries are a problem, >it makes sense to make sure everything is what is expected, and to drop >anything that isn't. This is getting way out of hand. The original question was "Does this break PMTU" (paraphrased), to which the answer is "NO". There may or may not be external factors which, in combination with RFC1918 space, breaks PMTU. But the answer to the original question is still "no". Thank you all for pointing out the possible (and even probable) external factors which may combine to interfere with PMTU in this case. >If they really don't want to use up valid addresses for the point-to-point >links, why not just run the interfaces unnumbered instead? IMHO, numbered interfaces are easier to deal with and troubleshoot. Not to mention it keeps people from directly addressing your router ports outside your own network. Besides, I just made that example up. Maybe some people do it intentionally for reasons I haven't though of. >John Tamplin Traveller Information Services TTFN, patrick I Am Not An Isp www.ianai.net "Think of it as evolution in action." - Niven & Pournelle

1 0

Re: WARNING: AOL is hosed (again)
by CyberTech/CTCS%CTCS＠ctcs.net 16 Oct '98

16 Oct '98

Just FYI.. I have personally NAK'd 4 updates sent in by clients of mine which effected domains on my servers. The updates were technically correct (for auto-processing), but had the wrong information. internic conveniently ignored the NAK's, all of them. Phillip Vandry <vandry(a)Mlink.NET>@merit.edu on 10/16/98 09:37:59 AM Sent by: owner-nanog(a)merit.edu To: jamie(a)ais.net cc: markb(a)infi.net, nanog(a)merit.edu (bcc: CyberTech/CTCS) Subject: Re: WARNING: AOL is hosed (again) > > If yes to my second question, then the tracking numbers either need to be > > made much longer and randomized or a one time pass phrase (session key) > > needs to be added to the acknowlegement form. > > You can actually set a domain name so that it cannot be changed, by > any template, by any modification, correct guardian or NOT. Sounds like a nonreversible setting to me. What if you need to change it? Anyway, I think that by default, the update goes through automatically, a positive acknoledgement is ignored (default behaviour) and a negative acknowledgement is honored. (Which means AOL should have been able to stop it). Then there is the setting where the update will not go through by default, and a positive acknowledgement is required. As to whether it all works as advertized (and PGP auth too?), who knows? -Phil

1 0

Re: Maybe I'm misreading this but...
by shields＠crosslink.net 16 Oct '98

16 Oct '98

In article <199810161909.PAA16027(a)merit.edu>, I Am Not An Isp <patrick(a)ianai.net> wrote: > At 01:12 PM 10/16/98 -0400, tvo wrote: > >Doesn't this break MTU path discovery though? > > No, it wouldn't. Those addresses are not routable on the global 'Net, > however, there is nothing stopping a device with an RFC1918 address from > sending a packet onto the 'Net. Except that many people filter out RFC 1918 at ingress, in the same ACL that blocks spoofing of your own blocks. (although if you see it in a traceroute you know that's not happening) -- Shields, CrossLink.

1 0

primary for aol.com?
by bryan s. blank 16 Oct '98

16 Oct '98

went ahead and went authorative for aol for the time being, this might not be what aol wants everyone to do, and it might hit some MX'es harder than others, but since i can't get anything other than a voice jail at their contact number, and nothing has been posted on a web page, it seems to be a good way to keep from queuing mail and keeping customers happy. if anyone from aol would like us to all go authorative for a better copy of a zone file than what i threw together from dig, just point me to it and i'll drop it in, no problem. this should get interesting mediawise hang in there ... @ SOA mars.discovernet.net. bryanb.discovernet.net. ( 1998081601 21600 ; refresh 3600 ; retry 604800 ; expire 86400 ) ; minimum aol.com. 15797 NS DNS-02.NS.aol.com. aol.com. 15797 NS DNS-01.NS.aol.com. DNS-02.NS.aol.com. 70232 A 152.163.200.116 DNS-01.NS.aol.com. 70232 A 152.163.200.52 aol.com. 340 MX 15 a.mx.aol.com. www.aol.com. 3595 CNAME aol.com. aol.com. 3595 A 152.163.210.12 aol.com. 3595 A 152.163.210.13 aol.com. 3595 A 152.163.210.25 aol.com. 3595 A 152.163.210.27 aol.com. 3595 A 152.163.210.28 aol.com. 3595 A 152.163.210.29 aol.com. 3595 A 152.163.210.7 aol.com. 3595 A 152.163.210.8 aol.com. 3595 A 152.163.210.9 aol.com. 3595 A 152.163.210.10 aol.com. 3595 A 152.163.210.11 a.mx.aol.com. 62 A 198.81.19.137 a.mx.aol.com. 62 A 198.81.19.210 a.mx.aol.com. 62 A 198.81.19.139 a.mx.aol.com. 62 A 198.81.19.83 a.mx.aol.com. 62 A 198.81.19.84 a.mx.aol.com. 62 A 198.81.19.70 a.mx.aol.com. 62 A 198.81.19.85 a.mx.aol.com. 62 A 198.81.19.82 a.mx.aol.com. 62 A 198.81.19.81 members.aol.com. 3460 A 152.163.200.196 members.aol.com. 3460 A 152.163.200.197 members.aol.com. 3460 A 152.163.216.137 members.aol.com. 3460 A 152.163.216.138 members.aol.com. 3460 A 152.163.216.139 members.aol.com. 3460 A 152.163.216.140 members.aol.com. 3460 A 152.163.216.141 members.aol.com. 3460 A 152.163.200.193 members.aol.com. 3460 A 152.163.200.194 members.aol.com. 3460 A 152.163.200.195 americaonline.aol.com. 3232 CNAME dial.internet.aol.com. dial.internet.aol.com. 532 CNAME 11.internet.aol.com. 11.internet.aol.com. 532 A 198.81.28.4 11.internet.aol.com. 532 A 198.81.28.8 11.internet.aol.com. 532 A 205.188.126.4 11.internet.aol.com. 532 A 205.188.126.8 11.internet.aol.com. 532 A 198.81.28.36 11.internet.aol.com. 532 A 198.81.28.40 |o|----------------------------------------------------------------------|o| |o| bryan s. blank (203)-351-1178 voice |o| |o| senior systems analyst (203)-351-1186 fax |o| |o| discovernet, incorporated (203)-979-5126 emerg |o|

3 4

Re: WARNING: AOL is hosed (again)
by Sean Donelan 16 Oct '98

16 Oct '98

>This is too trivial for words. We do SSL authenticated registrations for >our normal order processing, using CC transactions. I have always wondered >why NSI can't run both SSL and take immediate CC payments for >domain-registrations. It's not like they don't have the cash to make this >happen. It also wouldn't hurt to setup some ssh-forwarded ports and drop >the whole mess behind a firewall either. Run of the mill SSL does not protect against client forgery or impersonation. It protects against transmission wiretapping and some types of server impersonation. I can use a forged credit card number with SSL. Encryption is not a magic wand. On the other hand, security is a pain. I know I haven't taken advantage of all the security features NSI offers for all the objects I have registered over the years. The Guardian workflow process is still annoyingly convuleted enough, the default ends up being no protection if you miss or forget any of the steps. I guess it makes sense from NSI's point of view, cutting down on the number of 'lost' password or PGP key calls. Tell me again, what's your mother's maiden name? -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

3 2

Re: Maybe I'm misreading this but...
by I Am Not An Isp 16 Oct '98

16 Oct '98

At 04:58 PM 10/16/98 -0400, tvo wrote: >Well, that is all fine and well if the device with the RFC1918 address is >the one screaming "Too Boocoo!" but if it's some other box trying to tell >it that the packets are too bug, no dice. Non-routable address. If you mean "if some device tries to tell the RFC1918 box the packet is too large", this is correct. However, the same reasoning shows that *ANY* session opened between an RFC1918 box and a random host on the Internet will break as well. I suppose you could be talking about a one-way transmission of data from the RFC1918 box to a random host. If so, yes, you are SOL. I just don't see a whole lot of that. ;) TTFN, patrick I Am Not An Isp www.ianai.net "Think of it as evolution in action." - Niven & Pournelle

1 0

Re: Maybe I'm misreading this but...
by Dean Anderson 16 Oct '98

16 Oct '98

Sorry. I stand corrected. --Dean At 02:00 PM 10/16/98 -0700, I Am Not An Isp wrote: >At 04:37 PM 10/16/98 -0400, Dean Anderson wrote: > >>But Path MTU discovery is a bit more complicated. I'm not looking at any >>docs at the moment, so I hope I'm not completely wrong about this, but as I >>recall the discovery process tries to send packets to each hop. First >>discovering the route path, and then trying to determine the mtu of each >>hop. While the intermediate RFC1918 addresses can reply to things they >>happen to get, you can't directly send a packet to them to see if they will >>want to fragment it. > >This is incorrect. From RFC1191, which can be found at >http://www.pmg.lcs.mit.edu/cgi-bin/rfc/view-plain?number=1191, page 2, >section "2. Protocol overview": > ><quote> > The basic idea is that a source host initially assumes that the PMTU > of a path is the (known) MTU of its first hop, and sends all > datagrams on that path with the DF bit set. If any of the datagrams > are too large to be forwarded without fragmentation by some router > along the path, that router will discard them and return ICMP > Destination Unreachable messages with a code meaning "fragmentation > needed and DF set" [7]. Upon receipt of such a message (henceforth > called a "Datagram Too Big" message), the source host reduces its > assumed PMTU for the path. ></quote> > >So, as I stated in my last post, it will work unless you filter RFC1918 >space. I've received lots & lots of replies saying "I filter it", or "I >RFC1918 in my own LAN, so the firewall drops the packets assuming they are >spoofed" or stuff like that. This is fine, and possibly even desirable. >However, there is nothing to distinguish a packet with RFC1918 space as the >source address from any other "legal" packet on the 'Net other than your >own administrative policies - which can break *anything* on the 'Net, not >just PMTU with RFC1918 space. Sorry, but I have no control over your >policy. So, if someone asks "does this break...", the answer is no. > >> --Dean > >TTFN, >patrick > >I Am Not An Isp >www.ianai.net >"Think of it as evolution in action." - Niven & Pournelle > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Plain Aviation, Inc dean(a)av8.com LAN/WAN/UNIX/NT/TCPIP http://www.av8.com ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

1 0