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

From: [email-masked]
Date: Mon, 05 Jun 2017 13:57:34 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Autonomic Networking Integrated Model and Approach of the IETF.

        Title           : A Generic Autonomic Signaling Protocol (GRASP)
        Authors         : Carsten Bormann
                          Brian Carpenter
                          Bing Liu
	Filename        : draft-ietf-anima-grasp-13.txt
	Pages           : 79
	Date            : 2017-06-05

Abstract:
   This document specifies the GeneRic Autonomic Signaling Protocol
   (GRASP), which enables autonomic nodes and autonomic service agents
   to dynamically discover peers, to synchronize state with each other,
   and to negotiate parameter settings with each other.  GRASP depends
   on an external security environment that is described elsewhere.  The
   technical objectives and parameters for specific application
   scenarios are to be described in separate documents.  Appendices
   briefly discuss requirements for the protocol and existing protocols
   with comparable features.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-anima-grasp/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-anima-grasp-13
https://datatracker.ietf.org/doc/html/draft-ietf-anima-grasp-13

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-grasp-13

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 6 Jun 2017 10:22:20 +1200

This version includes a second round of responses to IESG comments.

We may not be done yet, but please check the diffs. Here are the main changes:

   Removed all mention of TLS, including SONN, since it was under-
   specified.

   Clarified other text about trust and security model.

   Banned Rapid Mode when multicast is insecure.

   Explained use of M_INVALID to support extensibility

   Corrected details on discovery cache TTL and discovery timeout.

   Improved description of multicast UDP w.r.t.  RFC8085.

   Clarified when transport connections are opened or closed.

   Noted that IPPROTO values come from the Protocol Numbers registry

   Protocol change: Added protocol and port numbers to URI locator.

   Removed inaccurate text about routing protocols

   Moved Requirements section to an Appendix.

   Other editorial and technical clarifications.

Regards
   Brian

On 06/06/2017 08:57, [email-masked] wrote:
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>

---

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Mon, 5 Jun 2017 23:41:55 +0000

> On Jun 5, 2017, at 4:22 PM, Brian E Carpenter <[email-masked]> wrote:
> 

The -13 text maintains the “MUST be authenticated and encryption MUST be used” but now there is no normative requirement on how this is met. Correct? 

         <t>As mentioned in <xref target="highlevel"/>, some GRASP operations might be
         performed across an administrative domain boundary by mutual agreement, without the
         benefit of an ACP. Such operations
         MUST be confined to a separate instance of GRASP with its own copy of all GRASP
         data structures. Messages MUST be authenticated and encryption MUST be used.
         <!-- TLS <xref target="RFC5246"/> and DTLS <xref target="RFC6347"/> based on a Public Key Infrastructure (PKI)
         <xref target="RFC5280"/> are RECOMMENDED for this purpose.-->
         Further details may be specified in future documents.
         </t></section>

As such I’m not sure this section is providing any value anymore. Perhaps simply remove it? 
Its only saying that some future work might discover an alternative non-constained way of running GRASP. This is effectively already discussed above:

     <t>The ACP, or in its absence another security mechanism, sets the boundary within which nodes
         are trusted as GRASP peers. A GRASP implementation MUST refuse to execute GRASP
         synchronization and negotiation functions if there is neither an operational
         ACP nor another secure environment. </t>

QUESTION: The BRSKI -06 draft generically references GRASP for discovery but of course we know that this is prior to being able to establish an ACP. Therefore we must be referencing something in <section anchor="secinst" title="Constrained Instances”>. I think then that the BRSKI document should be referencing specifically <section anchor="secinst-dull" title="Discovery Unsolicited Link-Local”>. Do you agree? 

- max

> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 6 Jun 2017 11:51:06 +1200

> The -13 text maintains the “MUST be authenticated and encryption MUST be used” but now there is no normative requirement on how this is met. Correct? 

Correct, because EKR's DISCUSS was partly about the semi-specified usage with TLS.

>          ACP nor another secure environment. </t>

Well, maybe we can see whether what we've already done handles the DISCUSS? (However, I see the logic in what you say.)
 
> QUESTION: The BRSKI -06 draft generically references GRASP for discovery but of course we know that this is prior to being able to establish an ACP. Therefore we must be referencing something in <s…

