Subject: [Anima] eckert-anima-stable-connectivity

From: Michael Richardson <[email-masked]>
Date: Sun, 23 Nov 2014 16:15:10 -0500

section 2.1.3 suggests that the ACP would be numbered out of ULA.
This would make sense for IoT-type uses, but I don't think operators would
want to use ULA.  There are two reasons for this:
  1) lack of whois means that diagnostics and packet leaks, particularly
     at the edge of the network are rather hard to diagnose. Operators
     will want to use address space with whois.  Not that this doesn't
     mean globally routable, ULA-C would work, or some form of Non-Connected
     Network pool would be ideal for this. (This is a recurring thing that
     I and a few others bring up at ARIN since around 2008, but so far
     few care about non-public-internet IPv6 needs.)

  2) reverse DNS is important for things like SSH connections, especially
     with IPv6.  It's hard to get ULA reverse setup, because it requires
     a split-horizon DNS, which means that that one has to be able to contr=
ol
     every single DNS request to go out to one's internal servers.
     This means getting the network to be completely concave.

I predict that ACP will occasionally make associations between adjacent
operators (across peering links).  This is fine: the connection will come up,
and then the two peers will say, "hey, that's not the AUTONOMOUS SYSTEM I was
looking for", and each will want to log the other's IP, so even if one can
arrange for concave DNS, it's a good idea to be able to see other side's
reverse names too.

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 28 Nov 2014 17:26:23 -0800

>      few care about non-public-internet IPv6 needs.)

Hmm.. We propose (and did implement) ULA because it make zero-touch
address assignment easy. I also thought it was a benefit to have non
Internte routeable addresses for an OAM plan that ultimately is meant to be
protected from outside access.

I am sure it would be possible to make ACP work with a different prefix
than ULA. Could for example be derived from S-UDI subject name elements.

>      a split-horizon DNS, which means that that one has to be able to control

Well... It wouldn't be "anywhere" in the network, but just within
dedicated management areas (NOC). Any stats how popular or unpopular 
split-DNS is ? I've seen companies seeing it as a big benefit. DOes
the IETF have any docs that make judgement calls about it ?

> arrange for concave DNS, it's a good idea to be able to see other side's

So thats the first explicit example of diagnostic, and it's a good one.
I'd say we could also put the diagnostics into the AN discovery protocols
aka: have them announce a domain-name.

Thanks a lot for these comments. Will integrte the technical aspects into
the draft.

Cheers
    Toerless

> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima

-- 
---
Toerless Eckert, [email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 30 Nov 2014 07:55:30 +1300

> On Sun, Nov 23, 2014 at 04:15:10PM -0500, Michael Richardson wrote:
...
>>      with IPv6.

I see this as a potential problem. It is widely felt that
reverse DNS is a bogus requirement, because tens of millions of
reverse DNS entries are automatically synthesised and therefore
meaningless as any kind of authentication. There are also
already numerous reports of operational failures caused by mail
exchangers and the like that expect them for IPv6.

I think we should draw a line in the sand and ensure that
nothing in anima requires reverse DNS. It certainly has no place
in a trust model.

I think ULAs are a fine idea for this, but we do have to work
out the rules if a network partitions or merges. Probably the
NOC itself needs to "own" the ULA (but then is the NOC itself
distributed, in which case who owns the prefix after partition?).

Of course there should be an option to use a normal prefix if
the operator prefers.

   Brian

---

From: Michael Richardson <[email-masked]>
Date: Sun, 30 Nov 2014 12:19:32 -0500

> protected from outside access.

Yes,  I totally agree with it being non-routed.
I'm saying the problem is with ULA-R.

    > the IETF have any docs that make judgement calls about it ?

Split-DNS is impossible for many ISPs --- their networks are not concave.
Some try. Many fail.  The result is usually IP[v4] address literals in config
files, which makes upgrade to IPv6 very very very error prone.

Split-DNS is very very problematic for enterprises that have road warriors
because the remote-access connections make their network not concave... 

If you  then throw  *contractors*  who sit inside Enterprise A, and have
connectivity to the inside of Enterprise B, and it's impossible.  Those folks
either have a horrible life of "VPN on" / "work a bit" / "VPN off" / "work a bit"/..
or they just resort to using IP address literals, because nothing else works.

    > Thanks a lot for these comments. Will integrte the technical aspects into

Thanks.
{I sold some of the first commercial firewalls in the mid-1990s that included
split-DNS as not only the recommended option, but the default, hard-to-change
option, and I see it as being a serious serious mistake.  It was
security-through-obscurity. }

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: joel jaeggli <[email-masked]>
Date: Sun, 30 Nov 2014 09:27:56 -0800

> or they just resort to using IP address literals, because nothing else works.

Resolvers don't come with scopes attached to them (neither do names) so
the "I have to make this work with more than one set at the same time"
is basically  a non-starter.

Even those those of us who have had to misfortune to have to deploy it
typically expect it to break with some regularity.

---

From: Michael Richardson <[email-masked]>
Date: Sun, 30 Nov 2014 12:57:24 -0500

> meaningless as any kind of authentication. There are also

It was never about authentication, and the various detractors of reverse DNS
do not listen very well.  It's about auditing, and it's about reputation.

    > exchangers and the like that expect them for IPv6.

Too late. 
You can not deliver email to any major provider over IPv6 without a valid
reverse name.  Should his affect ANIMA?  I don't think so, but that boat has
sailed. 

The problem with ULA-Random in an enterprise is that, when it escapes, it is
impossible to know who is using it for what.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 01 Dec 2014 08:08:13 +1300

> do not listen very well.  It's about auditing, and it's about reputation.

Yes, my choice of word was sloppy, but as far as I'm concerned the fact
that many if not most reverse records are automatically synthesised
destroys their value for auditing, reputation and pretty much everything
else.

> reverse name.  

I know, and that's exactly why it's already meaningless.

> Should his affect ANIMA?  I don't think so, but that boat has
> sailed. 

Indeed. In the anima context, all I'm saying is that we shouldn't
accidentally end up depending on it.

> impossible to know who is using it for what.

Well, that's also a feature, from a privacy PoV.

   Brian

---

From: Michael Richardson <[email-masked]>
Date: Sun, 30 Nov 2014 18:07:43 -0500

> destroys their value for auditing, reputation and pretty much everything

1) they won't be synthesized in IPv6 :-)

