Subject: [homenet] routing protocol comparison document and hncp

From: Christian Hopps <[email-masked]>
Date: Mon, 2 Mar 2015 07:33:47 -0500

Hi homenet-wg,

One thing that has been mentioned to me is that IS-IS could be used (with proper TLV additions) to completely replace HNCP, if IS-IS were used as the homenet protocol. If true should we be calling this out more explicitly in the document?

Thanks,
Chris.

---

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 02 Mar 2015 14:00:32 +0100

> One thing that has been mentioned to me is that IS-IS could be used
> (with proper TLV additions) to completely replace HNCP, if IS-IS were
> used as the homenet protocol.

I see that you've been speaking with Abrahamsson.  Please let me give you
some background.

Two years ago, there was a very animated discussion about whether the
configuration protocol and the routing protocol should be separate or not.
After a lot of energy was spent on the issue, Markus designed HNCP, which
went through a few iterations.  The chairs judged that WG consensus was
achieved, and the configuration protocol is now separate from the routing
protocol.

Since achieving consensus on this was a lot of work, some of us are
somewhat annoyed at Mikael bringing this argument back from the dead at
every opportunity.

> If true should we be calling this out more explicitly in the document?

I seem to recall that I already mentioned that I find your tendency to
bring out controversial arguments just before a deadline somewhat offputting.

-- Juliusz

---

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 02 Mar 2015 14:03:12 +0100

This was of course meant to go out by private mail.

I most sincerely apologise to both Mikael and Chris -- both the tone and
the content of this mail are completely innapropriate for a public forum.

-- Juliusz

---

From: Gert Doering <[email-masked]>
Date: Mon, 2 Mar 2015 14:03:30 +0100

Hi,

> One thing that has been mentioned to me is that IS-IS could be used (with proper TLV additions) to completely replace HNCP, if IS-IS were used as the homenet protocol. If true should we be calling…

I'm sure we could, but "what is it that the WG wants?"

 - achieve something that vendors could deploy, in finite time

 - do another few rounds on protocols, variations, personal peeves, and
   end up with something like IPSEC?

I'm firmly in the "do something that is good enough, and get it deployed"
camp, which means "no, we don't do everything-on-top-of-ISIS".

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279

---

From: Markus Stenberg <[email-masked]>
Date: Mon, 2 Mar 2015 15:11:50 +0200

> somewhat annoyed at Mikael bringing this argument back from the dead at

Funny part is, the argument has changed substantially since. Originally I considered HNCP security to be strictly optional, but as there was push-back to have built-in security, I added it in. And now it is essentially more littleconf’able than any routing protocol security scheme I have ever met before.

The current draft specifies only PSK based security; do you really want to bootstrap your home security either with well-known ‘IamGoodguy’ password, or perhaps by logging in to every router to do magic things?

No, me neither.

I am looking forward to hearing some of some relatively dynamic security protocol (think IKE, or TLS handshake) that runs on top of CLNP though that we can hook in to IS-IS. The current draft’s ’security’ requirements for (stand-alone) use of either routing protocol’s own security framework are inadequate to what the group has been discussing here (among other places) over the last year.

Cheers,

-Markus

---

From: Christian Hopps <[email-masked]>
Date: Mon, 2 Mar 2015 08:36:58 -0500

> On Mar 2, 2015, at 8:00 AM, Juliusz Chroboczek <[email-masked]> wrote:
> 

It’s not just Mikael that has this opinion, he’s just the more active email participant.

> bring out controversial arguments just before a deadline somewhat offputting.

There was nothing nefarious here. I just thought of a question and raised it. I think we should be open to doing that any time free of attack.

Thanks,
Chris.

---

From: Margaret Wasserman <[email-masked]>
Date: Mon, 2 Mar 2015 08:47:16 -0500

Juliusz, I've actually been wondering about this, too.

I am not sure about the history here, because the last version of HNCP I read (in preparation for the last IETF meeting), HNCP contained its own (underspecified) link-state routing protocol…  If that protocol were replaced with an already-existing link-state routing protocol, one that had the ability flood additional information about the links, it might be possible to use that already-existing routing protocol as the underlying communication mechanism for HNCP.  We would still need to specify what HNCP information is sent, but the routing information and HNCP information could, possibly, be transmitted over the same protocol.  I don't know if that would work with a non-link-state routing protocol, as part of what HNCP was using its internal routing protocol to distribute was information about all of the links.

