Subject: Re: [Anima] Adjacency table

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Mon, 2 Nov 2015 07:24:48 +0000

> -----Original Message-----
> From: Anima [mailto:[email-masked]] On Behalf Of Brian E
> Carpenter
> Sent: 29 October 2015 11:15
> To: [email-masked]
> Subject: Re: [Anima] Adjacency table
> 
> Hi Michael,
> 
> So, I'm thinking about how a GRASP implementation might use the adjacency
> table, and I have some questions and comments.
> 
> 1. What is the format and scope of the Node-ID? Is it just an arbitrary value
> that has no global meaning, or is it more than that?

It is the inbuilt h/w identifier. We have a "unique device identifier", which is a combination of device type and serial number. Now that I'm writing that, I wonder whether we can assume uniqueness across vendors... 
 
> 2. I would very much like the Interface ID to be the interface index (a small
> integer, to be found in ipi6_ifindex in the Advanced Socket API).
> There's no benefit and more work in having a name there.

Yes, of course the fields are examples. i/f index sounds ok. 

> 3. Similarly, I would very much like the IP addresses to be binary. Again,
> there's no benefit and more work in having them human-readable.

I think actually that's implementation specific (as is the interface id), and doesn't need to be specified in the document, as long as the protocols do the right thing. 

Michael
 
> Regards,
>    Brian
> 
> On 08/10/2015 04:54, Michael Behringer (mbehring) wrote:
> > ANIMA WG,
> >
> > In the latest version of the ACP draft, I was trying to be clearer on what
> triggers ACP creation. While thinking about this I came to the conclusion that
> practically all operations in ANIMA today are really focused around an
> adjacency table, which I now list in section 5.1 (precondition).
> >
> > Also in the bootstrap design team call just now, same thing: What triggers a
> bootstrap action? And again, it's really anchored around the adjacency table.
> >
> > Since this seems a pretty important concept (although quite simple, really),
> I wanted to illustrate how this all fits together in my mind:
> >
> > There are processes feeding the adjacency table; there are processes
> triggered by it. Discovery feeds the table. But there are also potential other
> input vectors. Depending on the state of the device, and what it sees in the
> table, different things happen. And there we go into the bootstrap draft, the
> ACP draft, or potentially others.
> >
> > I guess the reference model should explain this table, because it
> > really links all the documents together, in a way. v
> >
> > Does this make sense to everyone? Any things that don't seem right?
> Thoughts?
> >
> > Michael

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 3 Nov 2015 07:57:47 +1300

> It is the inbuilt h/w identifier. We have a "unique device identifier", which is a combination of device type and serial number. Now that I'm writing that, I wonder whether we can assume uniqueness…

Probably not, but presumably the security bootstrap can deliver some sort of
answer to that? Anyway, if the answer is "unique string" that is what I wanted to
know, thanks.

> I think actually that's implementation specific (as is the interface id), and doesn't need to be specified in the document, as long as the protocols do the right thing.

Well, it needs to be specified in the API for accessing the adjacency table. If we
want portability, I think it needs to be specified generally.

   Brian

---

From: Michael Richardson <[email-masked]>
Date: Tue, 03 Nov 2015 18:50:19 +0900

Brian E Carpenter <[email-masked]> wrote:
> > It is the inbuilt h/w identifier. We have a "unique device identifier",
> > which is a combination of device type and serial number. Now that I'm
> > writing that, I wonder whether we can assume uniqueness across vendors...  

> Probably not, but presumably the security bootstrap can deliver some sort
> of answer to that? Anyway, if the answer is "unique string" that is what I
> wanted to know, thanks.

Yes, the combination of <hash-of-vendor-CA-key, serialNumber> will be unique
before bootstrap.

After bootstrap, we will have <domain-CA, domain-specific-serialNumber>
in a certificate that would be installed in each device.  If you are really
lazy, you can just use the entire certificate bytes [on the order of
1Kbytes], but technically, a device might have many of those over it's
lifetime.

The serialNumber is mandated to be unique by pkix/x509.

