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

Jeff Schmidt jschmidt at jasadvisors.com
Fri Jan 10 21:08:33 UTC 2014


Hia, Jim:

On 1/10/14 11:41 AM, "Jim Reid" <jim at rfc1035.com> wrote:

>On 10 Jan 2014, at 17:12, Jeff Schmidt <jschmidt at jasadvisors.com> wrote:
>
>>This may actually making things worse than they are now - where NX
>>means nothing is transmitted.
>
>That's an unsound assumption.

Wasn't an assumption but one of two likely scenarios that are happening
today:

1). Today, the NX happens as one step along a "walk" leading to an
eventually successful resolution. In this case, the (application layer)
data gets transmitted anyway (today), and the application is exposed to
unknown risk because: a). The transmitted data might not be going to the
intended party (and possibly following an untrusted path); and b). Will
likely break at some unknown future point, Bad Guy M could do Bad Thing X,
Y, Z, etc. Returning something other than NX would be designed to help
that guy by causing a closed fail during a scheduled time. If things
happen to be working for him now, it's because of technical happenstance.

2). Today, the NX kills things and the application sits in a retry loop.
In this case, nothing is transmitted. This is the scenario we don't want
to make worse by returning a routable IP which suddenly causes data to be
transmitted that wasn't transmitted before and creating new risks that
didn't exist before.

>Pointing them at an address in 127/8 or some (presumably ICANN run)
>thing which says "you've come here because
>of a gTLD collision" is not going to have a happy ending.

Please elaborate.

Thx,
Jeff

-------------- 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/8cf395fe/attachment.bin>


More information about the Collisions mailing list