Subject: Re: [sfc] Stephen Farrell's Discuss on draft-ietf-sfc-architecture-08: (with DISCUSS and COMMENT)

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Tue, 2 Jun 2015 19:57:56 +0000

Hi, Stephen,

Let me reset the conversation, focusing specifically on the two DISCUSSes you have:

> On May 28, 2015, at 8:52 AM, Stephen Farrell <[email-masked]> wrote:
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> 
> (1) I note the charter calls for this deliverable to "provide
> a description of... security models" The charter also
> generally notes that "The SFC WG will closely consider and
> address the management and security implications when
> documenting these deliverables." My conclusion is that this
> deliverable needs to reflect the results of a security
> analysis that the wg are suppoed to have carried out but that
> it's currently too vague only saying that solutions need to
> consider this. (Essentially this is a continuation of the
> mail threads from the secdir review [1] and a satisfactory
> resolution of that will probably resolve this.)
> 
>   [1]
> https://www.ietf.org/mail-archive/web/secdir/current/msg05701.html <https://www.ietf.org/mail-archive/web/secdir/current/msg05701.html>

Regarding (1), you say:
Essentially this is a continuation of the
mail threads from the secdir review [1] and a satisfactory
resolution of that will probably resolve this"

And it seems from [2] there is a satisfactory resolution:
Thanks for all these updates; I think they go a long way to addressing the
concerns that were raised during the secdir review.
-Ben

[2] http://www.ietf.org/mail-archive/web/secdir/current/msg05740.html

> 
> (2) Metadata that contains information that is protected in
> the data plane SHOULD be equally well protected when passed
> about by SFC. I hope that's acceptable and documented. I'm
> not sure myself if "passed about" ought also include within a
> device but maybe it should really.  But at minimum, I do
> think you need to define confidentiality and origin
> authentication services for SFC metadata and/or for the SFC
> encapsulation as a whole. And I think this architecture
> document needs to say that those services have to be
> well-defined as part of any solution. (And I am not
> saying that this draft needs to define how to do those.)
> 
> 

Regarding (2), you say:
Metadata that contains information that is protected in
the data plane SHOULD be equally well protected when passed
about by SFC. I hope that's acceptable and documented.

For this we have proposed adding the following text:
Protocols addressing this architecture must include adjunct
mechanisms to provide confidentiality and integrity of metadata
carried by the protocol, although implementation of such
mechanisms may be optional.

Would all these additions address your DISCUSS?

Thanks,

— Carlos.

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 07 Jun 2015 21:15:33 +0100

Hi Carlos,

Sorry for the delayed response - some more travel ensued;-(

> [2] http://www.ietf.org/mail-archive/web/secdir/current/msg05740.html

Yes, I think the secdir review discussions seem to be reaching
or have reached closure. I'd say an updated draft could be a
good idea as I've lost track of those changes. I'm therefore
also not sure if the results there are enough to clear this
point but that'll be much easier to determine with a revision.

I don't believe that those discussions have resulted in anything
that's a recognisable "security model" though have they (as is
called for by the charter). Can you speak to how that aspect of
the WG charter is met by the changes proposed or why that isn't
needed?

> Would all these additions address your DISCUSS?

No, sorry. For one minor and two major reasons.

The first is that I want to ensure we do not end up in the
various bad situations that happened in the roll and karp
WGs, so a simple addition like that without any idea what is
likely to really happen isn't a good plan I think.

The second is that I am entirely unconvinced that any
security mechanisms can be an "adjunct" or optional to
implement.

The minor reason is that I don't think we have gotten to
the bottom of whether data integrity of data in transit
is sufficient or whether data origin authentication is
really needed here. (That could easily be something to be
addressed later in the WG but is not something to determine
now unless we do the analysis now, or describe that analysis
if it has been done but not written down so far which may
be the case.)

Cheers,
S.

PS: I'm starting on vacation on Thursday so will try to be
responsive on this in the meantime. However, we really ought
keep in mind that getting the right outcome at this stage
could save a lot of effort later, so I wouldn't be too focused
on trying to get this document done in the next few days and
I think we ought be much more focused on doing our best with
ensuring that SFC doesn't hit security speedbumps later on.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 07 Jun 2015 16:31:47 -0400

I am not sure how to usefully respond to your concern that you are not 
convinced that security mechanisms can be adjunct or optional.  That 
seems to border on opinion, rather than factual basis for a discuss. 
Further, I really do not want to end up in a situation where the 
majority of implementations are not conformant to the architecture and 
protocol spec.
And it is very clear that most of the environments at least for the 
initial, single domain, case that we are targeting will not need any 
form of authentication or data integrity in the SFC mechanism.

Also, I realized looking at your comments and the charter, that I do not 
know know what would constitute a "security model" as you understand it.

Yours,
Joel