-- 
]               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: "Michael Behringer (mbehring)" <[email-masked]>
Date: Tue, 3 Nov 2015 21:02:46 +0000

> From: Michael Richardson [mailto:[email-masked]]
> Sent: 03 November 2015 18:50
> To: Brian E Carpenter <[email-masked]>
> Cc: Michael Behringer (mbehring) <[email-masked]>; [email-masked]
> > > It is the inbuilt h/w identifier. We have a "unique device
> > > identifier", which is a combination of device type and serial
> > > number. Now that I'm writing that, I wonder whether we can assume
> uniqueness across vendors...
> 
> > Probably not, but presumably the security bootstrap can deliver some
> > sort of answer to that? Anyway, if the answer is "unique string" that
> > is what I wanted to know, thanks.
> 
> Yes, the combination of <hash-of-vendor-CA-key, serialNumber> will be
> unique before bootstrap.

Are you suggesting to use that as a device-ID? 
Strictly speaking <hash of vendor CA-key> isn't guaranteed to be unique either... 
 
> After bootstrap, we will have <domain-CA, domain-specific-serialNumber> in
> a certificate that would be installed in each device.  

I'd prefer to use the same device ID all the time, before and after bootstrap. Why change? It's just a string to identify the device...

> If you are really lazy, you
> can just use the entire certificate bytes [on the order of 1Kbytes], but
> technically, a device might have many of those over it's lifetime.

Right. 

> The serialNumber is mandated to be unique by pkix/x509.

Are you saying that the serial numbers in products ARE unique? 

Michael

---

From: Michael Richardson <[email-masked]>
Date: Wed, 04 Nov 2015 15:01:17 +0900

First, I confused myself and mis-stated something, but fundamentally
what I said was accurate.  Let me clarify first:

1) every certificate issued by any CA is supposed to have a unique
   "Serial Number" attribute.

dooku-[~] mcr 10008 %openssl x509 -in /etc/postfix/ssl/dooku.crt -noout -text
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 121 (0x79)
...
    Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=CA, ST=Ontario, L=Ottawa, O=Sandelman Software Works, OU=Debugging Department, CN=sandelman.ca/emailAddress=[email-masked]
        [yes, I need to remove SHA1 from my SOHO CA]

2) The 802.1AR specification says vendors will use a SubjectAltName to
   indicate a vendor-specific serial number.
   802.1AR is rather silent about the form of that number, but in
     draft-richardson-6tisch-idevid-cert-01 now
     draft-richardson-anima-idevid-cert-00
   I suggested that it would be an integer like SerialNumber.

Michael Behringer (mbehring) <[email-masked]> wrote:
    >> > sort of answer to that? Anyway, if the answer is "unique string"

    > Are you suggesting to use that as a device-ID?  Strictly speaking <hash
    > of vendor CA-key> isn't guaranteed to be unique either...

I never said <hash-of-vendor-CA-key> was unique.
I said that the pair <hash-of-vendor-CA-key, SerialNumber> was unique by
construction (yes, bad things can happen, but that's against the spec).
I was vague as to whether this was the SerialNumber in the certificate,
of the device-serialnumber in the SubjectAltName.  Let me clarify that it's
the latter.

    >> After bootstrap, we will have <domain-CA,
    >> domain-specific-serialNumber> in a certificate that would be installed
    >> in each device.

    > I'd prefer to use the same device ID all the time, before and after
    > bootstrap. Why change? It's just a string to identify the device...

Well, because vendorA can issue SN: 000011
and vendorB can issue SN: 00011, and we can't expect them to coordinate.
The enrollment part of the bootstrap process will provide the node with a new
(locally significant) certificate, and can provide it with whatever stable
deviceID you like.  Unless you have a model where unenrolled nodes form
prospective ACPs [that idea of mine was withdrawn after discussion], then no
nodes communicate with each other in a secure way until after they are
enrolled. 

    >> If you are really lazy, you can just use the entire certificate bytes
    >> [on the order of 1Kbytes], but technically, a device might have many
    >> of those over it's lifetime.

    > Are you saying that the serial numbers in products ARE unique?

Yes.  The <vendor,serial-number> pair is unique from the factory.