Re: [v6ops] [GROW] Deaggregation by large organizations

[Owen DeLong <[e-mail]>]

On Oct 16, 2014, at 16:35 , Mark Andrews <[e-mail]> wrote:

> 
> In message <[e-mail]>, Owen DeLong writes:
>> 
>> On Oct 16, 2014, at 02:43 , Iljitsch van Beijnum <[e-mail]> wrote:
>> 
>>> Let me address a few points that were brought up by different people.
>>> 
>>> Renumbering:
>>> 
>>> We had great plans for making renumbering easy in the early days of IPv6. Remember A6 records and bit
>> labels in the DNS? But none of that went anywhere. The problem isn't so much that we can't push a prefi
>> x down the network or update the DNS (although both of these still have challenges associated with them
>> ), but that addresses tend to get hardcoded all over the place, starting with firewalls all the way up 
>> to homegrown applications. I don't think renumbering addresses this issue, although it could help steer
>> some smaller organizations away from PI.
>> 
>> They never went anywhere because they focused on solving the easy part of the renumbering problem while
>> utterly and completely ignoring the hard part.
>> 
>> Easy part: Changing your stuff.
>> Hard part: Updating all of the prefix lists, filters, firewall rules, VPN configurations, and other con
>> figuration elements in systems not under your control that contain your prefixes (partner VPNs, peer ro
>> uters, etc.).
> 
> Owen this a collective response to the list.
> 
> Not all that hard at all.  Just send signed update requests.  I did
> that with email over a decade ago.  You just have to have something
> listening for them that verifies the signature and updates the
> system.

No, you have to have all your {customers, suppliers, partners, etc.} implement
a compatible system of listeners that can configure their equipment on the basis
of those requests.

> Write a draft "Remote Firewall Update Request Protocol" and submit
> it.

I don't have time to engage in this, but I think such a thing would be a
more useful use of IETF time than what has been proposed in the earlier
discussions in this thread. I still question whether it would get widely
adopted, but having it documented would at least be a good first step.

> The alternative is stop worrying about the remote address and use
> security at the application layer.

Again, not a solution unless you can achieve ubiquitous deployment of
such a scenario.

> Or complain to your vendor that you can't use a hostname in the
> configuration file element.  In many cases it doesn't require
> anything more than looking up a address in the DNS before the
> operation.  Yes, I need to fix the masters clause in named to support
> this.  We already do something similar for NOTIFY messages so it
> is possible to do this.

It's not my vendor that's at issue here. I can configure whatever I bought
from my vendor. Convincing my {customers', suppliers', partners'} vendors
to listen to me is, well, unlikely. Convincing my {customers, suppliers, partners}
to make demands of their vendors on my behalf is slightly less likely.

> For masters clauses there is a bootstrap problem to deal with but
> it is not impossible.  Just sending periodic NOTIFY messages will
> work.  Named has had support to do this for 1 1/2 decades now to
> allow for a a stealth master behind a dial on demand link.  It would
> send a notify periodically.  That would bring up the line.  The
> slave would refresh and transfer if required.  When that was complete
> the idle timer on link would drop it.

Less concerned about that than the above issues. Do you really think that
partner A wants to allow partner B to send signed messages to modify his
firewall configuratoin? Who is liable for what happens to partner A if partner
B's private key gets compromised? The transitive trust involved in such a
scenario is not something I have found to be widely accepted by enterprise
security people.

> This just used standard signalling designed by the IETF in a different
> way.
> 
> Stop expecting someone else to *find* and fix these issues for you.
> You know what the issues are.  Ask your vendors to fix them.  If
> they need to co-ordinate they should know where to go to do it.

I don't expect them to get fixed. They've been widely known for years. They're not
easy problems to solve and there isn't money commensurate with their difficulty
available to solve them. Further, the human interface problems involved are probably
just as difficult if not more so than the technical hurdles, so even if the technology
were miraculously solved, it might not matter.

Owen