I don't know what facilities IS-IS or Babel have for sending additional information about each link, and I don't know if we actually want to require that very node that needs HNCP information run IS-IS or Babel, but I think this is worth considering.  I will think about this, read some stuff, and try to come up with my own opinion about it ASAP. I would suggest that other people do that, too.

I think Markus' comments on security are also very important to consider here, as some sort of integrated security mechanism between the routing protocol and HNCP might be strongly desired.

Margaret

On Mar 2, 2015, at 8:00 AM, Juliusz Chroboczek <[email-masked]> wrote:

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

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 2 Mar 2015 14:55:44 +0100 (CET)

On Mon, 2 Mar 2015, Margaret Wasserman wrote:

> I think Markus' comments on security are also very important to consider 
> here, as some sort of integrated security mechanism between the routing 
> protocol and HNCP might be strongly desired.

Yes, I agree that HNCP has gained security that currently none of the 
routing protocols have, and that this is important.

Then one can always discuss what kind of information could go into each 
protocol after bootstrap. Perhaps what we actually need is a new bootstrap 
security protocol (not only for homenet), and that this is where the 
emphasis should be.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Steven Barth <[email-masked]>
Date: Mon, 02 Mar 2015 15:07:48 +0100

> One thing that has been mentioned to me is that IS-IS could be used (with proper TLV additions) to completely replace HNCP, if IS-IS were used as the homenet protocol. If true should we be calling…
I got my hands on ISO 10589 today and tried to very briefly glance 
through it. And personally I had a really hard time getting into it.

Having read the comparison document beforehand I haven't found anything 
about IPv4, IPv6, HMACs, wide-metrics or other things that are mentioned 
in the draft (and that ISO standard was ~200 pages already).

So I think I asked Mikael the same thing already but could you (or 
anyone else) please provide a dumbed down specification or at least an 
overview document that references all relevant ISO-standards, RFCs and 
drafts (or chapters thereof) that one needs to read to understand modern 
IS-IS?
On top of that if you could mention what could / or should be removed 
for a trimmed down homenet version that would be a huge plus.

Cheers,

Steven

---

From: Markus Stenberg <[email-masked]>
Date: Mon, 2 Mar 2015 16:11:17 +0200

On 2.3.2015, at 15.55, Mikael Abrahamsson <[email-masked]> wrote:
> Yes, I agree that HNCP has gained security that currently none of the routing protocols have, and that this is important.
> 
> Then one can always discuss what kind of information could go into each protocol after bootstrap. Perhaps what we actually need is a new bootstrap security protocol (not only for homenet), and that this is where the emphasis should be.

Possibly. However, even if we had one, bootstrap protocol does not lead easily to widely shared PSKs, and that’s what routing protocols require.

E.g. anima bootstrap stuff is focusing only on enrolling certificates. If I had a certificate, I am not sure how it helps with PSK IS-IS scheme.

Babel + IKE + IPsec, on the other hand, could of course run with the certificate, but would not be link-state => hard to replicate state. 

Looking at fast adoption, perhaps OSPF would be preferable then, as it already runs over IP so the story would be just ’take TEH BOOTSTRAPPER, IKE, IPsec, OSPF’ and world is your oyster. No standardization required (beyond dst-src draft by Baker, just like IS-IS).

Cheers,

-Markus

---

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 02 Mar 2015 15:24:50 +0100

> I've actually been wondering about this, too.

I would dearly like to avoid having this discussion today.  I was under
the impression that we had agreed on today's deadline for the -02 version
of the routing protocol comparison, and so had assumed that only editorial
changes and discussion of existing text should happen right now.  I would
have welcomed this discussion a week earlier.

> I am not sure about the history here,

At the beginning of the discussion, I summarised my thoughts in

  https://tools.ietf.org/html/draft-chroboczek-configuration-separate-00

The rest of the discussion caused my opinions to evolve somewhat, so
please take this document with a reasonable amount of salt:

  - security was off the radar at the time;
  - Section 4 is no longer relevant (and even contains some incorrect
    claims).
  
