Subject: [Anima] some comments on -- draft-ietf-anima-grasp-01

From: Michael Richardson <[email-masked]>
Date: Sun, 29 Nov 2015 16:43:44 -0500

section 2.1, part 2.

>2.1.  Requirements for Discovery
>   2.  When an ASA first starts up, it has no knowledge of the specific
>   network to which it is attached.  Therefore the discovery process
>   must be able to support any network scenario, assuming only that the
>   device concerned is bootstrapped from factory condition.

I'm thinking that there is more to this: the ASA may assume that the device,
having been bootstrapped, now has a secured ACP with the local machine.

(The exception being a bootstrap ASA, but I'm not convinced GRASP should be
used for that)

I think that we should also need to think about channel binding mechanisms so
that the ASA doesn't have to do all it's own security work, and so that an
ASA can potentially put a bit more trust into the source address of a packet.

We also need to discuss how/if an ASA that do wants to do its own security
gets access to the validated device identity. The possibility that the device
would act as a sub-CA signing each of the ASAs.  Another model would have the
device enroll each of the ASA into an ASA-type-specific CA. (Finding/creating
that ASA-specific-CA being a meta goal.)

>   8.  The discovery process must not generate excessive (multicast)
>   traffic and must take account of sleeping nodes in the case of a
>   resource-constrained network [RFC7228].

First, 7228 defines constrained devices, and challenged networks.
"resource-constrained network" isn't a thing in 7228, so that needs to be
clarified.

Second, if the ACP is implemented as I think it ought to, we won't support
any kind of native multicast.  We could provide multicast via
draft-ietf/roll-trickle-mcast, or draft-bergmann-bier-ccast perhaps, or PIM.

I don't think it's worth doing any of these things at the IP layer, I think
that there will be grasp daemons running at each vertice of the ACP, and so I
think that we should do flooding at the application layer, much like DNCP
does for Homenet.

>   25.  The protocol needs to be fully secured against forged messages
>   and man-in-the middle attacks, and secured as much as reasonably
>   possible against denial of service attacks.  It needs to be capable
>   of encryption in order to resist unwanted monitoring, although this
>   capability may not be required in all deployments.  However, it is
>   not required that the protocol itself provides these security
>   features; it may depend on an existing secure environment.

I feel like there is too much hedging.  This is where my comment that we seem
to be writing at cross-purposes come to play.   I think it would be better to
say:

        + 25.  The protocol is expected to run on top of a secure
               infrastructure provided by the Autonomic Control Plane (ACP)
               [I-D.ietf-anima-autonomic-control-plane].  The ACP is
               expected to defend against: forged messages and man-in-the
               middle attacks, as well as provide for mitigation of against
               denial of service attacks from nodes not into the ACP.  The
               ACP is further expected to provide a private channel.

I think that the words here:
  > , although this
  >   capability may not be required in all deployments.

are insufficiently supported.  Why should the protocol be complicated in this
fashion?  3.3.1 goes on to say:

>3.3.1.  Required External Security Mechanism
>
>   The protocol SHOULD run within a secure Autonomic Control Plane (ACP)
>   [I-D.ietf-anima-autonomic-control-plane].  The ACP MUST provide a
>   status indicator to inform GRASP that the ACP is operational.
>
>   If there is no ACP, the protocol MUST use another form of strong
>   authentication and SHOULD use a form of strong encryption.  TLS
>   [RFC5246] or DTLS [RFC6347] are RECOMMENDED for this purpose, based
>   on a local Public Key Infrastructure (PKI) [RFC5280] managed within
>   the autonomic network itself.

so, let's not sit on the fence here.  Can we please decide if we want an ACP,
and if we don't, then let's stop working on it.

If the designers of GRASP are thinking of using it in some other
non-Autonomic situation, then please write a new document that inherits from
draft-ietf-anima-grasp for that purpose.

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

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 30 Nov 2015 16:23:06 +1300

Hi Michael,

Thanks for reading and commenting.

> having been bootstrapped, now has a secured ACP with the local machine.

Yes, you could argue that there's a local sandbox I guess, but is that
a protocol issue?

> (The exception being a bootstrap ASA, but I'm not convinced GRASP should be

I tend to agree - we can have a *dummy* ASA for discovery purposes, but I
don't think the actual bootstrapping transaction needs to or should go
through GRASP.

> ASA can potentially put a bit more trust into the source address of a packet.

Well, GRASP effectively provides a session layer and the spec says it MUST
be secured, preferably by the ACP. I'm not clear what more you want.

> that ASA-specific-CA being a meta goal.)

Right, but given that ASA authorization is out of scope for GRASP,
what are you asking for? I agree there should be an API giving access
to the security credentials such as the ID, but shouldn't that be provided
by the security function itself, not by GRASP?

> "resource-constrained network" isn't a thing in 7228, so that needs to be

OK, wording detail, got it.

> draft-ietf/roll-trickle-mcast, or draft-bergmann-bier-ccast perhaps, or PIM.

There *will* be link-local multicast. In fact I spent most of today finding
out how to send and receive IPv6 LL multicasts in Python, and just half an
hour ago my code said:
 My goodness, I received a multicast
 b'\xf0\x00\xba\xaa' ('fe80::28cc:dc4c:9703:6781%12', 53330, 0, 12)

