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

Fri Jan 10 16:37:49 UTC 2014

On Thu, Jan 9, 2014 at 8:51 PM, Jeff Schmidt <jschmidt at jasadvisors.com> wrote:
>
> 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.

Yes -- that's true -- leaked requests will contain some sensitive data
-- which is why I think placing that information in the hands of
someone "trustworthy" is better than letting it go to whoever
registers secret-server.example -- and much of the reasons that I've
been pushing the [trial/pre/whatever we are calling it this week]
delegations.

It would not be hard for ICANN to host a webserver that:
a: strips all parameters from the URL before logging it (anything
after the /, anything of the form user:pass@, etc).
b: throws away cookies, all other headers.
c: Doesn't log usernames, etc for other protocols.
d: performs other sanitization (only log AS#, strip / elide last octet, etc.)
and have this behavior audited by <insert random auditor here>.

Returning 127.0.x.x does at least "break: the affected user,  but you
loose most of the visibility into who is affected and the scale.

If you get 1qps for login.example from 8.8.8.8 (or 4.2.2.2) , is that
one user? 1million users? Is it coming from Mom&Pop Flowers or the
Costa Rica Power Authority? If after 3 weeks you are still getting
1qps for login.example is it safe to delegate? Or, lets say you see
100qps for [every dictionary word].example as soon as you stand this
up, spread across a large number of resolvers.
You have no way of knowing if this is one person trying to monkey with
the process (reflected through open resolvers) or an actual thing.

Causing a request allows you to get much more visibility into this --
you can see the IP of the user, apply standard DoS tracking, etc.

Don't get me wrong, 127.0.x.x (which is *way* better than RFC1918) is
much better than nothing, but I wanted to explain my thoughts.

I realize that I'm trying to apply logic to a legal / liability
argument here... :-P

W
>
> 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