2) synthesized records that say ip231.example.com may be WAY more useful
   (particularly if the forward is there too) because it points you at
   [email-masked], rather than the SWIP entry of [email-masked].

Let me assure you that this is hugely valuable information to have in logs,
and short cuts a great deal of investigation.   

    > Well, that's also a feature, from a privacy PoV.

When you have traffic on *your* network with source addresses you can not
identify, and therefore can not easily track it back to the
faulty/misconfigured device, it is not a feature.  It's an **attack**
Dealing with this kind of attack is likely to cause one to deploy lots and
lots of privacy violating devices inside the enterprise.  I love privacy too
(I will claim: more than you many people),  but I do not think the upper
64-bits of an address can be private.   Remember: the traffic isn't going
anywhere: BCP38 filtering at some point will kill it outbound, and there can
never be any inbound traffic responding.  

A BCP38-related question about Anima Control Plane would be: what kind of
filtering is appropriate.  Consider two networks which merge... does one
renumber?  

I propose that we adopt some terminology from chemistry for our networks.

Individual ANIMA entites are atoms... they can form bonds to other atoms to
form molecules.  Molecules may coalese to form bigger molecules.

A molecule (can become)/is "grounded" (a RPL term) to a substrate
(i.e. a NOC).   We may have a use for the various kinds of bonds (covalent,
ionic, hydrogen, van-der-Walls)...   I would claim that molecules that
spontaneously form should use ULA-R until such time as they become grounded,
at which point they would adopt the numbering from the NOC (which I suggest
should be NCN or ULA-C).

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 01 Dec 2014 14:17:55 +1300

> 1) they won't be synthesized in IPv6 :-)

Right, and I certainly don't expect them to exist for an ACP.

> and short cuts a great deal of investigation.   

Yes, I can believe that. Peace, it's a side issue for anima.

> never be any inbound traffic responding.  

Exactly, and site egresses should stop it even before it hits any BCP38 filters.
So I have never had any real level of concern about ULA leakage; I don't
really see why it's going to happen more than say Net 10 leakage does today.

> filtering is appropriate.  Consider two networks which merge... does one

Yes, both splits and merges are an issue. In the "professionally managed"
networks that anima is scoped for, hopefully there will not be unplanned
merges, but we do need to consider these issues.

> at which point they would adopt the numbering from the NOC (which I suggest

But there's no such thing as ULA-C. Also, the way enterprise networks
are extended is a bit different from IoT or homenets in this respect. I think
the model needs to be flexible on what kind of prefix is used. I do agree
with your implication that renumbering of the ACP needs to be regarded
as a routine event (e.g., assume renumbering might happen after every
significant outage and again after the outage is fixed). Node identities
should matter a lot more than node addresses.

    Brian