> Sorry for the delayed response - some more travel ensued;-(
...

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 07 Jun 2015 21:34:34 +0100

> form of authentication or data integrity in the SFC mechanism.

Hmm. Doesn't BCP61 directly address the above?

> know know what would constitute a "security model" as you understand it.

Ok - what is a security model as you understand what the charter
says about this deliverable? Since you're an author and the charter
calls for that can you point me at where in the draft I find it
or why it is no longer needed/relevant/whatever?

Ta,
S.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 07 Jun 2015 16:40:23 -0400

The escurity considerations section addresses, as far as we understand 
them, the issues that a "security model" needs to cover.  It is not done 
as an explicit model.  We could recast the section as such a model, but 
it would end up saying the same things.

We could write more explicitly some of the other assumptions we make, 
for example that the services to which user packets are delivered are 
trusted by the operator to examine the packets and associated metadata. 
  We could note that the service functions are further trusted to modify 
the packet contents and metadata.
We could add text that in most single-domain cases, the underlying 
infrastructure is trusted by the operator.

Would adding text like that help?  It would seem instead to provoke the 
BCP61 comment that you are now making.

Yours,
Joel

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 07 Jun 2015 22:04:59 +0100

> it would end up saying the same things.

Well, let's see what a revised ID looks like and then haggle about
that maybe. I think that'll be easier. (I note you did not say that
the charter text on this is OBE btw.)

> infrastructure is trusted by the operator.

If your goal as authors/WG is to not have mandatory to implement
security then yes you would I think need to explicitly justify that
in a convincing manner. Isn't it perhaps telling us something if you
chose to not explicitly say things like "trusted by the operator so
no security needed" in the draft? (Seems so to me tbh.)

> BCP61 comment that you are now making.

The BCP61 comment resulted from your proposed text ("adjunct" etc) which
seems to me to run counter to that BCP. Are you arguing that such text
would be consistent with BCP61? If not, then what is your argument for
BCP61 not applying or being unwise in this case?

Cheers,
S.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 07 Jun 2015 17:38:54 -0400

This sounds like something Carlos and I can try to address in 
conjunction with the revisions.  Sorry if I was slow to understand the 
quesiton.

Yours,
Joel

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Mon, 8 Jun 2015 01:16:32 +0000

Hi Stephen,

> On Jun 7, 2015, at 4:15 PM, Stephen Farrell <[email-masked]> wrote:
> 
> 
> Hi Carlos,
> 
>>> https://www.ietf.org/mail-archive/web/secdir/current/msg05701.html <https://www.ietf.org/mail-archive/web/secdir/current/msg05701.html> <https://www.ietf.org/mail-archive/web/secdir/current/msg05701.html <https://www.ietf.org/mail-archive/web/secdir/current/msg05701.html>>
>> 
>> 
>> Regarding (1), you say:
>> [2] http://www.ietf.org/mail-archive/web/secdir/current/msg05740.html <http://www.ietf.org/mail-archive/web/secdir/current/msg05740.html>
> 

We just posted a new rev to clear Kathleen’s discuss and bring up all comments from Benoit and others.

There are good updates to the security considerations, as per secdir thread as well. You can check those diffs.

> the WG charter is met by the changes proposed or why that isn't

The “security model” is basically the analysis and details in each of the four areas called out in the Security Considerations.

I do wonder if this might make it more clear.

Additionally, see below.

OLD:
   Security considerations apply to the realization of this
   architecture, in particular to the documents that will define
   protocols.  Such realization ought to provide means to protect
   against security and privacy attacks in the areas hereby described.

   Building from the categorization of [RFC7498], we can largely divide
|  the security considerations in four areas:

NEW:
   Security considerations apply to the realization of this
   architecture, in particular to the documents that will define
   protocols.  Such realization ought to provide means to protect
   against security and privacy attacks in the areas hereby described.

   Building from the categorization of [RFC7498], we can largely divide
|  the security model in four areas, each of which is described detailing

> if it has been done but not written down so far which may

As Joel mentioned, we can work on this. Text proposal will follow.

> ensuring that SFC doesn't hit security speedbumps later on.

Let’s not make delaying (as a self-fulfilling prophecy) an objective in itself, however. I am not implying that’s what’s happening, nor that that’s what you are doing right now — but merely pointing out that kicking the can too far down the road does not ensure quality. We have the attention on this now.

I agree with you that the focus is getting to the right outcome (and text) — let’s not focus on not getting this done in the next couple days either.

Thanks,

— Carlos.

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Mon, 8 Jun 2015 01:35:24 +0000

Stephen,

Please find some concrete text, with a sufficiently detailed explanation, to anchor the discussion.

Feedback?

—>8—
6.1. SFC Data Plane Security

One of the aspects to consider as part of the SFC security model is whether to mandate the implementation of, and strongly recommend the use of authentication and encryption technology within the SFC data plane.  This architecture mandates the definition of mechanisms to provide confidentiality and integrity of metadata carried by the protocol, but makes not further recommendations. This is based on the unusual operating constraints.  Rather than being an end-to-end protocol, or even a relayed protocol with a desire to reduce the number of relays, the goal of this protocol is to deliver data packets to a series of service functions.  These functions are selected and provided by a combination of user and operator decisions. They are, in most cases, granted access to the data packet contents and the metadata.  Securing the packets from the service functions would be counter-productive.

One could argue for securing the packets as they traverse the underlying network.  Provisions for this are already included under the “Service Overlay” title in this Security Considerations. In the general case where every hop between service functions is over untrusted media, that may be necessary and appropriate. However, the initial target is for a single administrative domain, where if there are any untrustued segments they will be few and well-recognized.  Even in the general case, most transport connections will be sufficiently trusted so as not to warrant the cost of hop-wise security mechanisms over a multi-hop transport.

Given the operator focus on internal use of this tool, even demanding implementation of such mechanisms is likely to place a cost on delivery that will interfere with the use of this technology.  It should be understood that this architecture is a new model replacement for a multiplicity of widely used techniques, most of which do not even have the option of security mechanisms.

