Re: [Anima] I-D Action: draft-ietf-anima-grasp-13.txt - SONN

[Michael Richardson <[e-mail]>]

Toerless Eckert <[e-mail]> wrote:
    > So, in some near term future, ANI/ACP is so successfully that we
    > have four possible ACP channel protocols: IPsec, IPsec/GRE, dTLS and
    > 802.1ae

That's only three, btw.
And the answer is that you'd use IKEv2 to negotiate which one of them to use,
because IKEv2 was designed *SPECIFICALLY* to do this kind of thing.

    > a) We need a security association before we negotiate so the negotiation does
    > not become an attack vector. Solution: We build a a TLS connection

You just assumed TLS.
If you can assume TLS, I can assume IKEv2, and save a lot more code, and
pages less

And you have to assume TLS 1.3 (so you need new code and new libraries on
every device). The process will still be suspectible to trivial TCP RST
attacks.  So please add some security for that part too!


    >> 2) We have no meaningful specification for IP over *TLS thing.
    >> (but that, I mean a deployed protocol with an RFC and widespread
    >> implementation.)

    > The negotiation is just GRASP inside TLS. No IP needed.

I'm talking about the "dTLS" option above you just named.
What is it?  "IP in DTLS" isn't anywhere near enough.
Why not add OpenVPN to the list too?
At least it has widely used, extensively tested reference code, even if it
has no public specification.

Some developer in Mumbai will still have no idea what that means.
Is there an IXIA or SPIRENT module so that I can test it at 10G? or 100G?
That's a serious objection: you can't just make stuff up like that.

    >> 3) I have been trying to understand the MACsec KMP, as some would like to run
    >> the ACP over MACsec.    I originally was led to believe that there was no
    >> KMP, but after finding the full specifications, it's clear that there is
    >> support for PSK and other things and even IDevID are mentioned.
    >> I'd still like to suggest that we negotiate the use of MACsec (or of some
    >> yet-to-be-well-defined IP over TLS) via IKEv2.  It's not at all hard, and
    >> if IKEv2 is the MTI, then we need it implemented anyway.  An IKEv2 minimal
    >> implementation can be very small; lwig has some good advice, but it
    >> assumes initiator only, and we need both.
    >>
    >> I can not see a purpose for SONN, and I do not think we can do a proper
    >> security analysis, and it forces TLS to be MTI.  SONN will therefore add
    >> a significant (3-5 pages) of text on how to use TLS properly.

    > Would be great if you could point me to some example RFC where something like
    > this ("how to use TLS appropriately") is done!

I think that the Opportunistic Security specification, https://tools.ietf.org/html/rfc7435
tried to do this.  I'm not a TLS guy, so go ask one of them.

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