Yes. I'm afraid I just haven't had time to read the latest BRSKI, but that seems correct.

Thanks
   Brian

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 6 Jun 2017 23:04:00 +0200

(slight rant about encryption, sorry, also Ccing IESG because this seems to have resulted from IESG feedback):

Which IESG feedback did raise the need to mandate encryption for GRASP in the text block you propose ?
If this does stem from IESG feedback, i would love to know any appropriate IETF security guideline
(RFC?) that defines this MUST as recommended for network signaling (such as GRASP).

IMHO: I think its bogus and an annoying proliferation of PerPass concerns into totally
different domains than end-user data. I think most network signaling works best if it is NOT encrypted
by default because it easily breaks monitoring, diagnostics, troubleshooting, analytics, optimizations. 

IMHO, networking signaling transport MUST support authentication and SHOULD enable this
by default. It MUST support enrcyption but SHOULD select the default for encryption (off/on)
based on weighting monitoring, diagnostics, troublehsooting, analytics and optimizations benefits
vs. data privacy concerns (eg: understood and documented increase in attack surface). 

Example: 

- TLS with zero-encrypt is IMHO a good default for network signaling (such as GRASP).
- ACP is a great solution to enable encryption by default because the zero-touch
  handling of domain certificates does allow to easily establish trust relationships
  for "third-party" monitoring, diagnostics, troubleshooting, analytics and optimization functions.

Thanks
    Toerless

> We may not be done yet, but please check the diffs. Here are the main changes:
[...]

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 7 Jun 2017 01:24:17 +0200

Thanks, Brian. Lot of good work.

I was surprised to see SONN go away. I do not understand what was considered to be
underspecified about it. Everything about that text was IMHO "OK". Now i was
not a big fan of the text, but if you do not want to bring it back then IMHO
we would need some other equivalent explanation.

Just as a reminder: The use-case for SONN is the ACP: 

 - you discover a candidate ACP neighbor with DULL
 - You build a TLS connection to that candidate ACP neighbor
 - You run "SONN" inside the TLS connection to negotiate the ACP protocol, eg: IPsec
   with/without GRE, or dTLS or IP over CoAP or what the heck.
 - YOu build the ACP.
 - Then you run the ACP instance of GRASP also across this new ACP leg.
   The "SONN" instance dies as soon as the ACP is up to the neighbor.

I do not think that the "SONN" instance is anything special. Thats why i do not
necessarily need to see the text reinstated. But it was nicely listing out the
implications of running a separate instance of GRASP across just a single p2p
connection. Especially the fact that you wouldn't want to flood any M_DISCOVERY
from that instance over to all the interfaces you use for the ACP instance was
IMHO well explanatory.

If i look at -13 wrt to these considerations:

 > The protocol SHOULD always run within a secure Autonomic Control
 > Plane (ACP) [I-D.ietf-anima-autonomic-control-plane].  The ACP is
 > assumed to carry all messages securely, including link-local
 > multicast when it is virtualized over the ACP.  A GRASP instance MUST
 > verify whether the ACP is operational.

"SHOULD always run within a secure ACP" is not a good sales pitch
and might confuse readers how easy it is to proliferate GRASP. In
that respect its IMHO factually not correct.

Here is how i would propose to write it resolving both the missing SONN text
and replacing that above paragraph:

GRASP is defined without authentication/encryption. Every ("normal") instance of GRASP MUST
either rely on an underlying transport that authenticates (and optionally encrypts)
messages from/to GRASP neighbors or the instance of GRASP MUST be constrained. One such
constrained instance type of GRASP is defined below - DULL.

Devices may need to be able to run more than one normal instances of GRASP, each with
a separate set of GRASP neighbors. No data structures of GRASP can be shared across
instances (including registered/cached objectives). No messages received from a
neighbor in one instance eof GRASP can be forwarded to a neighbor in another instance
of GRASP (eg: M_FLOOD messages that forwarded to all GRASP neighbors are forwarded
only to all GRASP neighbors in the same instance).

In ANI devices, the main instance of GRASP is the ACP instance. The ACP is the transport
that performs authentication and encryption of all GRASP messages for this instance.