I was chastised for publishing an opinion draft without consulting the
chairs (and perhaps rightly so), so I never got around to writing up a -01.

> it might be possible to use that already-existing routing protocol as
> the underlying communication mechanism for HNCP [...] I don't know if
> that would work with a non-link-state routing protocol,

It would be pretty trivial to implement reliable or unreliable flooding
over the Babel packet format.  I will not be doing that, however, not even
as a proof of concept, since I think that a routing protocol should avoid
doing anything that's not directly related to routing.

> HNCP contained its own (underspecified) link-state routing protocol

Markus and Steven should chime in, but my opinion is that this part of the
protocol should go.  Perfection, as somebody once said, is achieved when
there is nothing left to remove, not when there is nothing left to add.

> protocol and HNCP might be strongly desired.

I'm largely incompetent to comment on that.

-- Juliusz

---

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 02 Mar 2015 15:33:04 +0100

> I got my hands on ISO 10589 today and tried to very briefly glance through
> it. And personally I had a really hard time getting into it.
>

You need RFC 1195, RFC 3719, RFC 3787, RFC 5304, RFC 5305, and RFC 5308.

-- Juliusz

---

From: Christian Hopps <[email-masked]>
Date: Mon, 2 Mar 2015 09:56:39 -0500

> On Mar 2, 2015, at 9:07 AM, Steven Barth <[email-masked]> wrote:
> 
> 
> I got my hands on ISO 10589 today and tried to very briefly glance through it. And personally I had a really hard time getting into it.

Yes. ISO standards are not always the best place to get an overview of things. :)

The document referred to here is ISO10589:2002.

Section 6.8 is an overview IS-IS link-independent stuff. (pages 12-14)

Section 7 gets into specifics but skip anything about level 2 (definitely skip partition repair), at least to start, as we are only considering level-1 single-area operation. Feel free to skip over (or quickly glance through) any address specific stuff (7.1) as it mostly does not pertain. Also skip anything related to hosts for now (ES or end-systems, i.e., ISO hosts).

7.2 The "Decision Process" (pages 18-26)

This is basically an SPF with bi-directional checks (both sides of a link refer to each other). Additionally the fact that a broadcast network is treated as a pseudo-node with routers (non-pseudonodes) attached to it (rather than a full-mesh of connections between routers) is important.

So 7.3 is the update process (advertising and flooding of information). (pages 26-45)

Primarily this is going to get into
- How a router advertises it’s information (LSP generation)
- How IS-IS makes sure things are flooded (using sequence number packets and internally 2 flags called SRM and SSN).
- LSP expiration and collision detection.

Feel free to skip 7.4 (forwarding process), 7.5 (constants and parameters).

Section 8 is the link dependent stuff. Here the hello protocol is documented. Skip ES (end-system stuff).
- P2P (pages 50-54)
- Skip 8xxx
- Broadcast (pages 59-63)

Section 9 documents the protocol (on-the-wire) encodings (page 65-92)

Everything else can be skipped (page 92 on).

> Having read the comparison document beforehand I haven't found anything about IPv4, IPv6, HMACs, wide-metrics or other things that are mentioned in the draft (and that ISO standard was ~200 pages already).

There’s a new version that has the references to the RFCs for v4, v6, hmac and wide metrics.

The core of the IS-IS protocol is contained in about 80 pages. From above you should be able to get an good idea of the protocol in about ~40 pages, although it won’t necessarily be easy reading. :)

> So I think I asked Mikael the same thing already but could you (or anyone else) please provide a dumbed down specification or at least an overview document that references all relevant ISO-standards, RFCs and drafts (or chapters thereof) that one needs to read to understand modern IS-IS?
> On top of that if you could mention what could / or should be removed for a trimmed down homenet version that would be a huge plus.

Basically a trimmed down version is "level-1" operation only (everything in a single area). Whenever something mentioned level-2 operation discard it.

Thanks,
Chris.

---

From: Steven Barth <[email-masked]>
Date: Mon, 02 Mar 2015 16:23:33 +0100

Thanks for the quick reply. Looks like I will be having something to 
read on the plane to Dallas.

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Mon, 2 Mar 2015 19:34:54 +0000

