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

[Stephen Farrell <[e-mail]>]

Hi Carlos,

On 09/06/15 02:45, Carlos Pignataro (cpignata) wrote:
> 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. 

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.


> 
> Thanks,
> 
> — Carlos.
> 
>> On Jun 8, 2015, at 8:48 PM, Joel M. Halpern <[e-mail]>
>> 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
>> 
>> On 6/8/15 8:32 PM, Stephen Farrell wrote:
>>> 
>>> Hiya,
>>> 
>>> On 09/06/15 01:11, Joel M. Halpern wrote:
>>>> 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.
>>> 
>>> If the question were simple, it'd be easier I guess:-)
>>> 
>>>> 
>>>> You are saying "no".  We are saying "the working group did not
>>>> ask for 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?
>>> 
>>> 
>>>> 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.
>>> 
>>> 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.
>>> 
>>>> 
>>>> You asked for us to be explicit, and to state our reasons.  We
>>>> have done so.
>>> 
>>> Carlos' recent text omitted some points mentioned above.
>>> 
>>>> 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.
>>> 
>>> 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.
>>> 
>>> 
>>>> 
>>>> Yours, Joel
>>>> 
>>>> On 6/8/15 7:53 PM, Stephen Farrell wrote:
>>>>> 
>>>>> 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.
>>>>> 
>>>>> 
>>>>> On 08/06/15 02:35, Carlos Pignataro (cpignata) wrote:
>>>>>> 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
>>>>>>> <[e-mail]> 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
>>>>>>> 
>>>>>>> On 6/7/15 5:04 PM, Stephen Farrell wrote:
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On 07/06/15 21:40, Joel M. Halpern wrote:
>>>>>>>>> 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 
>>>>>>>> no security needed" in the draft? (Seems so to me
>>>>>>>> tbh.)
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 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
>>>>>>>>> 
>>>>>>>>> On 6/7/15 4:34 PM, Stephen Farrell wrote:
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> On 07/06/15 21:31, Joel M. Halpern wrote:
>>>>>>>>>>> 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.
>>>>>>>>>> 
>>>>>>>>>> Hmm. Doesn't BCP61 directly address the above?
>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 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
>>>>>>>>>>> 
>>>>>>>>>>> On 6/7/15 4:15 PM, Stephen Farrell wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>> Hi Carlos,
>>>>>>>>>>>> 
>>>>>>>>>>>> Sorry for the delayed response - some more
>>>>>>>>>>>> travel ensued;-(
>>>>>>>>>>>> 
>>>>>>>>>>> ...
>>>>>>>>>>>> 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.
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>> 
>>>>>>>>>>>>> — Carlos.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>>> _______________________________________________ sfc
>>>>>>> mailing list [e-mail] 
>>>>>>> https://www.ietf.org/mailman/listinfo/sfc
>>>>>> 
>>>>> 
>>>> 
> 
>