Before the ACP can be built to a neighbor, GRASP may also be used to negotiate
how to build the ACP to that neighbor. This negotiation happens over a separate
instance of GRASP running over TLS. This is a normal, but separate (from ACP) instance
of GRASP. We call such an instance also a (normal) p2p instance, because it operates
to only one GRASP neighbor. SUch a p2p instances implementation can be simplified
because a range of functions do automatically not apply to it (forwarding of M_FLOOD
messages, redirect messages, ...).

(aka: normal p2p instance would be exactly what SONN was).

 > Network interfaces could be at different security levels, in
 > particular being part of the ACP or not.  All the interfaces
 > supported by a given GRASP instance MUST be at the same security
 > level.

I am hesitant about the term "security level" that you introduce here. I would not
know how to define that term. "Clarence, this interface has Clearance" ? ;-))

What would happen if you simply deleted the whole paragraph ? (but took my text above) ?

 > The ACP, or in its absence another security mechanism, sets the
 > boundary within which nodes are trusted as GRASP peers.  A GRASP
 > implementation MUST refuse to execute GRASP synchronization and
 > negotiation functions if there is neither an operational ACP nor
 > another secure environment.

So... IMHO, it would be great if we had some clear terminology, eg: 

  GRASP domain: a connected graph of nodes. Each node in the graph is a (normal)
     instance of GRASP running on a different (virtual) device.
  GRASP neighbors: grasp nodes to which an instance has an edge in the graph
  GRASP peers: all nodes (GRASP instances) in the graph

Instances of GRASP expect that they can unicast send/receive packets to all peers.
GRASP does not need to know the addresses of neighbors because it addresses
neighbors via link-local multicast (M_DISCOVERY and M_FLOOD).

The section 2.5.2 about constrained instances :

With my proposed text qove IMHO you would not need any additional text for the
non-ACP case.

I also do no not understand where outside of DULL you would need the consideration
of not doing Rapid Mode.

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 7 Jun 2017 12:38:42 +1200

> we would need some other equivalent explanation.

EKR didn't like the loose mention of TLS. It would be perfectly
fine to revive SONN in the ACP draft or even in a separate
ACP 'profile' draft. But I had the impression that IPSec was
the preferred model for ACP. In either case you will have exactly
the same discussion with EKR, and he's probably right ;-). In other
words you have to fully describe how cert/key management works.

I think DULL is more fundamental to GRASP and it doesn't
contain any undefined mechanism.

A reminder: assuming GRASP is approved by the IESG, it will
block at the RFC Editor until the ACP is also approved. So I
think it makes sense to focus all the security details in the
ACP draft, to minimise loops between the documents.

> (aka: normal p2p instance would be exactly what SONN was).

I think your text and the existing text intend to say the same thing.
But do you really want to go back to the IESG with a completely new
text? Can we wait and see what the DISCUSSing ADs think about the
changes so far?

> know how to define that term. "Clarence, this interface has Clearance" ? ;-))

Hmm. That text first appeared in draft-ietf-anima-grasp-08. To me it
seems self-defining, but if it doesn't seem that way to you, it should
be retouched.

There's a slight discrepancy between the way the current text uses
"instance" (a GRASP instance in a single node) and your usage
above (the set of such instances that share a security regime).
So a bit more terminology tweaking is still needed.
 
>      instance of GRASP running on a different (virtual) device.

I have always ducked this because I understood that discussing domains
and domain boundaries was future work for Anima. But logically,
that makes sense.

> With my proposed text qove IMHO you would not need any additional text for the

I'd need to read the whole thing to be sure of that.
 
> I also do no not understand where outside of DULL you would need the consideration

Can we assume secure multicast except inside the ACP?
I don't think so.

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 7 Jun 2017 22:55:33 +0200

> words you have to fully describe how cert/key management works.

Ack. see PM with Eric. I think we can have all that text in ACP.

> I think DULL is more fundamental to GRASP.

Yes.

> and it doesn't contain any undefined mechanism.