> -----Original Message-----
> From: homenet [mailto:[email-masked]] On Behalf Of Markus
> Stenberg
> Sent: 02 March 2015 15:11
> To: Mikael Abrahamsson
> Cc: [email-masked]; Markus Stenberg; Margaret Wasserman; Christian
> Hopps
> Subject: Re: [homenet] routing protocol comparison document and hncp
> 
> Possibly. However, even if we had one, bootstrap protocol does not lead
> easily to widely shared PSKs, and that’s what routing protocols require.
> 
> E.g. anima bootstrap stuff is focusing only on enrolling certificates. If I had a
> certificate, I am not sure how it helps with PSK IS-IS scheme.

Well, draft-pritikin-anima-bootstrapping-keyinfra-01 describes a way to bootstrap a certificate infrastructure, zero touch. Once every device in a domain has a domain certificate, two devices can directly authenticate each other, without PSK. Then you can also authenticate a key negotiation scheme such as IKE, to negotiate a PSK which you can then use in your "normal" authentication scheme. Obviously, would be nice if protocol supported certs directly, but it's not required. 

I still think that the above draft is a very good way to bootstrap a certificate infrastructure, which can be leveraged in many different ways. 

Michael
 
> Babel + IKE + IPsec, on the other hand, could of course run with the
> certificate, but would not be link-state => hard to replicate state.
> 
> Looking at fast adoption, perhaps OSPF would be preferable then, as it
> already runs over IP so the story would be just ’take TEH BOOTSTRAPPER,
> IKE, IPsec, OSPF’ and world is your oyster. No standardization required
> (beyond dst-src draft by Baker, just like IS-IS).
> 
> Cheers,
> 
> -Markus
>

---

From: Michael Thomas <[email-masked]>
Date: Mon, 02 Mar 2015 11:38:43 -0800

> I still think that the above draft is a very good way to bootstrap a certificate infrastructure, which can be leveraged in many different ways.

I'm doubtful that routing protocols need PSK's. They almost certainly 
would like to share a symmetric key(s) but
is not the same thing.

Mike

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 03 Mar 2015 08:54:14 +1300

On 03/03/2015 08:38, Michael Thomas wrote:
>> Well, draft-pritikin-anima-bootstrapping-keyinfra-01 describes a way
>> to bootstrap a certificate infrastructure, zero touch. Once every
>> device in a domain has a domain certificate, two devices can directly
>> authenticate each other, without PSK. Then you can also authenticate a
>> key negotiation scheme such as IKE, to negotiate a PSK which you can
>> then use in your "normal" authentication scheme. Obviously, would be
>> nice if protocol supported certs directly, but it's not required.
>>
>> I still think that the above draft is a very good way to bootstrap a
>> certificate infrastructure, which can be leveraged in many different
>> ways.
>>
>>
> 

But they need to agree on the shared key(s) securely, and the only way
I know how to do that zero-touch is by starting with asymmetric keys
and certificates.

    Brian

---

From: Michael Thomas <[email-masked]>
Date: Mon, 02 Mar 2015 12:12:45 -0800

> I know how to do that zero-touch is by starting with asymmetric keys
s/and certificates//

Mike

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 03 Mar 2015 10:21:02 +1300

>> I know how to do that zero-touch is by starting with asymmetric keys

Well, I want certificates, because I don't believe someone who
says "Hi, I'm your friendly homenet router and here's my public
key."

   Brian

---

From: Markus Stenberg <[email-masked]>
Date: Mon, 2 Mar 2015 23:44:31 +0200

On 2.3.2015, at 21.34, Michael Behringer (mbehring) <[email-masked]> wrote:
> Well, draft-pritikin-anima-bootstrapping-keyinfra-01 describes a way to bootstrap a certificate infrastructure, zero touch. Once every device in a domain has a domain certificate, two devices can directly authenticate each other, without PSK. Then you can also authenticate a key negotiation scheme such as IKE, to negotiate a PSK which you can then use in your "normal" authentication scheme. Obviously, would be nice if protocol supported certs directly, but it’s not required. 

IKE provides just symmetric crypto key between two parties. Typical network has more (and routing protocols use multicast). Multiparty IKE is more or less dead (or undead?).

