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

[Brian E Carpenter <[e-mail]>]

On 01/12/2015 11:19, Michael Richardson wrote:
> 
> Brian E Carpenter <[e-mail]> wrote:
>     >>> 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.
> 
>     > Yes, you could argue that there's a local sandbox I guess, but is that
>     > a protocol issue?
> 
> 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.

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?

>     >> 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.
> 
>     > 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.
> 
> 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.  

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
> a trusted MITM because multi-hop GRASP messages will be necessary before
> stable addresses are available.

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

>     >> 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.)
> 
>     > 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?
> 
> 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)
>   - ...
> 
>     > 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.
> 
> 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...

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 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.
> 
>     > 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?
> 
> 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.
> 
>     > 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.
> 
> Okay, good to have this conflict clearly stated.
> 
>     >> 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.
> 
>     > 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.
> 
> 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...)

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