Well... i disagree (SONN didn't have this either), but not worth arguing.

> ACP draft, to minimise loops between the documents.

Well... I would love if the GRASP RFC would make it obvious that
GRASP could proliferate into as many environments as its beneficial.

To me this means that GRASP should say that it can run on any
secure transport and that ACP is just an example thereof. Maybe
specify the requirements of the secure transport. But ACP should not
need to be a normative reference.

Now i don't know if you even want to have this argument with the IESG...
Right now thhe text does tie GRAASP very tightly to the ACP.

Would IP have to be a normative reference for a new transport protocol built today ?

[lots of ignored proposed text deleted]

> text? Can we wait and see what the DISCUSSing ADs think about the

I can only make sugestions, you decide.

> and domain boundaries was future work for Anima. But logically,

I think this is today quite simple. I also think that one can not really explain
what a "secure transport is without having the term of a GRASP domain:

The secure transport needs to provide authentication (and optionally encryption)
for unicast packets between any GRASP peers in the GRASP domain.
It must prohibit traffic between any GRASP peers in the GRASP domain and
nodes outside the GRASP domain.

ACP can provide secure transport for a GRASP domain that extends across
a complete ACP because it offers these security functions.

> Can we assume secure multicast except inside the ACP?

Multicast is a red herring. The fact that we use link-local-scope multicast
is to make life easier for GRASP, but when using the ACP you would not even
need it, because you do know upfront the IPv6 link-local unicast addresses
of your GRASP peers. Instead of sending link-local multicast you could therefore
also send link-local unicast.

Consider a non-ACP solution for GRASP: You just rely on the autonomic domain
certificate. You use DULL to on all interfaces to discover your GRASP neighbors.
You set up persistent TLS connections to your GRASP neighbors. You set up
dynamic TLS connections to your (remote) GRASP peers. Aka: Same thing as when
using ACP except that you replace TCP with TLS.

Consider physcial security based secure transport (which the IETF crypto mafia would
of course argue is totally unacceptable): The physcial infrastructure is secured,
eg: Data Center internal network. Any links outside the physcial secure domain have
filters for GRASP link-local multicast. Maybe even filters for some GRASP specific
TCP port to be even more secure.  Again, you run DULL for GRASP neighbor discovery. You 
build GRASP TCP to all neighbors, you build dynamic TCP to all GRASP peers. 

Its not really rocket science.

Aka: the non-DULL "multicast is always inside whatever you define to be your
secure transport.

Cheers
    Toerless

---

From: Michael Richardson <[email-masked]>
Date: Wed, 07 Jun 2017 17:55:40 -0400

EXEC SUMM: SONN was extra plumbing with no clear benefits and significant
           downsides for the security analysis of the entire system.
           The document is fine as it is.

    > with/without GRE, or dTLS or IP over CoAP or what the heck.

1) I object to negotiating the use of which negotiation protocol to use.
   It's just asking for complicated state machines with very hard to analyze
   bid-down attacks at multiple layers.

2) We have no meaningful specification for IP over *TLS thing.
   (but that, I mean a deployed protocol with an RFC and widespread
   implementation.  We aren't here to invent protocols, but rather to
   put them together)

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.

I believe that this will confuse the market, and slow implementations
significantly (both the writing of, and the performance of).

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

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 8 Jun 2017 00:56:24 +0200

Thanks, Michael - inline.

>    bid-down attacks at multiple layers.

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

Question: How would you negotiate between two ANI peers which protocol to use ?
Lets say that the negotiation was also somewhat complex in so far that devices
may have two levels of performance support for a particular protocol

"i suck, but i do it to be compatible (software)"
"i do it with hardware acceleration"

So the negotiation would have to be done in a way that both sides will agree
on the protocol they both support und suck the least with.

The answer that the current ACP spec has to do this is incomplete but AFAIK
still the most simple one:

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
b) We need a negotiation protocol. Well. GRASP proposes we use it for this
   purpose. So we just run GRASP (no IP etc.) inside the TLS.
   Its incomplee because we have not defined the exact name of objective/
   parameters for this type of negotiation though.

ACP spec also specifies how to select a protocol without this degree of
negotiatio, which is that you start the subset of all the possible protocols
that you support, and once you have working connections you use a simple decider to
select which of the two peers takes the master role and closes the unneeded
connections. Thats the only solution to avoid the additional layer of
negotiation, but it is of course limited, because it will not allow to
negotiate any parameter not known via the existing (negotiation) protocols.
Such as the aforementioned performance of any of the possible protocols.
Aka: Without the GRASP/TLS negotiation i could not figure out that
in one case both sides have best performance via eg: 802.1ae.

