Subject: Re: [Anima] Anima domain/node ID format question

From: Brian E Carpenter <[email-masked]>
Date: Sat, 11 Apr 2015 13:15:44 +1200

Hi,

I'm extending this conversation to the list, with permission. The
assumption here is that (regardless of how the ownership and security
bootstrap dicussion ends up), the nodes in an autonomic network will be
identified by a Node ID within a domain identified by a Domain ID.

Now read on...

On 07/04/2015 18:57, Michael Behringer (mbehring) wrote:
> Hi Brian, 
> 
> [sorry yesterday was a day off here]
> 
> Inline...
> 
>> -----Original Message-----
>> From: Brian E Carpenter [mailto:[email-masked]]
>> Sent: 05 April 2015 22:35
>> To: Michael Behringer (mbehring); eckert.anima(mailer list); Liubing (Leo)
>> Subject: Anima domain/node ID format question
>>
>> Hi,
>>
>> I'm asking this question to the anima-reference-model team first, but we
>> can certainly expand the discussion to the WG if useful.
>>
>> I believe we have a concept that there will be an authenticated Domain ID
>> for each AN domain, and an authenticated Node ID for each node in a
>> domain. We're planning to remove the built-in security from GDNP, and
>> require that GDNP must either operate within the ACP, or use (D)TLS if it for
>> some reason is not running within the ACP.
>>
>> I suspect we will nevertheless want to keep a GDNP option to carry the
>> {Domain ID, Node ID} pair - but even if we don't do this, the reference
>> model will probably need to say something about them.
> 
> I think it is clear that we MUST have a single domain and node ID in an autonomic network. No, "single" is wrong. We need a "lowest common denominator". There can (and will) be several forms of ID, that doesn't matter, what matters is that there is the one that's constant and that all nodes in the domain understand. 
> 
>> So, my question: should we define a single format for Domain ID and Node
>> ID, or should they be versioned?
> 
> In our approach we're using a single format for node ID and domain ID, but a versioned form for addressing. Reason is that the node ID and domain ID are not really structured, but addressing might well need to be. So, we need some flexibility there.

I agree that the IDs may not be structured (from an external point of view)
but might there not be different families of ID?

For addressing, in GDNP we have locator options, currently of type IPv4, IPv6
and FQDN. Is that what you are thinking of, or something else?

> We're planning on writing up our approach on addressing, for discussion, but it hasn't happened yet.
>  
>> draft-pritikin does define a specific format of Domain ID. I'm not sure if any
>> current draft defines a Node ID format, except for the material we plan to
>> delete from GDNP.
> 
> This (node ID, domain ID, address model) should probably go into the reference model. Thoughts? 

Yes, I think it belongs in the reference model, but since that is likely to
end up Informational, we might need to put the format definitions, if needed,
somewhere else.

   Brian

> I suggest to take this to the list. Feel free to copy the list on your reply.
> 
> Michael
> 
>>     Brian

---

From: Michael Richardson <[email-masked]>
Date: Sat, 11 Apr 2015 17:16:39 -0400

> identified by a Node ID within a domain identified by a Domain ID.

I'm reluctant to have any kind of node-ID structure beyond something like a uuid.
I agree that it needs to be qualified by a DomainID.  I think that all other
things should be attributes of the nodeID, queryable and reportable via some
mechanism.

I think that the node-ID should be cryptographically bound into the IDevID as
Node-ID @ VENDOR-DOMAIN, and when bootstraped, it should be bound in LDevID
as Node-ID'@OPERATOR-DOMAIN.   I believe that for many, it will suffice to
set Node-ID' == Node-ID, but I don't believe this should be hard coded
anywhere in a protocol.  In particular, some operators will prefer to
maintain the Node-ID across physical replacements of a router chassis, while
other operators will prefer to always replace it.  If there is some
additional data relevant to warantees (an Asset Tag or Chassis Serial
Number), then this should be represented as an attribute.

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

---

From: Sheng Jiang <[email-masked]>
Date: Mon, 13 Apr 2015 01:06:48 +0000

>identified by a Node ID within a domain identified by a Domain ID.

Allow me to be divergent a little bit. Why single domain ID? If an autonomic node can only have one domain ID, the domain management could be rigescent. Then we have to handle something, like domain mergence, renumbering, etc. If we decouple the node from its belonging domain, it means a node could have virtual ids that belong to different domain or group. Then, maybe we do not have to have group concept?

Best regards,

Sheng

>> I think it is clear that we MUST have a single domain and node ID in an
>autonomic network. No, "single" is wrong. We need a "lowest common
>denominator". There can (and will) be several forms of ID, that doesn't matter,
>what matters is that there is the one that's constant and that all nodes in the
>domain understand.
>>
>> In our approach we're using a single format for node ID and domain ID, but
>a versioned form for addressing. Reason is that the node ID and domain ID
>are not really structured, but addressing might well need to be. So, we need
>some flexibility there.
>
>_______________________________________________
>Anima mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/anima

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 13 Apr 2015 16:41:22 +1200

> Allow me to be divergent a little bit. Why single domain ID? If an autonomic node can only have one domain ID, the domain management could be rigescent. Then we have to handle something, like domai…

Yes, I see no reason why a given node must be registered in only one domain.
We certainly should not put such a restriction in the basic protocols.

Regards
    Brian

---

From: Michael Richardson <[email-masked]>
Date: Mon, 13 Apr 2015 09:38:16 -0400

