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

[Michael Richardson <[e-mail]>]

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

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

--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-