>    implementation.)

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

>    (We aren't here to invent protocols, but rather to put them together)

See above, i think it's not relevant to this discus.

> 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 have sent a question to the same end to the SEC ADs.

Its fine with me not to have SONN defined in the GRASP document even though
i did like the text. Instead i would have to add more text to the ACP spec
explaining how to use GRASP across TLS to achieve above described negotiation.
And as you said: finding the minimum necessary definition of a TLS profile
would then be up to me.

If we make progress with the rest of ACP faster than with this piece, then
i will yank that section of GRASP negotiated ACP channel selection from ACP
draft and we can put it into a separate document.

> significantly (both the writing of, and the performance of).

Sure. Hope the above strategy of pushing this up in the doc stack
(GRASP -> ACP -> separate document) as needed makes sense.

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 8 Jun 2017 14:21:31 +1200

Mainly agreed, but see in line..
> also send link-local unicast.

Well yes, but for discovery & flooding you actually need to emulate
multicast. GRASP assumes that the ACP VRF will do that. If not, GRASP
would have to access the adjacency table and send N copies. I could
code that, but I don't think I should need to.

> using ACP except that you replace TCP with TLS.

Well yes. Wouldn't you rather sub-contract all that to the ACP? I would.

> Its not really rocket science.

Well, it's just an ACP by another name. We aren't disagreeing. However,
relying on physical integrity of the network might work for an enterprise
IT manager, but that is a bit out of the IETF's scope.

Yes.
    
   Brian

---

From: Michael Richardson <[email-masked]>
Date: Wed, 07 Jun 2017 22:36:09 -0400

> have four possible ACP channel protocols: IPsec, IPsec/GRE, dTLS and

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.

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

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

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

---

From: Michael Richardson <[email-masked]>
Date: Thu, 08 Jun 2017 11:59:31 -0400

> code that, but I don't think I should need to.

GRASP is doing application layer multicast.  That's why we have those
session-IDs, and the checking and the caching, etc.

It's news to me that the ACP will emulate layer-2 multicast!

I expected GRASP to send a copy on each interface (you do that now!), and the
ACP will present each link in the VRF as an interface.

If you want multicast support in the ACP, would you like:
   1) PIM? (dense or sparse)
   2) MPL?
   3) something totally bleeding edge (but very cool) like BIER?

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 8 Jun 2017 20:25:23 +0200

Thanks, Michael:

Any examples of how IKEv2 is used to negotiate other non-IPsec protocols ?

[ I have not found examples describing the use of IKE(v2) for dissimilar
  crypto associations outside of IPsec, except for maybe RFC4595. If i
  wanted for example to negotiate between 802.1ae or IPsec, i wonder what
  amount of trouble/work that would be to define that as an IKEv2 extension
  vs. defining this just as a GRASP negotiation in TLS. ]

Yes, we just made up TLS, and yes, if we can't come to a conclusion that
IKEv2 is not the most feasible approach (see above for my concerns),
TLS may potentially also not be the most widely accepted transport given the
constrained IoT worlds preference to use CoAP/dTLS if i am not mistaken.

In any case this discussion seems to point to need to take the more intelligent
negotiation out of the ACP document into a separate draft where we can continue to
ponder and decide on the best option. Right ?

Eg: Maybe a "lightweight heterogenous security association negotiation mechanism"
would have to be GRASP/CoAP/dTLS. and the negotiation functions should
defintely be able to argue how they did inherit or differ from IKEv2.

In the end this may simple be a more strategic modularization direction,
to reuse evolving building blocks eg: IKEv2 was built as a silo when there
where no widely adopted initial security association protocols like TLS/dTLS.
And the message formats used in IKEv2 where predating evolving industry
preferences over a reuse of request/response exchange standards such as those
of HTTP/CoAP/(hopefully GRASP) or encoding rules such as those of XML or JSON/CBOR.

If using IKEv2 to negotiate into eg: 802.1ae would be easier and make
adoption easier, i'd be all for it. Past experience just makes me think this
to be less likely.

Wrt to IP in dTLS:

This would of course only be a candidate ACP channel. For negotiation we would not
need IP, it would just be GRASP/(d)TLS or GRASP/CoAP/dTLS.