Remember, we need whole network to agree on the keys, or at least everyone on the link if any multicast is used in a way that requires authentication or confidentiality. (HNCP is designed to avoid transmitting anything important over multicast; are routing protocols? For most part, I think not.)

I might be wrong, hopefully some points me at some asymmetric crypto enabled multi-party authentication method for _some_ routing protocol.. 

Only way I could imagine this working is by firing up metric shitload of on-demand (e.g. GRE) tunnels on top of IPsec (based on some yet undefined on-link peer detection scheme), then running some RP over them in p2p mode. Then we realize that all security needed is really in the peer-detection (which can be conservative, very rate limited and so on) and the IPsec, and we would require no security features from the routing protocol itself. 

> I still think that the above draft is a very good way to bootstrap a certificate infrastructure, which can be leveraged in many different ways. 

It is relatively heavy in terms of number of protocols to the functionality I would want, but I agree that on the paper[1] it does what it advertises it does, but it is not enough to make routing protocols work in and of itself, see above. 

Cheers,

-Markus

[1] I have yet to see an implementation; I have heard one exists.

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 02 Mar 2015 19:32:25 -0500

In message <[email-masked]>
Christian Hopps writes:
 
> used as the homenet protocol. If true should we be calling this out
> more explicitly in the document?
>  
> Thanks,
> Chris.

Chris,

Yes.  I agree.

And OSPF could do the same, without dragging CLNP in with it.

Maybe ISIS-WG should consider an ISIS-over-IP draft?  Oh wait -
non-routability of CLNP is a security feature - so don't forget to
mention that in the security section.  You might need providers to use
filters at borders and GTSM as they do for OSPF.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 02 Mar 2015 19:48:24 -0500

In message <[email-masked]>
Christian Hopps writes:
> It's not just Mikael that has this opinion, he's just the more active
> email participant.
>  
> There was nothing nefarious here. I just thought of a question and
> raised it. I think we should be open to doing that any time free
> of attack.
>  
> Thanks,
> Chris.

I agree with Chris.

WGs are allowed to change their decisions particularly in early stages
when there is no significant ***deployment***.  Even then WGs can take
a new direction but need to include backward compatibility or at least
have a solid plan for (hopefully painless) transition.

For example, MPLS started with RSVP-TE and CRLDP and years later
dropped CRLDP due to lack of deployment.

CIDR obsoleted EGP, BGP1-3, RIP1, and lots of other protocols, but
there was a good reason and a clear transition plan.

The way IETF has normally done things is to allow multiple
developments to exist if they have support and then drop only those
that are not being deployed or prove to be less desirable.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 02 Mar 2015 19:59:29 -0500

In message <[email-masked]>
 
> You need RFC 1195, RFC 3719, RFC 3787, RFC 5304, RFC 5305, and RFC 5308.

Hint: RFC 1195 does a better job explaining what ISIS does than ISO
10589.  Read RFC 1195 first.

Curtis

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 3 Mar 2015 01:42:51 +0000

Hi Curtis, 
The main reason for going forward with IS-IS over OSPFv3 is that there was
an open source implementation willing to implement and support all the
enhancements necessary for Homenet. Admittedly, the source/destination
routing requirement makes the entrance barrier a bit higher for OSPFv3
than other protocols. The reason for this is that it requires the
implementation of 
http://www.ietf.org/id/draft-ietf-ospf-ospfv3-lsa-extend-06.txt in order
to support fully extendable LSAs. Hopefully, we can get some
implementation momentum for OSPFv3 Extendable LSAs this year. If not soon,
I have an idea for a cheaper, yet less elegant approach.
Thanks,
Acee

---

From: Michael Thomas <[email-masked]>
Date: Mon, 02 Mar 2015 18:05:58 -0800

> says "Hi, I'm your friendly homenet router and here's my public

so you're mollified if somebody's cert says "hi i'm 
[email-masked]" 
instead?

the possession of a cert does nothing in and of itself to make an 
enrollment decision.

Mike

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 03 Mar 2015 15:50:18 +1300

Regards
   Brian Carpenter
   http://orcid.org/0000-0001-7924-6182