> Allow me to be divergent a little bit. Why single domain ID? If an
    > autonomic node can only have one domain ID, the domain management could
    > be rigescent. Then we have to handle something, like domain mergence,
    > renumbering, etc. If we decouple the node from its belonging domain, it
    > means a node could have virtual ids that belong to different domain or
    > group. Then, maybe we do not have to have group concept?

I think we shouldn't try to boil the ocean dry before inventing electricity.
I can buy the renumbering argument, but not really.  I think that if there is
a merge (or more accurately, an acquisition, therefore a transfer of
ownership), then I think that it is acceptable, even required, that either
the autonomic bootstrap occur again, or that the existing autonomic control
plane is used to replace the LDevID.

I think that re-initializing the autonomic control plane should never cause
anything untoward to happen to the production network, so we don't need to
worry about causing a flag day to the entire network.

--
]               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: Mon, 13 Apr 2015 15:19:08 +0000

I tend to agree with Michael here. To me, a device belongs to someone, ultimately. There can only be one ultimate owner, and ultimate source of truth. Now that doesn't prevent for example shared management, where another entity is managing a sub-part of the device (or maybe even the entire device for a period of time). But there is always one "real" owner at a time.

And I would suggest for now to keep it simple, if a device changes hands, it enrols again. 

Before embarking on a more complex story line, I'd like to understand which model we can't reasonably solve with the above assumption? 

Michael

> From: [email-masked] [mailto:[email-masked]]
> Sent: 13 April 2015 15:38
> To: Michael Behringer (mbehring); Anima WG
> Subject: Re: [Anima] Anima domain/node ID format question
> 
> 
> I can buy the renumbering argument, but not really.  I think that if there is a
> merge (or more accurately, an acquisition, therefore a transfer of
> ownership), then I think that it is acceptable, even required, that either the
> autonomic bootstrap occur again, or that the existing autonomic control
> anything untoward to happen to the production network, so we don't need
> to worry about causing a flag day to the entire network.
> 
> --

---

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Mon, 13 Apr 2015 15:34:11 +0000

On Apr 13, 2015, at 7:38 AM, Michael Richardson <[email-masked]> wrote:

> the autonomic bootstrap occur again,

All models for autonomic bootstrapping so far include the device trusting the vendor “more than” anything locally. This makes total sense when the local trust anchor is completely untrusted. But if the local trust anchor *is* known my default thinking has been that this 'overrides’ some or all aspects of the vendor trust anchor. Therefore we can’t do autonomic bootstrapping a second time without returning the device to factory default which also requires some sort of physical proof of possession. Mandating this sort of behavior protects the current owner of the device from any compromised vendor trust anchor.

The side effect is that physical possession proofs are required if the current owner loses their own trust anchors. Which do you feel is the better choice? 

> or that the existing autonomic control

I think for the normal transition model when keys are not lost or compromised this makes sense to me. Implemented either as an “autonomic bootstrapping” but where the current owner trust anchor takes the place of the vendor (thus acceptable to occur w/o physical proof of possession) or implemented as an update to the devices trust anchor using the normal key management methods. 

> worry about causing a flag day to the entire network.

In the PKI space one can extend the trust anchor chain to a “new” trust anchor in a rolling (non-flag-day) fashion using the mechanism detailed in EST RFC7030 section 4.1.3 CA Certificate Response and from CMP RFC4210 section 4.1.1. Rolling over from an old CA trust anchor to a new CA trust anchor sounds exactly like rolling over from an old owner to a new owner (to me) and would be the first place I’d look to for insight on how to deal with an acquired AN domain. This rollover could occur either at the normal transition cycle when the first keys are expiring or it could be prematurely triggered via a TBD mechanism. 

- max

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 14 Apr 2015 08:23:34 +1200

> plane is used to replace the LDevID.

Oh, I understood Sheng to be intending something quite different.
A large network (many thousands of nodes) might need some administrative
sub-structure of domains, and an autonomic device might need to be trusted
in more than one of those domains. Think about Venn diagrams of overlapping
domains.

> worry about causing a flag day to the entire network.

That's a good goal, but I don't see the connection.

    Brian

---

From: Michael Richardson <[email-masked]>
Date: Mon, 13 Apr 2015 20:06:13 -0400

> in more than one of those domains. Think about Venn diagrams of overlapping

It seems to me that if it needs to be trusted in more than one domain than
that either calls for a domain that contains everything as the trust anchor,
(so it's not overlapping that we care about, but sub-domains), or we need to
have cross-domain trust.

I don't know what it means for a device to be trusted by a domain, but I
guess, not administrated by that domain.
As long as there is a

    > That's a good goal, but I don't see the connection.

(re)numbering can mean rebooting the autonomic bootstrap process. If you can
do that without affecting what the devices are supposed to be doing, then you
can renumber or re-trust-bootstrap the nodes as often as you wish.
(In this case, I had assumed they are routers, and routing packets in a
production network is what they are supposed to be doing)

---

From: Sheng Jiang <[email-masked]>
Date: Tue, 14 Apr 2015 07:27:50 +0000

I believe we were talking about two different concepts of domain: a) domain for the device ownership, b) domains for network administrative purpose. I was jump thinking the latter while you probably focused on the former. I was thinking whether they two concepts could reuse the same domain ID. According to the discussion, it seems a single domain ID dedicated for ownership is good. Then, we may come back to something like group IDs later to fulfill the requirements of administrative domains and purpose within a same autonomic network.

Best regards,

Sheng

>From: Anima [mailto:[email-masked]] On Behalf Of Brian E
>Carpenter
>Sent: Tuesday, April 14, 2015 4:24 AM
>To: Michael Richardson; Michael Behringer; Anima WG
>to