We had the argument in Chigaco or before whether it would be necessary to have a
1 paragraph separate document to state that IP packets can be carried in dTLS,
and i thought we did in the meeting come to the conclusion that that was not
necessary. But that may have been premature. I was looking at:
draft-mavrogiannopoulos-openconnect-00. That certainly is mostly complexity
because it combines TLS for connection negotiation and dTLS for the data.
Gee, i wonder why they didn't use IKEv2 ;-))

Nevertheless: Would be interesting to find the most simple RFC example of
an application protocol that just uses dTLS to have an example of what dTLS
parameters one would need to specify.

(i assume OpenVPN is just an implementation of openconnect mechanism, right ?,
i have not used it myself but just linux openconnect and Cisco Anyconnect)

Btw: Eric recommended to take a look at https://tools.ietf.org/html/draft-ietf-dprive-dtls-and-tls-profiles-09 as a recent example how to specify security profiles for (d)TLS.

Cheers
    toerless

---

From: William Atwood <[email-masked]>
Date: Thu, 8 Jun 2017 16:03:32 -0400

Toerless,

The idea to extend IKEv2 for "wider scope" negotiation can certainly be
seen in the KARP documents.  In this case:
1) for unicast negotiation, the protocols being keyed include IPsec and
TCP-AO
2) for multicast negotiation, the base model was GDOI (adapted to
IKEv2), but an election procedure was added

The addition is because GDOI's administratively-assigned group
controller/key server was not suitable for a negotiation whose scope was
a single network segment.  KARP needed something that would work on its
own.  Sounds as if "autonomic" would be a good descriptor for this case...

Unfortunately, these two documents never made it past the "draft-author"
stage.  However, they were well-enough defined that I have a student who
has formally validated some of their security properties.

documents (all four that I believe are pertinent):
	draft-mahesh-karp-rkmp
 	draft-hartman-karp-mrkmp
	draft-yeung-g-ikev2
	draft-chunduri-karp-using-ikev2-with-tcp-ao

  Bill

-- 

Dr. J.W. Atwood, Eng.             tel:   +1 (514) 848-2424 x3046
Distinguished Professor Emeritus  fax:   +1 (514) 848-2830
Department of Computer Science
   and Software Engineering
Concordia University EV 3.185     email:[email-masked]
1455 de Maisonneuve Blvd. West    http://users.encs.concordia.ca/~bill
Montreal, Quebec Canada H3G 1M8

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 9 Jun 2017 09:10:09 +1200

> session-IDs, and the checking and the caching, etc.

Wel, I think the session IDs are equally relevant for unicast, especially
if we do develop a UDP-unicast model later. But the model described
in GRASP relies explicitly on link-local IP multicast, that's why we
have a LL multicast address assigned. We do not rely on multicast routing,
because that makes us dependent on the data plane. But we do rely
on discovery and flood being sent to all neighbours. How else can they
work?

So this is why I've been asking the ACP authors to be precise about the
service they will offer to GRASP, over many months. They tell me it
will be a VRF instance providing a reasonably small number of (virtual)
interfaces to GRASP. GRASP will send LL multicasts to each of those
interfaces, and the VRF instance has to do the right thing, i.e. replicate
those multicasts as needed. But that's layer 3, it just has LL scope.

Nothing new here that I can see.

    Brian

---

From: Michael Richardson <[email-masked]>
Date: Fri, 09 Jun 2017 10:48:16 -0400

> Nothing new here that I can see.

Since all the links will be PPP links, there will be no "replication".

---

From: Uma Chunduri <[email-masked]>
Date: Fri, 9 Jun 2017 17:58:33 +0000

Agree with Bill below.

As a co-author of the  pair-wise key drafts https://www.ietf.org/archive/id/draft-chunduri-karp-using-ikev2-with-tcp-ao-06.txt & https://tools.ietf.org/html/draft-mahesh-karp-rkmp-05  or 
adaptation of IKEv2 for TCP-AO, I can say there was lot of effort done in KARP for this. 

However, eventually KARP WG  decided routing protocols don't need automated key exchange protocol for both pair-wise or for group-keying (out of KARP charter)  and the effort was  not progressed.

I am not fully clear on the exact requirements current context (*) but can answer any specific questions around usage of IKEv2 other than IPSec.

