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

[David Conrad]

Joe,

On Jan 10, 2014, at 6:36 AM, Joe Abley <jabley at hopcount.ca> wrote:
> what hosts, when presented with a destination address of 127.0.53.53, might send traffic to the network, despite the requirements of RFC 1700? I would hope the answer is "none". But I have seen strange things in the world.

Assuming there are hosts that are sufficiently broken to try send out a packet to 127.0.53.53 (none of the system to which I have access do), what risks do you see? If there is a risk, what would stop miscreants from triggering that badness today?

I suppose if 127.0.53.53 is considered too risky, we could instead use 253.0.53.53 (since we're all told that doesn't work, right? :)).
 
>> Now, with that assumption, what traffic are you talking about?  The connection attempt by the application to 127.0.53.53?
> Yeah. So, this proposal is identical to the normal state of things in many respects, but it attempts to trigger local traffic rather than (potentially) traffic across the Internet in the event that an internal name starts to exist in the public namespace.

Yes, with the assumption that said attempts will fail quickly, resulting in action being taken by the folks behind the connection attempt to address the issue.

>> Err, what legal-economic difficulties?
> 
> The idea of changing the requirements for the root zone partners or new gTLD registry operators in how they perform a delegation,

As far as I am aware, no one is proposing changing requirements for the root zone partners.

WRT the new gTLD registry operators, I believe the goal here is to come up with a way to address name collision concerns so they can move towards regular operations and not have to worry about block lists, etc.

> e.g. for registry operators who have already passed pre-delegation testing and are perhaps already running some new gTLD registries in production.

I'm not positive (or authoritative in any way) but I don't believe folks who are already running in production will be forced to do anything they don't want to.  As I said, I believe for them, the idea is to allow them to move more quickly to normal operation.

>> Could you be explicit in the headaches you see?
> It seems like a lot of work for lawyers and developers,

Not being a lawyer, I'll not comment on that bit. What development do you see being necessary?

> it has the small chance of causing unexpected side-effects due to the way the slightly unusual address chosen,

If there is a risk, it exists today and can be triggered remotely by miscreants in a variety of ways. The chain of events necessary for something bad to happen because 127.0.53.53 is returned in an A query seems to me to be particularly remote.

> it's IPv4-centric,

True. For "AAAA" queries, I'd propose we return 0100::53 [RFC6666]. Not identical behavior to 127/8 in IPv4land, but presumably IPv6-capable networks are more up to date (as Jim suggests).

> it ignores the impact on protocols that are looking for resources other than A and MX

Eyeballing the stats on "L", it looks like "A" and "MX" account for around 60-70% of the queries received at the root. Add "AAAA" as suggested and that accounts for between 80-90%. We can, of course, add other RRs.

> and the benefit is only realised by end-users who read their logs (who, I might suggest, are probably capable of figuring this stuff out anyway, without this proposed modification to the delegation process).

No. Again, the benefit is in the 'fail quickly' bit that would impact the user of the machine. The use of 127.0.53.53 in the context of logs is primarily an aid for folks to track down why the applications that used to "work" when the TLDs were undelegated all of a sudden stopped "working" and an attempt to limit the amount of outbound traffic. 

> I realise I'm coming across as very negative about the whole idea. This is not a religious crusade against loopback abuse, and as I mentioned earlier I like the general line of thinking. But I don't think the benefits of this approach outweigh the costs.

Out of curiosity, what do you believe would be a solution that has a better cost/benefit ratio?

Thanks,
-drc

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.dns-oarc.net/pipermail/collisions/attachments/20140110/9a0d7c99/attachment-0001.pgp>