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

["Carlos Pignataro (cpignata)" <[e-mail]>]

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