--
Uma C.
* I don't closely follow all Anima WG posts, Sorry!

-----Original Message-----
From: Anima [mailto:[email-masked]] On Behalf Of William Atwood
Sent: Thursday, June 08, 2017 1:04 PM
To: [email-masked]; Toerless Eckert <[email-masked]>; Michael Richardson <[email-masked]>
Subject: Re: [Anima] I-D Action: draft-ietf-anima-grasp-13.txt - SONN

Toerless,

The idea to extend IKEv2 for "wider scope" negotiation can certainly be seen in the KARP documents.  In this case:
1) for unicast negotiation, the protocols being keyed include IPsec and TCP-AO
2) for multicast negotiation, the base model was GDOI (adapted to IKEv2), but an election procedure was added

The addition is because GDOI's administratively-assigned group controller/key server was not suitable for a negotiation whose scope was a single network segment.  KARP needed something that would work on its own.  Sounds as if "autonomic" would be a good descriptor for this case...

Unfortunately, these two documents never made it past the "draft-author"
stage.  However, they were well-enough defined that I have a student who has formally validated some of their security properties.

  Bill

On 08/06/2017 2:25 PM, Toerless Eckert wrote:
> TLS may potentially also not be the most widely accepted transport 
> given the constrained IoT worlds preference to use CoAP/dTLS if i am not mistaken.
> 
> In any case this discussion seems to point to need to take the more 
> intelligent negotiation out of the ACP document into a separate draft 
> where we can continue to ponder and decide on the best option. Right ?
> 
> In the end this may simple be a more strategic modularization 
> direction, to reuse evolving building blocks eg: IKEv2 was built as a 
> silo when there where no widely adopted initial security association protocols like TLS/dTLS.
> And the message formats used in IKEv2 where predating evolving 
> industry preferences over a reuse of request/response exchange 
> standards such as those of HTTP/CoAP/(hopefully GRASP) or encoding rules such as those of XML or JSON/CBOR.
> 
> adoption easier, i'd be all for it. Past experience just makes me 
> think this to be less likely.
> 
> Wrt to IP in dTLS:
> 
> This would of course only be a candidate ACP channel. For negotiation 
> we would not need IP, it would just be GRASP/(d)TLS or GRASP/CoAP/dTLS.
> 
> 1 paragraph separate document to state that IP packets can be carried 
> in dTLS, and i thought we did in the meeting come to the conclusion 
> that that was not necessary. But that may have been premature. I was looking at:
> draft-mavrogiannopoulos-openconnect-00. That certainly is mostly 
> complexity because it combines TLS for connection negotiation and dTLS for the data.
> Nevertheless: Would be interesting to find the most simple RFC example 
> of an application protocol that just uses dTLS to have an example of 
> what dTLS parameters one would need to specify.
> 
> (i assume OpenVPN is just an implementation of openconnect mechanism, 
> right ?, i have not used it myself but just linux openconnect and 
> Cisco Anyconnect)
> 
>> 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.
>>
>> 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!
>>
>>
>> At least it has widely used, extensively tested reference code, even 
>> if it has no public specification.
>>

--

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 10 Jun 2017 08:43:09 +1200

> Since all the links will be PPP links, there will be no "replication".

I think that's our choice to make. Please see:

https://mailarchive.ietf.org/arch/msg/anima/-vOvFVQr6zcognXJxwKKB9_t5-Q

GRASP discovery and flood, by their nature, must be received by all
GRASP neighbours. How it happens isn't actually very important - if
there was such a thing as secure link-local multicast, we'd use it.
But if not, *somebody* is going to replicate the packets. If the VRF
doesn't do it, GRASP itself will have to do it. That doesn't seem optimal
to me.

I would like the ACP VRF to emulate link-local multicast to all nodes
listed in the adjacency table as neighbours on the same physical interface.
If it doesn't, then GRASP will.

IMHO we need a precise statement of the service the ACP will provide
at the API it presents to GRASP. That can't be left as an implementation
detail.

    Brian

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 9 Jun 2017 23:15:48 +0200

> doesn't do it, GRASP itself will have to do it. That doesn't seem optimal

I wonder why you are saying this.

Generally, where information needs to be disseminated to a group, there is an end-to-end argument giving the application a big role in that.  Supporting this directly in the network can only really be motivated by performance considerations(*); do you think this function here is performance-critical?