However, I agree that we should not ask the ACP to support multicast routing.
If there was some magic by which the ACP could secure LL multicast, that
would be wonderful, but I assume not.

> think that we should do flooding at the application layer, much like DNCP

Yes and no. Absolutely there needs to be a GRASP relay agent on every
box that has more than one interface. But do you really want to do
unicast replication if there are a hundred nodes on the link?

>                ACP is further expected to provide a private channel.

The thing is that the ACP is supposed to be a SHOULD but the external
security has to be a MUST.

Life would be simpler if the ACP was a MUST but that would be a big change.
More below.

> fashion?  

That was specifically qualifying the encryption requirement. Personally,
I wouldn't mind removing it, but that's a WG decision.

> 3.3.1 goes on to say:

Of course we want an ACP.

> draft-ietf-anima-grasp for that purpose.

That isn't that point. The point is (I thought this was made somewhere in
the draft, but maybe not) two operators might want to use some autonomic
capability across the boundary between them, and they will not want
to merge their ACPs. So that specific autonomic capability would need
to be protected separately, presumably by a conventional solution
such as TLS. So we don't want to exclude that by construction; IMHO it
has no impact on the protocol itself either way.

Regards
      Brian

---

From: Michael Richardson <[email-masked]>
Date: Mon, 30 Nov 2015 17:19:47 -0500

> Yes, you could argue that there's a local sandbox I guess, but is that

Yes, I suspect that there is something here.

There is a transitivity of trust that GRASP will have to deal with if the
ASAs do *not* have access to the private key for the device.  I think that
SIP did it right, explaining how the SIP proxies interacted, while not saying
too much about how/what they did.

    > be secured, preferably by the ACP. I'm not clear what more you want.

Channel binding may involve the two ASA cryptographically connecting the
communication they have at layer "5" with the security provided at layer 3.
It can be as simple as each end asking the layer-3 for the hash of the public
keys used to secure the channel 3, and then sending that in-protocol to establish
that there is no MITM.  It may be that GRASP will have to *explicitely* support
a trusted MITM because multi-hop GRASP messages will be necessary before
stable addresses are available.

    > by the security function itself, not by GRASP?

When we have seperated security functions from protocols, and assumed some
unspecified API, we have created unbound channels that can be attacked.
  - TCP SYN values were divorced from IP end points gave us NAPT.
  - lack of TLS ClientCertificates gives us hijacked HTTPS sessions
    (one end of not bound to the channel, the other has been trojaned by policy)
  - ...

    > would be wonderful, but I assume not.

Yes, it could be done.
We can use the enrolled certificates to bring up a multicast key manager like
rfc3830, but I'd like to know why we need it...

    > unicast replication if there are a hundred nodes on the link?

Quite possibly yes.
1) most links are not truly multicast the way 10base2 was, but are in fact
   star topologies... and:
2) the switching device at the hub of the star topology is running ANIMA,
   and it sees 48 ethernet ports, not one LAN.

    > Life would be simpler if the ACP was a MUST but that would be a big change.

Okay, good to have this conflict clearly stated.

    > has no impact on the protocol itself either way.

ah, okay.
I agree that they don't want to *merge* their ACPs.
I would claim that they want a new ACP to link their two domains, one which
is not yet another "VRF".  Let me add a diagram:
   http://www.sandelman.ca/SSW/ietf/anima/diagrams/ACP-between-two-ISPs.svg
   (also, .dia, and .png if you don't have svg in your browser)

I've drawn two ISPs, A and B. Each has a NOC and four routers. An ACP
(in purple for ISP A, in green for ISP B) connects each ISPs routers
together.

A second overlap in ORANGE is a new ACP.  I suggest it could be a double
tunnel, using ACP-A's addresses inside ISP-A to connect NOC-A directly to
router A3, which has a interconnect to ISP-B's B2.
(It could also be that ORANGE-ACP uses dataplane addresses)

The end result is that the appropriate inter-ISP ASAs that need to do things
communicate with each other.  I suspect that it isn't just A3/B2 that need to
talk, but rather and ASA on NOC-A and needs to talk to an ASA on NOC-B, but
that it may well need to know something about the Interconnection topology.

(I'm trying hard not to make this specific to DiffServ...)

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 1 Dec 2015 17:05:13 +1300

> too much about how/what they did.

I don't expect either the ASAs or GRASP to have access to the private key. Aren't
we leaving that in the hands of the ACP?

> that there is no MITM.  

OK, but for that GRASP is just a carrier. It would have to be the ACP, that
created the secure channel, that provides the hash. We still have an unused protocol
option called DeviceID - are you saying that we actually need it?

> It may be that GRASP will have to *explicitely* support

I don't see how that would work without a PKI.

> rfc3830, but I'd like to know why we need it...

I'm worrying about the unsolicited (flooding) synchronization that we bolted on.
I don't know how to secure it. My understanding is that DTLS+multicast==mess.
(Unicast replication, the next point, would fix it.)

> (I'm trying hard not to make this specific to DiffServ...)

That would be a fine use case. Yes, I agree that multiple ACPs are not excluded
by the laws of physics. Whether there's a real advantage over ad hoc TLS is
another question.

Thanks
    Brian