Subject: [Anima] Common Ground on the ACP

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Mon, 22 Jun 2015 16:40:26 +0000

ANIMA, 

Trying to get a new version of the ACP draft out later this week, I'm trying to understand what we're all agreeing on, and what not. 

As I see it, the high level requirements (below) and the benefits would go into the reference model, the details into the ACP draft. 

Requirements for an ACP: 

1 - The ACP SHOULD provide robust connectivity
   As far as possible, it should be independent of configured addressing, configuration and routing. 
   (2 and 3 build on this requirement, but also have value on their own)

2 - The ACP MUST have a separate address space from the data plane.
   Reason: traceability, debug-ability, separation from data plane, security (can block at edge) 

3 - The ACP MUST use autonomically managed address space
   Reason: easy bootstrap and setup ("autonomic"); robustness (admin can't mess things up so easily).

   I think we agreed: ULA seems like a good choice for 1 and 2.

4 - The ACP MUST be generic
   Usable by all the functions and protocols of the AN infrastructure. MUST NOT be tied to a particular protocol. 

5- The ACP MUST provide security: 
   Messages coming through the ACP are authenticated to be from a trusted node, and encrypted.  

   4a - MUST: ACP Hop-by-hop authentication
   4b - SHOULD: ACP Hop-by-hop encryption

Do we agree on those requirements? 

Michael

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 23 Jun 2015 09:29:57 +1200

Hi Michael,

I pretty much agree, but

>    4b - SHOULD: ACP Hop-by-hop encryption

I suppose these are meant to be 5a/b, but more substantively, is hop-by-hop
a *requirement*? End-to-end is definitely required, but hop-by-hop seems
like an implementation choice.

My opinion is that in these days of pervasive surveillance, encryption
is a very strong SHOULD indeed.

    Brian

On 23/06/2015 04:40, Michael Behringer (mbehring) wrote:
> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima
>

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 22 Jun 2015 17:42:27 -0700

Brian: These are intertwined:

Lets just start assuming end-to-end encryption is good enough.

How do we create between ASAs security associations. We definitely would
like that not every ASA needs to build out a separate security stack.

So ultimately, this would require you to either figure out network wide
group-keys or something like up to a full-mesh of p2p keys (eg: via IKE).
That can easily lead to a big chunk of key negotiations. And when we
looked at HW keys, then #SAs is usually the limit on HW platforms. Some
platforms meant to be big VPN headens may have enough to do this, most
network devices won't.

And with just end-to-end, you still haven't eliminated injection of
DoS traffic to just overload long network paths: Because only the ultimate
receiver will be able to authenticate and reject the packets.

Thats about the point when you start to love hop-by-hop security. Which
is by the way also the argument used by 802.1ae, which is also hop-by-hop.
And which os by the way a quite attractive option to use for ACP IMHO.

So when you're back disecting hop-by-hop security, you have authentication
and encryption. To the best of my knowledge, you can have authentication
without encryption, but not the other way around. Or rather: when you
can decrypt, authentication was implied. Which is why we can't turn
MUST/SHOULD around. 

Cheers
    Toerless

-- 
---
Toerless Eckert, [email-masked]

---

From: John Strassner <[email-masked]>
Date: Mon, 22 Jun 2015 19:47:29 -0700

Hi Michael,

I agree with all of your points.

For 4, I hope we get to a point where we can treat the interface to an ACP
more like an Abstract Data Type, and then add additional requirements to
it. However, any that I can think of right now would simply strengthen the
MUST (and MUST NOT) that you have already specified here.

For 5, you have a minor typo (they should be 5a and 5b). Shouldn't there be
a 5c and a 5d, which are the E2E versions of 5a and 5b?

regards,
John

On Mon, Jun 22, 2015 at 9:40 AM, Michael Behringer (mbehring) <
[email-masked]> wrote:

> ANIMA,
>
> Trying to get a new version of the ACP draft out later this week, I'm
> trying to understand what we're all agreeing on, and what not.
>
> As I see it, the high level requirements (below) and the benefits would go
> into the reference model, the details into the ACP draft.
>
> Requirements for an ACP:
>
>    Usable by all the functions and protocols of the AN infrastructure.
> MUST NOT be tied to a particular protocol.
>

-- 
regards,
John

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 23 Jun 2015 18:13:31 +1200

> Lets just start assuming end-to-end encryption is good enough.

I was talking about requirements. The requirement is that third
parties can't read the traffic. That's an end-to-end requirement.

The solution might be hop-by-hop but that's a separate discussion,
That's all I meant to say.

(However, in general, hop-by-hop decryption and re-encryption
increases the attack surface for a bad actor. So if hop-by-hop
is simpler to implement, there is a security trade-off. But that's
a design discussion, not a requirements discussion.)

One more comment at the end...

> can decrypt, authentication was implied. Which is why we can't turn

Indeed not. But if you are seriously worried about, e.g., enemy backdoors
in your network, it will be MUST/MUST. (I've just finished reading Bruce
Schneier's book, and it certainly makes one think about this topic.)

   Brian

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Tue, 23 Jun 2015 09:43:11 +0000

Inline…

From: John Strassner [mailto:[email-masked]]
Sent: 23 June 2015 04:47
To: Michael Behringer (mbehring)
Cc: Anima WG
Subject: Re: [Anima] Common Ground on the ACP

Hi Michael,

For 4, I hope we get to a point where we can treat the interface to an ACP more like an Abstract Data Type

MB: Can you expand here? Not sure I understand what you mean.

, and then add additional requirements to it. However, any that I can think of right now would simply strengthen the MUST (and MUST NOT) that you have already specified here.

For 5, you have a minor typo (they should be 5a and 5b). Shouldn't there be a 5c and a 5d, which are the E2E versions of 5a and 5b?

MB: See previous email to Brian. I think we’ll address that in the new text.

Michael

regards,
John

On Mon, Jun 22, 2015 at 9:40 AM, Michael Behringer (mbehring) <[email-masked]<mailto:[email-masked]>> wrote:
ANIMA,

Requirements for an ACP:

Michael

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

--
regards,
John

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Tue, 23 Jun 2015 09:50:25 +0000

> -----Original Message-----
> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: 22 June 2015 23:30
> To: Michael Behringer (mbehring); Anima WG
> I suppose these are meant to be 5a/b, 

Indeed. Shuffling error. Would have benefitted of autonomic addressing :-) 

> but more substantively, is hop-by-
> hop a *requirement*? End-to-end is definitely required, but hop-by-hop
> seems like an implementation choice.

Actually, the emphasis is on the "authentication". The "hop-by-hop" I see as the default mode of operation, and there may be exceptions where you create security associations end-to-end. I'll re-phrase that to make it clearer. 
Hop by hop has the very nice property that you can leverage link-local, have therefore no dependency / conflict with configuration, thus making the communications much more robust. 

Reading this again, I just realise now that the "hop by hop" doesn't really belong to the security point. Actually, this is a sub-point to point 1 (robust connectivity): . I'll add it there. 

> My opinion is that in these days of pervasive surveillance, encryption is a
> very strong SHOULD indeed.

Completely agree. And, once you have a security association (for authentication) anyway, you may normally as well encrypt. 

Michael

> > Trying to get a new version of the ACP draft out later this week, I'm trying
> to understand what we're all agreeing on, and what not.
> >

---

From: Duzongpeng <[email-masked]>
Date: Tue, 23 Jun 2015 09:57:14 +0000

Hi, Brian and Toerless:

 In my opinion, both the hop-by-hop encryption and the end-to-end encryption are needed in the Autonomic network.

 The Hop-by-hop one can provided a uniform encryption infrastructure for all the traffic. It can simply the encryption jobs.

 The end-to-end one can provide an encryption solution for two peer nodes. 
 One of the reasons why we need this is that perhaps some information is specific for the peer node. 
 
 In detail, 
	1. Maybe the sender does not want the middle nodes to know the information due to a high security lever requirement.
	2. Or if the messages are sent across domains, the sender may be not sure about the security configuration of another domain. Another domain may choose not to encrypt their traffic.

Best Regards
Zongpeng Du

-----邮件原件-----
发件人: Anima [mailto:[email-masked]] 代表 Brian E Carpenter
发送时间: 2015年6月23日 14:14
收件人: Toerless Eckert
抄送: Anima WG; Michael Behringer (mbehring)
主题: Re: [Anima] Common Ground on the ACP

> Lets just start assuming end-to-end encryption is good enough.

I was talking about requirements. The requirement is that third parties can't read the traffic. That's an end-to-end requirement.

The solution might be hop-by-hop but that's a separate discussion, That's all I meant to say.

(However, in general, hop-by-hop decryption and re-encryption increases the attack surface for a bad actor. So if hop-by-hop is simpler to implement, there is a security trade-off. But that's a design discussion, not a requirements discussion.)

> How do we create between ASAs security associations. We definitely 
> would like that not every ASA needs to build out a separate security stack.
> 
> So ultimately, this would require you to either figure out network 
> wide group-keys or something like up to a full-mesh of p2p keys (eg: via IKE).
> looked at HW keys, then #SAs is usually the limit on HW platforms. 
> Some platforms meant to be big VPN headens may have enough to do this, 
> most network devices won't.
> 
> DoS traffic to just overload long network paths: Because only the 
> ultimate receiver will be able to authenticate and reject the packets.
> 
> Thats about the point when you start to love hop-by-hop security. 
> Which is by the way also the argument used by 802.1ae, which is also hop-by-hop.
> So when you're back disecting hop-by-hop security, you have 
> authentication and encryption. To the best of my knowledge, you can 
> have authentication without encryption, but not the other way around. 
> Or rather: when you can decrypt, authentication was implied. Which is 
> why we can't turn MUST/SHOULD around.

Indeed not. But if you are seriously worried about, e.g., enemy backdoors in your network, it will be MUST/MUST. (I've just finished reading Bruce Schneier's book, and it certainly makes one think about this topic.)

   Brian

>> I suppose these are meant to be 5a/b, but more substantively, is 
>> hop-by-hop a *requirement*? End-to-end is definitely required, but 
>> hop-by-hop seems like an implementation choice.
>>
>> My opinion is that in these days of pervasive surveillance, 
>> encryption is a very strong SHOULD indeed.
>>
>>     Brian
>>

---

From: John Strassner <[email-masked]>
Date: Thu, 25 Jun 2015 19:23:09 -0700

Hi Michael,

sorry, just noticed that I forgot to respond to this. This actually applies
to section 7.5 of the reference model, but I didn't go into Abstract Data
Types (ADTs) there in the copy I sent you, as I thought that this was too
detailed.

An ADT defines a set of classes that represent data and the operations
allowed on those data. The classes are defined to be abstract so as to
separate the specification of the data and operations from their
implementation.

Traditionally, ADTs are collections, and share a set of core operations,
such as add, remove, access, find, and retrieve. They can support helper
functions (e.g., is the collection empty, clear the collection, provide a
subset of the collection, etc.). Things like Stacks, Queues, Lists,
Dictionaries, and Graphs are good examples of ADTs.

regards,
John

On Tue, Jun 23, 2015 at 2:43 AM, Michael Behringer (mbehring) <
[email-masked]> wrote:

>  Inline…
>
>
>
> *From:* John Strassner [mailto:[email-masked]]
> *Sent:* 23 June 2015 04:47
> *To:* Michael Behringer (mbehring)
> *Cc:* Anima WG
> *Subject:* Re: [Anima] Common Ground on the ACP
>
>
>
> Hi Michael,
>
>
>
> more like an Abstract Data Type
>
>
>
> , and then add additional requirements to it. However, any that I can
> think of right now would simply strengthen the MUST (and MUST NOT) that you
> have already specified here.
>
>
>
> For 5, you have a minor typo (they should be 5a and 5b). Shouldn't there
> be a 5c and a 5d, which are the E2E versions of 5a and 5b?
>
>
>

-- 
regards,
John