Grüße, Carsten

(*) or where the topology defines the group, but I don’t think this is the case here.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 10 Jun 2017 11:33:32 +1200

> Generally, where information needs to be disseminated to a group, there is an end-to-end argument giving the application a big role in that.  Supporting this directly in the network can only really…

Well, we are talking about encryption here, so there is a run-time cost
that we can never optimise if it's an upper layer that replicates the
packets. However, my main concern is that the GRASP code will have to
track each neighbour relationship as a distinct virtual interface with
its own interface index, and in particular the discovery relaying code
will have to track each one separately. That is stateful, because
discovery responses have to be matched to the discovery request.
And it goes like N(neighbours).

If the VRF simply emulates multicast sending, that is a trvial
stateless process, and the GRASP state goes like N(interfaces).

Either will work, but as far as I can see having the VRF handle
LL multicast is much, much simpler. To be clear, it doesn't have
to do any multicast routing; that's why GRASP does its own
relaying. The VRF has to do something like

if message.destination_address == ALL_GRASP_NEIGHBORS_6:
    for i in neighbors:
        secure_send(message, i)

and then it can forget about it, because it's UDP.

   Brian

---

From: Michael Richardson <[email-masked]>
Date: Sat, 10 Jun 2017 11:20:07 -0400

> stateless process, and the GRASP state goes like N(interfaces).

Again, the ACP VRF is a set of PPP links over IPsec tunnels.
It will show up as interfaces with seperate ifindex.
(Replacing IPsec with another IP-level security mechanism won't change this)

A long time ago, I asked carefully if it was intended that GRASP to be
providing application layer multicast (vs supporting multicast across the ACP
via PIM or MPL), and the response I got was that GRASP would do it.

And GRASP do it the right thing now, so I'm really lost as to what the
concern is.

Putting on my ISP architect hat:

In a realistic ISP situations, the occurances of having more than
one or two ACP peers on a single physical link is pretty rare.
The exception would be at access networks that look like ethernet. (Cable,
FTTH, GPONs).

xDSL networks tend to use PPPoE, so have a seperate interface per CPE device.
b2b ISPs that use GPON tend to split off the customer traffic into seperate
VLANs, although both they and Cable networks usually put the GPON
terminals/Cable_modem management into a VLAN seperate from the customer
traffic.   At this point, these networks are using TR-069 for management
with a transition from SOAP to NETCONF apparently on the way.

So for initial deployment of ACP, I expect not to see more than 3-4 devices
per link.  The interface between the access devices and the core devices may
initially have a higher fan-out, until one looks at the actual wires, and
realizes that the layer-2 switching hardware in between ought to be involved
in the ACP, and then the ACP devolves to point to point ethernet cables.

Whether Metro-Ethernet rings will be presented to the ACP as a single link
with many nodes (ignoring all the layer-2 topology), or whether the layer-2
topology will be revealed will, I think be a question of evolution.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 12 Jun 2017 11:43:07 +1200

> (Replacing IPsec with another IP-level security mechanism won't change this)

Yes, I understand that, which is why I was asking about the number of
interfaces that a GRASP instance will see in the earlier thread that
I referenced. I still need to see an API for the adjacency table to
be certain, but I believe I understand how GRASP will use those
interfaces.

> via PIM or MPL), and the response I got was that GRASP would do it.

Right, there is absolutely no need for a multicast routing protocol. 

> And GRASP do it the right thing now, so I'm really lost as to what the

Efficiency, basically. Reading on...

> per link.  

OK, let's work with that. If a node has 4 interfaces and 4 GRASP neighbours
per interface, your model will have the GRASP core replicating each discovery
and flood message 16 times, because it will see 16 ACP interfaces. So there
will be 16 separately encrypted messages. That's not a disaster. But for
discovery, there will also be 16 potential responses, all of which
have to be waited for and collected up. It will work (although I wouldn't
recommend coding it the way I coded the prototype, because it would also
generate 16 threads). It just doesn't feel optimal.

Anyway my real request, before I feel ready for an ACP WGLC, is to see
at least notionally what the ACP's API will look like, including the
API for the adjacency table.

Thanks
    Brian

> The interface between the access devices and the core devices may