On 03/03/2015 15:05, Michael Thomas wrote:
>>> I'm doubtful that routing protocols need PSK's. They almost
>>> certainly would like to share a symmetric key(s) but is not the
>>> same thing.
>>>> But they need to agree on the shared key(s) securely, and the
>>>> only way I know how to do that zero-touch is by starting with
>>>> asymmetric keys and certificates.
>>>> 
>>>> 
>>> s/and certificates//
>> Well, I want certificates, because I don't believe someone who says
>> "Hi, I'm your friendly homenet router and here's my public key."
>> 
> 

No, of course not. That is the whole point of using
draft-pritikin-anima-bootstrapping-keyinfra or an equivalent.

    Brian

---

From: Michael Thomas <[email-masked]>
Date: Mon, 02 Mar 2015 19:07:31 -0800

> draft-pritikin-anima-bootstrapping-keyinfra or an equivalent.

The point being that enrollment decisions have very little to do with 
the name binding
claimed by some third party, especially when the name binding itself in 
a zero/littleconf most
likely has little/no meaning to the enrollor (ie, 
[email-masked]).

It's hardly news that I'm biased against certs, but the biggest reason 
is that people impute
in them superpowers which only get in the way of discussing the actual 
problems.

Mike

---

From: Gert Doering <[email-masked]>
Date: Tue, 3 Mar 2015 09:33:06 +0100

Hi,

> that are not being deployed or prove to be less desirable.

"Having multiple examples of running code" is certainly a good thing.

"Discussing all potential approaches to death, unless the committee has
won, and the result is an unimplementable nightmare of myriads of different
options" is what IETF WGs have changed to in more recent years - and if
I look at the last few rounds of discussions, I can certainly understand
why Dave moved off to get something *done*.

A:
  "here's a draft that got implemented, works, and needs feedback"
  "but I want ISIS!"
  "and I want OSPF!"
  goto A

gert,
   tempted to call it a day and spend my time *deploying* IPv6 somewhere
-- 
have you enabled IPv6 on something today...?

---

From: Christian Hopps <[email-masked]>
Date: Tue, 3 Mar 2015 07:22:50 -0500

> On Mar 2, 2015, at 7:32 PM, Curtis Villamizar <[email-masked]> wrote:
> 

Using CLNP framing for IS-IS packets at the L2 layer is not the same as dragging in CLNP. No homenet router is going to do anything with ISO like frames other than drop them or hand them off to IS-IS. 

> Maybe ISIS-WG should consider an ISIS-over-IP draft?

I actually presented that draft back in 1999, it was my first presentation at IETF; it didn’t go anywhere. :)

Chris.

---

From: David Oran <[email-masked]>
Date: Tue, 3 Mar 2015 08:55:33 -0500

> On Mar 2, 2015, at 9:05 PM, Michael Thomas <[email-masked]> wrote:
> 
> so you're mollified if somebody's cert says "hi i'm [email-masked]" instead?
> 
Actually, I’m suspicious, which is entirely appropriate.

If, on the other hand, the cert says router3.orandom.net and orandom.net is my domain with delegated DNSSEC from my domain provider I might be a tad more trusting than if I just saw a 2048bit raw public key.

> the possession of a cert does nothing in and of itself to make an enrollment decision.
> 
I agree that the cert itself does nothing. The name in the cert, as long as it isn’t self signed, provides a trust anchor.

---

From: Michael Thomas <[email-masked]>
Date: Tue, 03 Mar 2015 07:31:56 -0800

> If, on the other hand, the cert says router3.orandom.net and orandom.net is my domain with delegated DNSSEC from my domain provider I might be a tad more trusting than if I just saw a 2048bit raw p…

Considering that provisioning personal certificates is the almost the 
polar opposite of zeroconf, the chances
of the normal schlub seeing an informative and/or trustworthy name are 
really, really low.

Mike

---

From: Gert Doering <[email-masked]>
Date: Tue, 3 Mar 2015 17:43:45 +0100

Hi,

> of the normal schlub seeing an informative and/or trustworthy name are 

You might want to entertain you reading 
 
  draft-behringer-homenet-trust-bootstrap

which gives a good idea how this could work (the general ideas, maybe not
the specific implementation).

Of course the normal end user is not going to ever look at or manually
generate a certificate.

