[Collisions] "controlled interruption" - 127/8 versus RFC1918 space

[Jeff Schmidt]

Hia, Warren:

I just responded to this issue over at DI but in a nutshell we don't want
to "cause" traffic to leave the host/LAN/enterprise.  We don't know what
it will contain, and it might contain sensitive/protected data, which
makes this much more complicating.  Using 127/8 or 1918 space eliminates
that can o' worms and is the more conservative approach in this dimension
we believe.

Jeff


On 1/9/14 5:20 PM, "Warren Kumari" <warren at kumari.net> wrote:

>On Thu, Jan 9, 2014 at 8:01 PM, Wayne MacLaurin <Wayne at demandmedia.com>
>wrote:
>> Hi folks.. I posted a longer reply on Domainincite but basically, if we
>>are going to accept that returning something other than NXDOMAIN is ok,
>>why don¹t we just make it useful  and avoid the Internet sleuthing for
>>the true meaning of 127.0.53.53?
>>
>> Get ICANN to host a nice informative website and point the IPs there..
>>If its not a human, its not going to work anyway.  If it is a human,
>>then we have ICANN¹s backing as to the how and why and what can be done
>>to fix the problem.
>
>
>Yup, that was part of the original proposal (and personally what I
>like the most) -- a web page that says:
>"Whoops, you probably didn't intend to get here -- hare are a bunch of
>resources to explain the issue."
>Same thing can be implemented for a whole heap-o-other protocols, like
>SMTP, Telnet/SSH, etc (I made a list somewhere).
>
>Apart from providing feedback to the user this also allows *much*
>better monitoring of the issue -- serving a A record gives you no real
>visibility into who is actually affected (just their NS) -- having the
>client connect gives you way more information about who and number.
>
>The big bugaboo here is what happens with the data -- but presumably
>ICANN could have a reasonable privacy policy...
>
>W
>
>
>
>
>
>>
>> Wayne
>> On Jan 9, 2014, at 4:25 PM, David Conrad <drc at virtualized.org> wrote:
>>
>>> Joe,
>>>
>>> On Jan 9, 2014, at 1:20 PM, Joe Abley <jabley at hopcount.ca> wrote:
>>>>> To an engineer, 127.0.53.53 is unusual enough to alert them as well
>>>>>as not send them chasing down non-problems.
>>>> A correct host implementation will not send datagrams to the network
>>>>with a source or destination address within 127/8 [RFC1700] or ::1/128
>>>>[RFC 4291].
>>>
>>> Yep.
>>>
>>>> However, it's not obvious what implementations do in real life.
>>>>RFC3330 comments that the IPv4 loopback address is "ordinarily
>>>>implemented using only 127.0.0.1/32", for example.
>>>
>>> I'm told Linux implements loopback as 127/8, but don't have one handy
>>>to test myself.
>>> MacOSX appears to time out going to anything in 127/8 other than
>>>127.0.0.1
>>> FreeBSD 8.2 and 9.1 says "sendto: can't assign requested address"
>>>
>>>> The goal of the work that triggered this thread is to keep traffic
>>>>triggered by the disappearance of NXDOMAIN responses for QNAMEs
>>>>subordinate (or identical) to new gTLDs local, ideally on the same
>>>>host that originated them, to avoid mysterious service failures or
>>>>information leakage.
>>>
>>> Err, not really. The goal is to interrupt service so people will
>>>notice and fix it, along the lines of registrations being dropped.
>>>Keeping traffic local and avoiding information leakage are side
>>>benefits. The choice of 127.0.53.53 was just to maybe provide an
>>>additional bit of information to folks who look at the log files on the
>>>machines that all of a sudden stopped working the way they used to
>>>(assumes the address connections are being attempted to are logged) and
>>>reduce the risk that there is actually a listener for a future
>>>connection attempt at 127.0.0.1.
>>>
>>>> So, the specification suggests that for IPv6 there's only one address
>>>>to play with, ::1/128.
>>>
>>> Yep.
>>>
>>>> What studies exist to confirm that (say) 127.0.53.53 won't attract
>>>>network traffic from a host?
>>>
>>> Sorry, don't understand the question -- unsure what 'attract network
>>>traffic' means. Do you mean whether anyone has looked to see if hosts
>>>will accept traffic off the wire at (say) 127.0.53.53?
>>>
>>>> What is the expected analogue to 127.0.53.53 for IPv6,
>>>
>>> Doesn't explicitly exist (of course). As mentioned, the intent is to
>>>hopefully provide a bit of help to folks who are unaware of the
>>>situation and who are trying to track down the problem. Personally I'd
>>>think for the purposes of this effort, we could squat on ::53 given the
>>>small likelihood that 0::0/122 will be allocated in the foreseeable
>>>future, but I can see that this position might be ... controversial
>>>(:)).
>>>
>>>> and what studies exist for how that traffic might be treated by a
>>>>variety of hosts?
>>>
>>> Just to clarify, the assumption is a scenario like:
>>>
>>> - Application (probably through a resolver) sends an A query to newly
>>>delegated "mumble.abley".
>>> - Name server for mumble.abley returns 127.0.53.53
>>> - Application attempts to open a connection to 127.0.53.53
>>> - Connection attempt fails, logging "connection attempt to
>>>'mumble.abley' (127.0.53.53) didn't return NXDOMAIN: launch the
>>>missiles!"
>>> - In the radioactive wasteland that remains, archeologists uncover the
>>>machine and look at the log file, notice 127.0.53.53 and say "Eureka!
>>>That's what happened! Damn you DNS search path!"
>>>
>>> Now, with that assumption, what traffic are you talking about?  The
>>>connection attempt by the application to 127.0.53.53?
>>>
>>>> [I like the out-of-boxness of the thinking that triggered all of
>>>>this, but I don't see it going anywhere. Quite aside from the
>>>>legal-economic difficulties in rebuilding the new gTLD aircraft in
>>>>flight alluded to earlier,
>>>
>>> Err, what legal-economic difficulties?
>>>
>>>> I think the ideas here involve unproved assumptions (e.g. wrt
>>>>127.0.53.53), are IPv4-centric and are likely to lead to more
>>>>headaches than they solve.]
>>>
>>>
>>> Could you be explicit in the headaches you see?
>>>
>>> Thanks,
>>> -drc
>>>
>>> _______________________________________________
>>> Collisions mailing list
>>> Collisions at lists.dns-oarc.net
>>> https://lists.dns-oarc.net/mailman/listinfo/collisions
>>
>>
>> Please NOTE: This electronic message, including any attachments, may
>>include privileged, confidential and/or inside information owned by
>>Demand Media, Inc. Any distribution or use of this communication by
>>anyone other than the intended recipient(s) is strictly prohibited and
>>may be unlawful.  If you are not the intended recipient, please notify
>>the sender by replying to this message and then delete it from your
>>system. Thank you.
>> _______________________________________________
>> Collisions mailing list
>> Collisions at lists.dns-oarc.net
>> https://lists.dns-oarc.net/mailman/listinfo/collisions
>_______________________________________________
>Collisions mailing list
>Collisions at lists.dns-oarc.net
>https://lists.dns-oarc.net/mailman/listinfo/collisions
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4376 bytes
Desc: not available
URL: <http://lists.dns-oarc.net/pipermail/collisions/attachments/20140110/c5c01bb7/attachment.bin>