This analysis leads to an expectation of a need for optional security techniques well-integrated with the protocol so that they can be used where needed, without mandating that all implementations include such capabilities.
—>8—

Thanks,

— Carlos.

> On Jun 7, 2015, at 5:38 PM, Joel M. Halpern <[email-masked]> wrote:
> 
> This sounds like something Carlos and I can try to address in conjunction with the revisions.  Sorry if I was slow to understand the quesiton.
> 
> Yours,
> Joel
> 
> _______________________________________________
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 09 Jun 2015 00:53:34 +0100

Hi Carlos,

Thanks for that text, which I think seems to match well with what
you and Joel have been saying.

I have to say though that I don't find it at all convincing given
that we have bcp61. Having some mti security so that it can be
turned on when needed despite buying kit from multiple vendors is
what bcp61 calls for and I really don't see why sfc is an exception.

A question for you - is it useful for me to try de-construct the
text below (on the above basis) or not? It may be a waste of time
and we may be better off getting additional viewpoints on this
instead.

And in case it helps, I think the main (not the only) counter to what
you propose below is the consideration that while sfc may only be
well-defined for intradomain use now, intradomain use can in
various ways span what are now clearly important trust boundaries,
see tempora/belgacom/gemalto for examples.

Cheers,
S.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 08 Jun 2015 20:11:57 -0400

Given that we do clearly recognize that there are cases where securing 
the communication is necessary this comes down, from what you are saying 
now, to the simple question of whether we have justified the absence of 
an MTI security mechanism.

You are saying "no".  We are saying "the working group did not ask for 
it, and here the reasons we think that is defensible."

BCP61 does recognize that it does not apply to all cases.

I am very concerned that if we write an MTI security mechanism into 
this, almost no implementations will be compliant with the 
specifications.  That does not do us any good at all.

You asked for us to be explicit, and to state our reasons.  We have done 
so.  Yes, we could have a working group hum on whether we want an MTI 
security mechanism in all solutions which comply with the architecture. 
  I think we already have clarity on that issue from the WG.  And I 
doubt such a hum would change your mind if it went against you.

Yours,
Joel

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 09 Jun 2015 01:32:05 +0100

Hiya,

> an MTI security mechanism.

If the question were simple, it'd be easier I guess:-)

> it, and here the reasons we think that is defensible."

Can you show me where the WG discussed this? (In the archive.)
Seeing that discussion would help. If it has not happened, then
seeing that discussion will help.

> BCP61 does recognize that it does not apply to all cases.

I'm not sure what part(s) of bcp61 you mean, can you point me
at that/those?

> specifications.  That does not do us any good at all.

Yes. Mythical security is no security I fully agree. But Carlos'
text did not speak to unwillingness to implement, nor to any
inability to define a usable/sufficiently-useful mechanism.

> so. 

Carlos' recent text omitted some points mentioned above.

> Yes, we could have a working group hum on whether we want an MTI
>  I think we already have clarity on that issue from the WG.  And I doubt
> such a hum would change your mind if it went against you.

I am not asking for a hum. I am asking to see the (archive of
the) discussion demonstrating that clarity. Please send a URL.

Thanks,
S.

>>> One of the aspects to consider as part of the SFC security model is
>>> whether to mandate the implementation of, and strongly recommend the
>>> use of authentication and encryption technology within the SFC data
>>> plane.  This architecture mandates the definition of mechanisms to
>>> provide confidentiality and integrity of metadata carried by the
>>> protocol, but makes not further recommendations. This is based on the
>>> unusual operating constraints.  Rather than being an end-to-end
>>> protocol, or even a relayed protocol with a desire to reduce the
>>> number of relays, the goal of this protocol is to deliver data
>>> packets to a series of service functions.  These functions are
>>> selected and provided by a combination of user and operator
>>> decisions. They are, in most cases, granted access to the data packet
>>> contents and the metadata.  Securing the packets from the service
>>> functions would be counter-productive.
>>>
>>> One could argue for securing the packets as they traverse the
>>> underlying network.  Provisions for this are already included under
>>> the “Service Overlay” title in this Security Considerations. In the
>>> general case where every hop between service functions is over
>>> untrusted media, that may be necessary and appropriate. However, the
>>> initial target is for a single administrative domain, where if there
>>> are any untrustued segments they will be few and well-recognized. 
>>> Even in the general case, most transport connections will be
>>> sufficiently trusted so as not to warrant the cost of hop-wise
>>> security mechanisms over a multi-hop transport.
>>>
>>> Given the operator focus on internal use of this tool, even demanding
>>> implementation of such mechanisms is likely to place a cost on
>>> delivery that will interfere with the use of this technology.  It
>>> should be understood that this architecture is a new model
>>> replacement for a multiplicity of widely used techniques, most of
>>> which do not even have the option of security mechanisms.
>>>
>>> This analysis leads to an expectation of a need for optional security
>>> techniques well-integrated with the protocol so that they can be used
>>> where needed, without mandating that all implementations include such
>>> capabilities.
>>> —>8—
>>>
>>> Thanks,
>>>
>>> — Carlos.
>>>
>>>> conjunction with the revisions.  Sorry if I was slow to understand
>>>> the quesiton.
>>>>
>>>> Yours,
>>>> Joel
>>>>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 08 Jun 2015 20:48:25 -0400

