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

From: Alia Atlas <[email-masked]>
Date: Mon, 5 Jan 2015 14:54:34 -0500

[Just adding the SFC WG, since they're not on the recipients list]

Alia

On Sun, Jan 4, 2015 at 2:49 PM, Joel M. Halpern <[email-masked]> wrote:

> I am not understanding the question.  SFC depends upon classification. But
> it does not depend upon any specific classification.  If all it has is
> source and destiantion IP, then that is all it uses.  If it has sources of
> out of band information that it trusts to tell it that SPI X goes to
> service chain Y, then it uses that.  If it can magically read through
> cryptography and know what application is actually running, then it can do
> that.  In some networks, this will result in something that is not useful.
> In others, it will be very useful.  That proportion may change over time,
> based on many factors.  If that is to be addressed anywhere, it would be in
> an applicability or deployment document.  But frankly, with so many
> different uses envisioned, I don't expect it to be discussed anywhere.  In
> particular, I just can't see it in the problem statement document.  Maybe
> others see it differently and can suggest a sensible way to cover it.
>
> Yours,
> Joel
>
>
> On 1/4/15 2:34 PM, Stephen Farrell wrote:
>
>>
>>
>> On 04/01/15 19:27, Joel M. Halpern wrote:
>>
>>> I agree with regard to potential impact on the other parts of the
>>> network from SFC infrastructure.
>>>
>>
>> Grand.
>>
>>  I do not know where the questions of which services can, should, or must
>>> not be provided belongs.  But since SFC is carefully agnostic of the
>>> service specifics, I don't think it belongs here.  If OPS wants to try
>>> to write that document, I wish them luck.
>>>
>>
>> I think we're talking at cross purposes.
>>
>> I would like to know how and when the SFC WG are going to address
>> the tension to which I referred, in their design of SFC.
>>
>> If SFC inherently depends on classification and metadata (as this
>> draft states) then that has to be a relevant question to ask.
>>
>> S.
>>
>>
>>
>>> Yours,
>>> Joel
>>>
>>> On 1/4/15 2:20 PM, Stephen Farrell wrote:
>>>
>>>>
>>>> Hi Joel,
>>>>
>>>> On 04/01/15 18:24, Joel M. Halpern wrote:
>>>>
>>>>> I will leave most of these for the authors or chairs to respond to.
>>>>> There is one aspect where as shepherd I would like to ask for
>>>>> clarification.
>>>>>
>>>>> You raise the question of the implications of RFC 7258.  I am not sure
>>>>> what aspect you expect SFC and the SFC problem statement to deal with.
>>>>> Given both RFC 7258 and other factors, we expect to see more and more
>>>>> of
>>>>> the traffic encrypted.  That will mean that some kinds of services, and
>>>>> some kinds of classification, can not be used with such traffic.
>>>>>
>>>>
>>>> Right. And/or that some folks might feel they're losing out by not
>>>> blocking such traffic so they can do their whizzy classification
>>>> etc.
>>>>
>>>>     That
>>>>> does not mean that the SFC problems don't apply.  Nor that operators do
>>>>> not envision offering services to / regarding such traffic.
>>>>>
>>>>
>>>> Sure. But it does mean there's an obvious tension between some
>>>> security and privacy requirements and some SFC requirements/goals.
>>>>
>>>>  It is not the job of SFC or the SFC problem statement to discuss issues
>>>>> like whether an operator can deploy firewalls or virus scanners that
>>>>> work on encrypted traffic.  This problem statement doesn't care about
>>>>> that.
>>>>>
>>>>> So what is it you would like to see regarding your point 2 in the
>>>>> problem statement?
>>>>>
>>>>
>>>> What I'm trying to understand is where those issues will be addressed
>>>> (esp. given discuss point #1) and why the problem statement doesn't
>>>> consider the tension referred to above to be a relevant problem.
>>>>
>>>>  The security and mangeability issues that I understand the charter to
>>>>> talk about are the security and managability of the SFC infrastructure.
>>>>>
>>>>
>>>> And presumably any notable impacts of that SFC infrastructure on the
>>>> security or manageability of other parts of the network.
>>>>
>>>> Cheers,
>>>> S.
>>>>
>>>>
>>>>
>>>>> Yours,
>>>>> Joel
>>>>>
>>>>> On 1/4/15 12:53 PM, Stephen Farrell wrote:
>>>>>
>>>>>> Stephen Farrell has entered the following ballot position for
>>>>>> draft-ietf-sfc-problem-statement-10: Discuss
>>>>>>
>>>>>> When responding, please keep the subject line intact and reply to all
>>>>>> email addresses included in the To and CC lines. (Feel free to cut
>>>>>> this
>>>>>> introductory paragraph, however.)
>>>>>>
>>>>>>
>>>>>> Please refer to
>>>>>> http://www.ietf.org/iesg/statement/discuss-criteria.html
>>>>>> for more information about IESG DISCUSS and COMMENT positions.
>>>>>>
>>>>>>
>>>>>> The document, along with other ballot positions, can be found here:
>>>>>> http://datatracker.ietf.org/doc/draft-ietf-sfc-problem-statement/
>>>>>>
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------
>>>>>> ----------
>>>>>> DISCUSS:
>>>>>> ------------------------------------------------------------
>>>>>> ----------
>>>>>>
>>>>>>
>>>>>> I have two points to discuss. Hopefully, they should
>>>>>> be fairly easily resolved though there may be a bit
>>>>>> of work needed.
>>>>>>
>>>>>> (1) The secdir review [1] I think does a good job of
>>>>>> identifying some real security issues that will emerege
>>>>>> and that are a consequence of the three bits of
>>>>>> architecture described here. Inclusion of some
>>>>>> variation of the 4 bullets from [1] would be at least a
>>>>>> good start in improving what is clearly an deficient
>>>>>> security considerations section (as Adrian correctly
>>>>>> said). I think that plus some text about other fairly
>>>>>> obvious issues (e.g. slow middlebox s/w update has
>>>>>> prevented applying some patches or slowed down
>>>>>> deployment of new security features, recognising the
>>>>>> tension between SFC and privacy/confidentiality,...)
>>>>>> should be fairly easily done with a little work from
>>>>>> someone.
>>>>>>
>>>>>>       [1]
>>>>>> https://www.ietf.org/mail-archive/web/secdir/current/msg05351.html
>>>>>>
>>>>>> (2) The IAB have encouraged us to encrypt everything
>>>>>> and that, and RFC 7258, would seem to me to be very
>>>>>> much in tension with some aspects of this work. And the
>>>>>> WG charter says "The SFC WG will closely consider and
>>>>>> address the management and security implications when
>>>>>> documenting these deliverables." I see no real evidence
>>>>>> that that has happened so far from this particular
>>>>>> deliverable so my question is: when will you tackle the
>>>>>> security and privacy considerations and the obvious
>>>>>> tension between doing more inside the n/w vs.
>>>>>> protecting users and applications? Also - don't you
>>>>>> consider that DoS attacks are a problem that could be
>>>>>> mitigated or made worse via SFC?  And isn't it clear
>>>>>> that privacy could easily be made worse if SFC is
>>>>>> developed without real consideration of privacy
>>>>>> trade-offs? Resolving this discuss point would ideally
>>>>>> be done by someone pointing me at WG drafts that do
>>>>>> substantively address these issues. (I've not looked,
>>>>>> so it's quite possible that will be done, and if so,
>>>>>> great.) If that is not currently possible, then we
>>>>>> should probably talk some more about when and how that
>>>>>> work is going to happen.  (Translating that last bit:
>>>>>> I'm not trying to insist that the security and privacy
>>>>>> work needed for SFC be finished already, but I'd like
>>>>>> to be confident that it will happen, so this DISCUSS is
>>>>>> perhaps more for chatting with the AD and WG chairs
>>>>>> rather than the authors of this deliverable.)
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------
>>>>>> ----------
>>>>>> COMMENT:
>>>>>> ------------------------------------------------------------
>>>>>> ----------
>>>>>>
>>>>>>
>>>>>>
>>>>>> - There are no IPR declarations on this directly
>>>>>> visible from the agenda (I've seen and reported another
>>>>>> bug near there today, not sure if this is related) but
>>>>>> there is one on this and there are two on a document
>>>>>> that this replaces, with one (#2285) being RAND with
>>>>>> possible royalty/fee. And the other (#2304) gets me a
>>>>>> 404 in the DB while the link is to #2307. I see the
>>>>>> write-up says the WG chairs figure that's ok, but it
>>>>>> only mentions 1 disclosure that it says caused some
>>>>>> concern. So this is just to check all's well, given the
>>>>>> confusing nature of the above. (Possibly the confusion
>>>>>> is just caused by a short-lived tracker bug.)
>>>>>>
>>>>>> - 1.1, RFC6967 is referenced as if it were a spec for
>>>>>> HOST_ID. But it is not. HOST_ID remains highly
>>>>>> controversial and using it as an example here is not a
>>>>>> good plan, as that might be used to claim that HOST_ID
>>>>>> has more acceptance than is the case. Simplest thing is
>>>>>> to just delete that. I'd also argue that HTTP header
>>>>>> "enrichment" has been shown to cause many
>>>>>> vulnerabilities so would also be better deleted.  And
>>>>>> it's noticeable that the examples given are all (or
>>>>>> almost all) ones that will be made harder by more
>>>>>> cryptography, which the IAB and RFC7258 tell us is
>>>>>> good. Don't you have non-invasive examples that
>>>>>> could be added?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 7 Jan 2015 11:35:29 -0500

On Mon, Jan 5, 2015 at 2:54 PM, Alia Atlas <[email-masked]> wrote:
>> out of band information that it trusts to tell it that SPI X goes to service
>> chain Y, then it uses that.  If it can magically read through cryptography
>> and know what application is actually running, then it can do that.  In some
>> networks, this will result in something that is not useful.  In others, it
>> will be very useful.  That proportion may change over time, based on many
>> factors.  If that is to be addressed anywhere, it would be in an
>> applicability or deployment document.  But frankly, with so many different
>> uses envisioned, I don't expect it to be discussed anywhere.  In particular,
>> I just can't see it in the problem statement document.  Maybe others see it
>> differently and can suggest a sensible way to cover it.

Since SFC is limited to a single administrative domain, I think that
impacts this discussion and limits the usefulness of having it in this
document.  Encryption and the challenges that will come should be
mentioned, but I think just at a high-level as the rest of this draft
is very high-level.  For service functions, many can deal with
encrypted traffic (load balancers, filters, etc.) and may be the
appropriate termination point for encryption when accessing services
(load balancers, front end web servers to databases or other functions
in a tiered architecture).

I do agree that this problem will change over time and the draft seems
to be dealing with the current situation.  As the security of
encrypted transport improves (harder to break, end-to-end encryption
required, etc.), the type and order of service functions will adapt.
DPI, firewall proxy functions, and email analysis may not be performed
as they are today.  This draft doesn't go into the functions in depth,
so maybe this isn't the right place and as Stephen requested,
understanding the plans of the WG to describe this in a later draft
would be helpful.

Thanks,
Kathleen

>>>>>>> ----------------------------------------------------------------------
>>>>>>> DISCUSS:
>>>>>>>
>>>>>>> ----------------------------------------------------------------------
>>>>>>>
>>>>>>>
>>>>>>> ----------------------------------------------------------------------
>>>>>>> COMMENT:
>>>>>>>
>>>>>>> ----------------------------------------------------------------------
>>>>>>>
>>>>>>>
>>>>>>>

-- 

Best regards,
Kathleen