- Test - lists.nanog.org

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

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

16 Oct '98

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. ------- John Fraizer (tvo) | __ _ The System Administrator | / / (_)__ __ ____ __ | The choice mailto:tvo@EnterZone.Net | / /__/ / _ \/ // /\ \/ / | of a GNU http://www.EnterZone.Net/ | /____/_/_//_/\_,_/ /_/\_\ | Generation A 486 is a terrible thing to waste... On Fri, 16 Oct 1998, 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 >

1 0

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

16 Oct '98

Yes. --Dean At 01:12 PM 10/16/98 -0400, tvo wrote: >Doesn't this break MTU path discovery though? > > > >------- >John Fraizer (tvo) | __ _ >The System Administrator | / / (_)__ __ ____ __ | The choice >mailto:tvo@EnterZone.Net | / /__/ / _ \/ // /\ \/ / | of a GNU >http://www.EnterZone.Net/ | /____/_/_//_/\_,_/ /_/\_\ | Generation > A 486 is a terrible thing to waste... > >On Wed, 14 Oct 1998, I Am Not An Isp wrote: > >> At 05:11 PM 10/14/98 -0400, Barry Shein wrote: >> > >> >The following traceroute seems to indicate, according to ARIN, that >> >someone is running routers for spammers in the IANA Reserved netspace? >> >> [SNIP] >> >> >> 8 bs-jackson-gw.customer.alter.net (157.130.65.226) 107 ms 132 ms 96 ms >> >> 9 172.17.80.46 (172.17.80.46) 59 ms 53 ms 44 ms >> >>10 172.21.210.18 (172.21.210.18) 122 ms 96 ms 49 ms >> >>11 209.149.111.17 (209.149.111.17) 53 ms (ttl=118!) 58 ms (ttl=118!) >> 150 ms (ttl=118!) >> >> >What's going on here? >> >> Barry, 172.16.0.0/12 is part of RFC1918 space. There is no prohibition of >> addressing routers with these addresses, and in fact I do not know of a >> router that will route RFC1918 space differently than any other IP address. >> (Of course, you can put in filters, and many people do, but you can filter >> any addresses exactly the same way.) This is a perfectly legitimate use of >> RFC1918 space, as long as those hosts expect no connectivity outside their >> own network. Many people use RFC1918 on WAN links and whatnot to preserve >> their ARIN allocations for "real" hosts. Read the RFC for more info. >> >> > -Barry Shein >> >> 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 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

3 2