There was no formal discussion of this topic by the working group. 
Carlos and I are reflecting what we understand from the passing 
references and the very lack of interest in the topic from the working 
group.

I really do not think, in an architecture, that it makes sense to get 
into a discussion of what we think will be implemented.  After all, 
while I can cite my expectations, we can't prove it until we get down 
the road.  I tried to focus the text on substantive technical matters. 
On the other hand, you seem to be trying to force the issue.

While section 6 of BCP61 is focused on the question of whether 
encryption is needed, it ends with the statement that cryptographic 
techniques are likely to be needed, with an implication form context of 
authentication and integrity.  But even then, it does not go so far as 
to say that cryptographic means for authentication and integrity are 
mandatory, merely likely.   So it seems very clear to me that even BCP 
61 allows for cases where such tools may not be mandatory to implement.

We are working on a control requirements document, and there I expect we 
will call for mandatory strong authentication, integrity, and encryption 
capabilities.  The threats are much clearer, the responses are 
well-defined, and the value is demonstrable.

But we are talking here about the data plane packets.  Packets being 
passed through a chain of services on their way from a source to a 
destination.

I am sure that you could phrase the question to the working group in 
such a way as to prompt extended discussion and disagreement.  I am 
equally sure that the question could be phrased in a way that would 
result in a confirmation of Carlos' and my understanding of the working 
groups intent, desire, and understanding.

Yours,
Joel

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Tue, 9 Jun 2015 01:45:32 +0000

Stephen,

To add to what Joel articulated, please find a three key points:

First, what we are taking about here is mandatory SFC encapsulation encryption. That is really one piece of the security puzzle. But the Service Overlay satisfy the security requirements of the specific SFC deployment. At the tunnel, we can turn on "authenticity and integrity checking, and/or confidentiality provisions” (the text is already there), and that would cover headers and payloads. It is not fully clear (to me) why the fixation on mandating encrypting this particular piece (more in the 3rd point).

The second point, when you say “Please send a URL”, it seems as if you are hoping to find all security discussions consolidated into a single convenient email thread. Truth is, the topic was discussed in various occasions, on the list, with off-list comments, in meetings, and in multiple threads. I expect that this is better than “a URL” frankly.

So, a couple of relevant breadcrumbs FYI: All the WG discussions are what drove the shaping of the security considerations from the initial one-sentence that it was:
"   This document does not define a new protocol and therefore creates no
    new security issues."

to today’s:
http://tools.ietf.org/rfcdiff?url2=draft-ietf-sfc-architecture-09.txt&url1=draft-merged-sfc-architecture-01.txt#diff0127 <http://tools.ietf.org/rfcdiff?url2=draft-ietf-sfc-architecture-09.txt&url1=draft-merged-sfc-architecture-01.txt#diff0127>

That did not happen in a single mega-discussion — the more meaty security discussions started at this comment http://www.ietf.org/mail-archive/web/sfc/current/msg02869.html <http://www.ietf.org/mail-archive/web/sfc/current/msg02869.html>, and we had a milestone at http://www.ietf.org/mail-archive/web/sfc/current/msg03126.html <http://www.ietf.org/mail-archive/web/sfc/current/msg03126.html>.

Then the goal was to get to Hawaii with an even strengthened section. Slide 4 at https://tools.ietf.org/agenda/91/slides/slides-91-sfc-2.pdf <https://tools.ietf.org/agenda/91/slides/slides-91-sfc-2.pdf>. And really the list archives show this discussion sprinkled throughout multiple times.

The third point, regarding BCP61. BCP61 speaks about strong security requirements for IETF “Standard Protocols”. However, this document does not define protocols.

I did mention to you already a couple of times that there is concrete clear WG interest in working on these solutions, as per https://tools.ietf.org/html/draft-reddy-sfc-nsh-encrypt-00 <https://tools.ietf.org/html/draft-reddy-sfc-nsh-encrypt-00>. You will find that draft-reddy-sfc-nsh-encrypt-00 is not a quick placeholder-draft, but energy wants to be placed here. This does not mean or imply that this architecture needs to cast MTI encryption. That question can be answered when the protocol and the encryption methods are defined.

Further, BCP61 says “ensure that IETF standard protocols have the necessary features to provide appropriate security for the application as it may be used across the Internet” — and this architecture is not defining an application that is used across the Internet.

Thanks,

— Carlos.

> On Jun 8, 2015, at 8:48 PM, Joel M. Halpern <[email-masked]> wrote:
> 
> There was no formal discussion of this topic by the working group. Carlos and I are reflecting what we understand from the passing references and the very lack of interest in the topic from the working group.
> 
> I really do not think, in an architecture, that it makes sense to get into a discussion of what we think will be implemented.  After all, while I can cite my expectations, we can't prove it until we get down the road.  I tried to focus the text on substantive technical matters. On the other hand, you seem to be trying to force the issue.
> 
> While section 6 of BCP61 is focused on the question of whether encryption is needed, it ends with the statement that cryptographic techniques are likely to be needed, with an implication form context of authentication and integrity.  But even then, it does not go so far as to say that cryptographic means for authentication and integrity are mandatory, merely likely.   So it seems very clear to me that even BCP 61 allows for cases where such tools may not be mandatory to implement.
> 
> We are working on a control requirements document, and there I expect we will call for mandatory strong authentication, integrity, and encryption capabilities.  The threats are much clearer, the responses are well-defined, and the value is demonstrable.
> 
> But we are talking here about the data plane packets.  Packets being passed through a chain of services on their way from a source to a destination.
> 
> I am sure that you could phrase the question to the working group in such a way as to prompt extended discussion and disagreement.  I am equally sure that the question could be phrased in a way that would result in a confirmation of Carlos' and my understanding of the working groups intent, desire, and understanding.
> 
> Yours,
> Joel
>

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 09 Jun 2015 12:20:33 +0100