Gert Doering
        -- NetMaster

---

From: Michael Thomas <[email-masked]>
Date: Tue, 03 Mar 2015 09:20:29 -0800

> Of course the normal end user is not going to ever look at or manually

I scanned this over (I think I've scanned Max's base doc too, but it's 
been a long time), and
don't think that the problem at hand has much to do with needing a CA of 
any sort. Binding
"human" names to cryptographic identities is fraught with trouble -- and 
if they're not intended
to be human consumable, they might as well be the fingerprint of a 
public key.

The big question i have is whether the non-interactive nature of certs 
is being taken advantage
of. For example, if I throw my root current CA in the trash what happens?

I have a lot of other questions, but I'm not sure whether this is right 
time to go through them.

Mike

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Tue, 3 Mar 2015 17:37:54 +0000

> From: homenet [mailto:[email-masked]] On Behalf Of Michael
> Thomas
> Sent: 03 March 2015 18:20
> To: [email-masked]
> >> polar opposite of zeroconf, the chances of the normal schlub seeing
> >> an informative and/or trustworthy name are really, really low.
> > which gives a good idea how this could work (the general ideas, maybe
> > not the specific implementation).
> >
> I scanned this over (I think I've scanned Max's base doc too, but it's been a
> long time), and don't think that the problem at hand has much to do with
> needing a CA of any sort. Binding "human" names to cryptographic
> identities is fraught with trouble -- and if they're not intended to be human
> consumable, they might as well be the fingerprint of a public key.
> 
> The big question i have is whether the non-interactive nature of certs is
> being taken advantage of. For example, if I throw my root current CA in the
> trash what happens?
> 
> I have a lot of other questions, but I'm not sure whether this is right time to
> go through them.

There are lots of questions which we should discuss. To the above question, easiest case would be that you create a new root CA and re-enrol devices there. Not perfect, but probably acceptable in a homenet, if the enrolment process is easy (which I believe we can make it). 

Should we set up an informal meeting in Dallas to discuss this? Find a slot that works for most, a quiet corner, and discuss? 

Michael

---

From: Michael Thomas <[email-masked]>
Date: Tue, 03 Mar 2015 09:51:57 -0800

> There are lots of questions which we should discuss. To the above question, easiest case would be that you create a new root CA and re-enrol devices there. Not perfect, but probably acceptable in a…

Yuck, obviously. It seems to me that there's a larger distributed 
database problem that this is probably another
for-instance of. I really want to be able to throw my current CPE in the 
trash when it dies and not spend an
entire day of harrowing configuration annotated with the dictionary's 
4-letter word section.

(others being dns naming/config, router/routing configs, dhcp goodies, 
etc, etc).

> Should we set up an informal meeting in Dallas to discuss this? Find a slot that works for most, a quiet corner, and discuss?

Alas, I will not be in Dallas. Grassy knolls give me the sneezes.

Mike

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Tue, 3 Mar 2015 18:03:45 +0000

> > Well, draft-pritikin-anima-bootstrapping-keyinfra-01 describes a way to
> bootstrap a certificate infrastructure, zero touch. Once every device in a
> domain has a domain certificate, two devices can directly authenticate each
> other, without PSK. Then you can also authenticate a key negotiation
> scheme such as IKE, to negotiate a PSK which you can then use in your
> "normal" authentication scheme. Obviously, would be nice if protocol
> supported certs directly, but it’s not required.
> 
> IKE provides just symmetric crypto key between two parties. Typical
> network has more (and routing protocols use multicast). Multiparty IKE is
> more or less dead (or undead?).
> 
> Remember, we need whole network to agree on the keys, or at least
> everyone on the link if any multicast is used in a way that requires
> authentication or confidentiality. (HNCP is designed to avoid transmitting
> anything important over multicast; are routing protocols? For most part, I
> think not.)

Sorry, I haven't been following all this discussion so I may be missing something, but ... I would say: 
Pick a master (on a link, or the entire network); master calculates a random key; distributes it to the other nodes using asymmetric crypto; all nodes use that key. For rollover use some key chain mechanism such that for a period of time old and new key are accepted. Plug those keys into the "normal" routing protocol security mechanism. 

What am I missing? 
Michael