Hi Joel,

> references and the very lack of interest in the topic from the working

I don't see how that correlates with a claim that this document meets
the chartered goals. Are you saying the charter is OBE and thus maybe
needs changing?

> into a discussion of what we think will be implemented.  

Yes, and we are not getting into *what* would be implemented, we are
arguing over whether or not the architecture says that security services
are optional to implement. (Which you prefer and I don't.)

> After all,

That is a false dichotomy.

I asked a specific question to which I have yet to see an answer:
"Where is the analysis that says that data origin authentication is
not needed and that data integrity is sufficient"?

We do seem to agree that it's necessary to define a confidentiality
service and either how to do (data-origin-authentication or
data-integrity) for at least the meta-data. And I think getting
rid of those brackets is the only substantive technical issue,
aside from the stuff about MTI.

But yes, I am trying to force the issue, but only to the point where
we do not punt on decisions because in my experience that leads to
worse outcomes in terms of DISCUSSes later.

> 61 allows for cases where such tools may not be mandatory to implement.

Honestly, I find that to be a very weird reading of bcp61. I don't
myself see any wiggle room in [1] which ends with

"
   However security must be a MUST IMPLEMENT so that end users will have
   the option of enabling it when the situation calls for it.
"

In this case the relevant end users are folks who buy/deploy SFC
things (just so's we don't get into a debate about "what's an
end-user" here:-)

  [1] https://tools.ietf.org/html/bcp61#section-7

> passed through a chain of services on their way from a source to a

I think we're talking about the overall SFC architecture here.

> groups intent, desire, and understanding.

I don't get your point there sorry.

Cheers,
S.

PS: I'll response to Carlos' mail in a while. Gotta do a thing
first.

>>> doubt

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 09 Jun 2015 13:25:46 +0100

Hi Carlos,

On 09/06/15 02:45, Carlos Pignataro (cpignata) wrote:
> First, what we are taking about here is mandatory SFC encapsulation
> encryption. 

No. What we're talking about is mandatory *to implement* security
services being called for by the SFC architecture.

We are not talking about mandating *use* of those services and it's
important to keep that front and centre in the discussion and to not
be ambiguous.

> That is really one piece of the security puzzle. But the
> Service Overlay satisfy the security requirements of the specific SFC
> deployment.

And how would one do that if your vendor has chosen to not
implement whatever security services are defined?

> At the tunnel, we can turn on "authenticity and integrity
> checking, and/or confidentiality provisions” (the text is already
> there), and that would cover headers and payloads. It is not fully
> clear (to me) why the fixation on mandating encrypting this
> particular piece (more in the 3rd point).

Same ambiguity above. That doesn't help. We're only talking
MTI here.

> 
> The second point, when you say “Please send a URL”, it seems as if
> you are hoping to find all security discussions consolidated into a
> single convenient email thread.

Yep, that'd be lovely:-) I realise life's not so simple.

> Truth is, the topic was discussed in
> various occasions, on the list, with off-list comments, in meetings,
> and in multiple threads. I expect that this is better than “a URL”
> frankly.

And I'm asking to see that. If it was all offlist or wasn't well
documented in meeting minutes that's undesirable but entirely
understandable. But in that case I'm sure you can understand why
that makes it hard for me to understand the analysis.

OTOH, Joel seemed to be saying that this had not really been
discussed (on the list/in meetings), so I'm not sure which is
the case.

> 
> So, a couple of relevant breadcrumbs FYI: All the WG discussions are
> what drove the shaping of the security considerations from the
> initial one-sentence that it was: "   This document does not define a
> new protocol and therefore creates no new security issues."

I'm entirely happy to have a problem with that one sentence;-)
The SFC architecture (and hence this document) certainly does
create new security issues.

> 
> to today’s: 
> http://tools.ietf.org/rfcdiff?url2=draft-ietf-sfc-architecture-09.txt&url1=draft-merged-sfc-architecture-01.txt#diff0127
> <http://tools.ietf.org/rfcdiff?url2=draft-ietf-sfc-architecture-09.txt&url1=draft-merged-sfc-architecture-01.txt#diff0127>
>
>  That did not happen in a single mega-discussion — the more meaty
> security discussions started at this comment
> http://www.ietf.org/mail-archive/web/sfc/current/msg02869.html
> <http://www.ietf.org/mail-archive/web/sfc/current/msg02869.html>, and
> we had a milestone at
> http://www.ietf.org/mail-archive/web/sfc/current/msg03126.html
> <http://www.ietf.org/mail-archive/web/sfc/current/msg03126.html>.
> 
> Then the goal was to get to Hawaii with an even strengthened section.
> Slide 4 at
> https://tools.ietf.org/agenda/91/slides/slides-91-sfc-2.pdf
> <https://tools.ietf.org/agenda/91/slides/slides-91-sfc-2.pdf>. And
> really the list archives show this discussion sprinkled throughout
> multiple times.

So I had a look through those, thanks for hunting them down. But
unfortunately I don't see in-depth security discussion - did I
miss it?

> 
> The third point, regarding BCP61. BCP61 speaks about strong security
> requirements for IETF “Standard Protocols”. However, this document
> does not define protocols.

Sure. For an architecture document, what I think we need to do is
to say what security services need to be defined. And, in this
case, we clearly need to follow bcp61 in saying that those need to
be MTI, (from my POV) as the authors are asking to say that those
are "adjuncts" and optional to implement. (Normally, silence on
that topic might be sufficient, but I think in this case we should
bottom out on it now since we already know there's very different
opinions.)

> 
> I did mention to you already a couple of times that there is concrete
> clear WG interest in working on these solutions, as per
> https://tools.ietf.org/html/draft-reddy-sfc-nsh-encrypt-00
> <https://tools.ietf.org/html/draft-reddy-sfc-nsh-encrypt-00>. You
> will find that draft-reddy-sfc-nsh-encrypt-00 is not a quick
> placeholder-draft, 

I've read that. It seems to call for a kerberos-like solution
(which is credible) but as of now, that draft doesn't actually
say "we're using kerberos for this" so I don't believe it
currently specifies something that could be MTI and that would
achieve interop.

But sure, that draft could be adopted and developed by the
WG to the point where it would be fine.

> but energy wants to be placed here. 

Yes, that's a concern. We need to get to something that
does the job and is good enough that folks will implement. And
it also needs to be good enough to deploy it when needed.

> This does not
> mean or imply that this architecture needs to cast MTI encryption.
> That question can be answered when the protocol and the encryption
> methods are defined.

No. Not if the architecture says security is not MTI, in
opposition to bcp61. If the architecture says that security
services for confidentiality etc. need to be defined and MTI
then yes the details can be sorted out later in the WG.

> 
> Further, BCP61 says “ensure that IETF standard protocols have the
> necessary features to provide appropriate security for the
> application as it may be used across the Internet” — and this
> architecture is not defining an application that is used across the
> Internet.

See above. I hope I've answered that.

Cheers,
S.

>> references and the very lack of interest in the topic from the
>> working group.
>> 
>> I really do not think, in an architecture, that it makes sense to
>> get into a discussion of what we think will be implemented.  After
>> all, while I can cite my expectations, we can't prove it until we
>> get down the road.  I tried to focus the text on substantive
>> technical matters. On the other hand, you seem to be trying to
>> force the issue.
>> 
>> techniques are likely to be needed, with an implication form
>> context of authentication and integrity.  But even then, it does
>> not go so far as to say that cryptographic means for authentication
>> and integrity are mandatory, merely likely.   So it seems very
>> clear to me that even BCP 61 allows for cases where such tools may
>> not be mandatory to implement.
>> 
>> We are working on a control requirements document, and there I
>> expect we will call for mandatory strong authentication, integrity,
>> and encryption capabilities.  The threats are much clearer, the
>> responses are well-defined, and the value is demonstrable.
>> 
>> But we are talking here about the data plane packets.  Packets
>> being passed through a chain of services on their way from a source
>> to a destination.
>> 
>> I am sure that you could phrase the question to the working group
>> in such a way as to prompt extended discussion and disagreement.  I
>> am equally sure that the question could be phrased in a way that
>> would result in a confirmation of Carlos' and my understanding of
>> the working groups intent, desire, and understanding.
>> 
>> Yours, Joel
>> 
>>>> Given that we do clearly recognize that there are cases where
>>>> securing the communication is necessary this comes down, from
>>>> what you are saying now, to the simple question of whether we
>>>> have justified the absence of an MTI security mechanism.
>>> 
>>>> You are saying "no".  We are saying "the working group did not
>>>> ask for it, and here the reasons we think that is defensible."
>>> 
>>> I'm not sure what part(s) of bcp61 you mean, can you point me at
>>> that/those?
>>> 
>>> 
>>>> I am very concerned that if we write an MTI security mechanism
>>>> into this, almost no implementations will be compliant with
>>>> the specifications.  That does not do us any good at all.
>>> 
>>>> You asked for us to be explicit, and to state our reasons.  We
>>>> have done so.
>>> 
>>>> Yes, we could have a working group hum on whether we want an
>>>> MTI security mechanism in all solutions which comply with the
>>>> architecture. I think we already have clarity on that issue
>>>> from the WG.  And I doubt such a hum would change your mind if
>>>> it went against you.
>>> 
>>> Thanks, S.
>>>> Yours, Joel
>>>>> Thanks for that text, which I think seems to match well with
>>>>> what you and Joel have been saying.
>>>>> 
>>>>> I have to say though that I don't find it at all convincing
>>>>> given that we have bcp61. Having some mti security so that it
>>>>> can be turned on when needed despite buying kit from multiple
>>>>> vendors is what bcp61 calls for and I really don't see why
>>>>> sfc is an exception.
>>>>> 
>>>>> A question for you - is it useful for me to try de-construct
>>>>> the text below (on the above basis) or not? It may be a waste
>>>>> of time and we may be better off getting additional
>>>>> viewpoints on this instead.
>>>>> 
>>>>> And in case it helps, I think the main (not the only) counter
>>>>> to what you propose below is the consideration that while sfc
>>>>> may only be well-defined for intradomain use now, intradomain
>>>>> use can in various ways span what are now clearly important
>>>>> trust boundaries, see tempora/belgacom/gemalto for examples.
>>>>> 
>>>>> Cheers, S.
>>>>> 
>>>>> 
>>>>>> Please find some concrete text, with a sufficiently
>>>>>> detailed explanation, to anchor the discussion.
>>>>>> 
>>>>>> Feedback?
>>>>>> 
>>>>>> —>8— 6.1. SFC Data Plane Security
>>>>>> 
>>>>>> One of the aspects to consider as part of the SFC security
>>>>>> model is whether to mandate the implementation of, and
>>>>>> strongly recommend the use of authentication and encryption
>>>>>> technology within the SFC data plane.  This architecture
>>>>>> mandates the definition of mechanisms to provide
>>>>>> confidentiality and integrity of metadata carried by the 
>>>>>> protocol, but makes not further recommendations. This is
>>>>>> based on the unusual operating constraints.  Rather than
>>>>>> being an end-to-end protocol, or even a relayed protocol
>>>>>> with a desire to reduce the number of relays, the goal of
>>>>>> this protocol is to deliver data packets to a series of
>>>>>> service functions.  These functions are selected and
>>>>>> provided by a combination of user and operator decisions.
>>>>>> They are, in most cases, granted access to the data packet 
>>>>>> contents and the metadata.  Securing the packets from the
>>>>>> service functions would be counter-productive.
>>>>>> 
>>>>>> One could argue for securing the packets as they traverse
>>>>>> the underlying network.  Provisions for this are already
>>>>>> included under the “Service Overlay” title in this Security
>>>>>> Considerations. In the general case where every hop between
>>>>>> service functions is over untrusted media, that may be
>>>>>> necessary and appropriate. However, the initial target is
>>>>>> for a single administrative domain, where if there are any
>>>>>> untrustued segments they will be few and well-recognized. 
>>>>>> Even in the general case, most transport connections will
>>>>>> be sufficiently trusted so as not to warrant the cost of
>>>>>> hop-wise security mechanisms over a multi-hop transport.
>>>>>> 
>>>>>> Given the operator focus on internal use of this tool, even
>>>>>> demanding implementation of such mechanisms is likely to
>>>>>> place a cost on delivery that will interfere with the use
>>>>>> of this technology.  It should be understood that this
>>>>>> architecture is a new model replacement for a multiplicity
>>>>>> of widely used techniques, most of which do not even have
>>>>>> the option of security mechanisms.
>>>>>> 
>>>>>> This analysis leads to an expectation of a need for
>>>>>> optional security techniques well-integrated with the
>>>>>> protocol so that they can be used where needed, without
>>>>>> mandating that all implementations include such 
>>>>>> capabilities. —>8—
>>>>>> 
>>>>>> Thanks,
>>>>>> 
>>>>>> — Carlos.
>>>>>> 
>>>>>>> This sounds like something Carlos and I can try to
>>>>>>> address in conjunction with the revisions.  Sorry if I
>>>>>>> was slow to understand the quesiton.
>>>>>>> 
>>>>>>> Yours, Joel
>>>>>>> 
>>>>>>>>> The escurity considerations section addresses, as far
>>>>>>>>> as we understand them, the issues that a "security
>>>>>>>>> model" needs to cover.  It is not done as an explicit
>>>>>>>>> model.  We could recast the section as such a model,
>>>>>>>>> but it would end up saying the same things.
>>>>>>>> 
>>>>>>>> Well, let's see what a revised ID looks like and then
>>>>>>>> haggle about that maybe. I think that'll be easier. (I
>>>>>>>> note you did not say that the charter text on this is
>>>>>>>> OBE btw.)
>>>>>>>> 
>>>>>>>>> We could write more explicitly some of the other
>>>>>>>>> assumptions we make, for example that the services to
>>>>>>>>> which user packets are delivered are trusted by the
>>>>>>>>> operator to examine the packets and associated 
>>>>>>>>> metadata. We could note that the service functions
>>>>>>>>> are further trusted to modify the packet contents and
>>>>>>>>> metadata. We could add text that in most
>>>>>>>>> single-domain cases, the underlying infrastructure is
>>>>>>>>> trusted by the operator.
>>>>>>>> 
>>>>>>>> If your goal as authors/WG is to not have mandatory to
>>>>>>>> implement security then yes you would I think need to
>>>>>>>> explicitly justify that in a convincing manner. Isn't
>>>>>>>> it perhaps telling us something if you chose to not
>>>>>>>> explicitly say things like "trusted by the operator so 
>>>>>>>>> Would adding text like that help?  It would seem
>>>>>>>>> instead to provoke the BCP61 comment that you are now
>>>>>>>>> making.
>>>>>>>> 
>>>>>>>> The BCP61 comment resulted from your proposed text
>>>>>>>> ("adjunct" etc) which seems to me to run counter to
>>>>>>>> that BCP. Are you arguing that such text would be
>>>>>>>> consistent with BCP61? If not, then what is your
>>>>>>>> argument for BCP61 not applying or being unwise in this
>>>>>>>> case?
>>>>>>>> 
>>>>>>>> Cheers, S.
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Yours, Joel
>>>>>>>>> 
>>>>>>>>>>> I am not sure how to usefully respond to your
>>>>>>>>>>> concern that you are not convinced that security
>>>>>>>>>>> mechanisms can be adjunct or optional. That seems
>>>>>>>>>>> to border on opinion, rather than factual basis
>>>>>>>>>>> for a discuss. Further, I really do not want to
>>>>>>>>>>> end up in a situation where the majority of
>>>>>>>>>>> implementations are not conformant to the 
>>>>>>>>>>> architecture and protocol spec. And it is very
>>>>>>>>>>> clear that most of the environments at least for
>>>>>>>>>>> the initial, single domain, case that we are
>>>>>>>>>>> targeting will not need any form of
>>>>>>>>>>> authentication or data integrity in the SFC
>>>>>>>>>>> mechanism.
>>>>>>>>>> 
>>>>>>>>>>> Also, I realized looking at your comments and the
>>>>>>>>>>> charter, that I do not know know what would
>>>>>>>>>>> constitute a "security model" as you understand
>>>>>>>>>>> it.
>>>>>>>>>> 
>>>>>>>>>> Ok - what is a security model as you understand
>>>>>>>>>> what the charter says about this deliverable? Since
>>>>>>>>>> you're an author and the charter calls for that can
>>>>>>>>>> you point me at where in the draft I find it or why
>>>>>>>>>> it is no longer needed/relevant/whatever?
>>>>>>>>>> 
>>>>>>>>>> Ta, S.
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> Yours, Joel
>>>>>>>>>>> 
>>>>>>>>>>>> The first is that I want to ensure we do not
>>>>>>>>>>>> end up in the various bad situations that
>>>>>>>>>>>> happened in the roll and karp WGs, so a simple
>>>>>>>>>>>> addition like that without any idea what is 
>>>>>>>>>>>> The second is that I am entirely unconvinced
>>>>>>>>>>>> that any security mechanisms can be an
>>>>>>>>>>>> "adjunct" or optional to implement.
>>>>>>>>>>>> 
>>>>>>>>>>>> The minor reason is that I don't think we have
>>>>>>>>>>>> gotten to the bottom of whether data integrity
>>>>>>>>>>>> of data in transit is sufficient or whether
>>>>>>>>>>>> data origin authentication is really needed
>>>>>>>>>>>> here. (That could easily be something to be 
>>>>>>>>>>>> addressed later in the WG but is not something
>>>>>>>>>>>> to determine now unless we do the analysis now,
>>>>>>>>>>>> or describe that analysis if it has been done
>>>>>>>>>>>> but not written down so far which may be the
>>>>>>>>>>>> case.)
>>>>>>>>>>>> 
>>>>>>>>>>>> Cheers, S.
>>>>>>>>>>>> 
>>>>>>>>>>>> PS: I'm starting on vacation on Thursday so
>>>>>>>>>>>> will try to be responsive on this in the
>>>>>>>>>>>> meantime. However, we really ought keep in mind
>>>>>>>>>>>> that getting the right outcome at this stage 
>>>>>>>>>>>> could save a lot of effort later, so I wouldn't
>>>>>>>>>>>> be too focused on trying to get this document
>>>>>>>>>>>> done in the next few days and I think we ought
>>>>>>>>>>>> be much more focused on doing our best with 
>>>>>>> _______________________________________________ sfc
>>>>>>> mailing list [email-masked]

---

From: Joel Halpern Direct <[email-masked]>
Date: Tue, 09 Jun 2015 09:28:47 -0400

I agree that the wording in section 7 of BCP 61 makes clear that the 
end-user issue does apply here.  I think that the biggest difference in 
this regard is that because there are a relatively small number of 
actual end users, and because they have the proven ability to be very 
specific about what they want, and to get it, I am much less concerned 
in this context that operators who wish to deploy secure mechanisms will 
be unable to get them.

We have tried to be clear why we consider that the problem we are tasked 
to address does not require MTI security.  At this point, I have no idea 
how to proceed with this aspect of the discussion.

Part of the problem, it seems to me, is that you have said that you are 
perfectly happy if we take our time, perform a thorough security 
analysis including at least some analysis of possible solutions, and 
then write the rest of the architecture.  Such would be needed, for 
example, to determine if data origin authentication is even tractable.

I find myself perforce raising a point that is regularly raised, and one 
which I normally side with the IESG taking its time and being thorough. 
  If we do not get this document done ASAP, we will not be able to use 
the document to inform the protocol work unless we significantly delay 
that work.  In order to achieve an interoperable data plane protocol, 
most of us need to undertake and resolve the working group discussion of 
the protocol behavior and mechanisms.  If we don't do that, the protocol 
will essentially be decided elsewhere.  Which I would consider VERY 
unfortunate.  That protocol will not have an MTI security mechanisms. 
(It won't be MTI because there will be no spec.  And many people will 
leave such mechanisms out of their implementation.)  We will likely get 
stuck with "interoperability by means of the biggest market force" (no 
insult to the folks who have that force, they have been VERY cooperative 
in the IETF work) if we do not ahve an IETF specification process to 
focus that discussion.

The net is that if we write MTI into the archtiecture specification 
right now, we won't know what it means.  We will then either ignore it 
in the protocol specification, or write something probably incorrect 
into the protocol specification, and have it ignored by most of the vendors.

I must point out that we tried writing "must include security" into the 
IPv6 specification.  Sorry, such words did not improve security 
availability at all.  A similar pretense here will likely be of similar 
value.

Yours,
Joel