Subject: [secdir] Review of draft-ietf-sfc-architecture-08

From: Simon Josefsson <[email-masked]>
Date: Sun, 24 May 2015 21:10:41 +0200

Hello.

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

This is an architectural document, so it doesn't have the usual
security impact that you can easily review.  The Security
Considerations section gently refer any security considerations to
the future documents that will actually realize the archicture.

The security considerations that you would expect to be discussed in an
architecural document are those on an architectural level.  The
archicture proposed here is to change how network services are
delivered.  The document doesn't give many examples, but my
understanding is that the intended services would include firewalls,
NAT, proxies, packet filtering, anti-spam measures, anti-DDOS measure,
QoS, and so on.

The traditional model is static services coupled to network topology
and physical resource. The new model introduced by this document, as
far as I understand, is a dynamic model where delivery of these services
can be moved around more dynamically, by tunneling traffic to the
service and back.

I may have missed it, but I feel that the security consequences of
moving to this new architecture is not discussed in the document.

Some obvious security considerations that are introduced with an
architecture like this are:

  1) When delivery of a service is moved from an on-network-path
  machine to a machine sitting somewhere else, there ought to be some
  consideration to authenticating the involved entities and encrypting
  the traffic between them.

  2) Auditing who has powers over a communication channel will be
  different -- before you evaluated the wires and who had access to the
  machines connected to the wires.  Now you have to review the policies
  configured in the machines and what external entities are involved,
  together with the operational aspects of this boxes that perform the
  service delivery.

  3) Moving traffic around raises the challenge how to achieve that
  without negatively affecting privacy of the traffic.

  4) Protecting the SFC configuration and policies is critical for
  secure operations.  Anyone who gains access may be able to modify
  traffic.

If the above is a bit handwavy, allow me to be more concrete.  Adding
something like the following to the security considerations would at
least acknowledge that there are inherent security considerations with
this architecture:

  The architecture described here is different from the current model,
  and moving to the new model will lead to different security
  arrangements and modeling. For example, when service functions are
  moved from on-path static machines to dynamic remote machines, this
  introduce security and privacy aspects that needs to be addressed.

All this said, I still would classify this document as Ready.  It
mostly just disappoint me that a new architecture can be introduced
without containing a significant discussion of security properties.

/Simon

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 24 May 2015 16:06:43 -0400

While the paragraph you suggest looks reasonable, I am somewhat 
concerned if readers draw the conclusion that we expect to include data 
plane authentication and / or encryption mechanisms as a mandatory part 
of the solution.  There is no such expectation.  While there is reason 
to be concerned about exposure of information across the Internet, the 
document begins by specifically noting that this architecture is for use 
with a single administrative domain.

I am thus concerned that adding the suggested text may give rise to 
unreasonable expectations on solutions which comply with this architecture.

Yours,
Joel

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Mon, 25 May 2015 01:25:56 +0000

Simon,

Many thanks for your detailed review, and in particular your conclusion:
"I still would classify this document as Ready."

It is true that this new architecture introduces a model in which there is a more dynamic service application, decoupling it from network topology path; however, there is no administrative domain changes or admin fragmentation. In other words, taking it very concrete, there is no change in expectations regarding for example encryption. The service is potentially applied in another part of the network and a chain can be created dynamically, but all within the same admin domain as before. 

I am happy to add some text strengthening the security considerations -- however, I am concerned with any text that could be interpreted as a specific strong requirement of encryption on solutions. 

Your proposal ends too definitively as "this
 introduce security and privacy aspects that needs to be addressed", while I see it more as "potentially" or "may in some cases". 

Further, I believe that the main concern you raise is already covered in the "SFC Encapsulation" section of the Security Considerations. 

Thanks!

Thumb typed by Carlos Pignataro.
Excuze typofraphicak errows

> On May 24, 2015, at 15:11, Simon Josefsson <[email-masked]> wrote:
> 
> Hello.
>

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 25 May 2015 23:01:57 -0400 (EDT)

On Sun, 24 May 2015, Carlos Pignataro (cpignata) wrote:

> It is true that this new architecture introduces a model in which there
> is a more dynamic service application, decoupling it from network
> topology path; however, there is no administrative domain changes or
> admin fragmentation. In other words, taking it very concrete, there is
> no change in expectations regarding for example encryption. The service
> is potentially applied in another part of the network and a chain can be
> created dynamically, but all within the same admin domain as before.

As I attemted to say in my secdir review of the sfc-problem-statement
document
(http://www.ietf.org/mail-archive/web/secdir/current/msg05351.html), it is
not clear that being within the same administrative domain excuses one
from considering whether encryption is necessary.  I seem to recall that,
e.g., Google is encrypting all inter-datacenter traffic (I don't remember
about intra-datacenter traffic, though).

I do not think it is realistic to think that one can protect a network at
the boundary -- there are always ways for sufficiently advanced attackers
to get in, and some form of defense in depth is needed.  Now, I grant that
encryption may not always be needed, and it is not the place of SFC to
insist that encryption always be used, but please do not claim that being
in a single administrative domain excuses the operator from considering
whether encryption is necessary.

-Ben Kaduk

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 25 May 2015 23:15:24 -0400

I have no problem if someone wants to add link protection because they 
use someone elses resources as part of their domain.
But that is not SFC's problem, and not something, as far as I can tell, 
for the SFC architecture to address.

We have already had to make clear multiple times to folks that we do not 
expect to require the kind of encryption that you are agreeing we don't 
need to require.  Given that, I am very concerned that we not add words 
which will lead readers to think we are making such a requirement.

Yours,
Joel

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Tue, 26 May 2015 12:09:50 +0000

Ben,

> On May 25, 2015, at 11:01 PM, Benjamin Kaduk <[email-masked]> wrote:
> 

My point was a different one: that SFC does not change these requirements.

I may have misunderstood, but what I read in Simon's review (admittedly oversimplified) was: in SFC you move services from on-network-path (which, as an aside, is really the other way around; it is moving from creating an on-network-path steering of network topology through the service) to a machine ‘elsewhere' — and thus, consequently, you have to encrypt.

My point is that the logic above (which, again, I may have misunderstood) does not follow.

There may be additional security and privacy considerations needed in the DC, in mobile networks, etc. However, the SFC architecture does not change that, and mandating encryption on SFCs might not be the right answer. As we wrote, the solution realizing the architecture need to perform part of that analysis.

As I had said, I am more than happy adding text strengthening the security considerations — as long as we do not mandate a solution at a specific layer.

Best,

— Carlos.

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 26 May 2015 22:17:28 +0200

If it is unreasonable to expect that encryption/authentication will be
part of the architecture, I believe there is a significant problem with
this architecture.  The argument that security is not necessary within
a single administrative domain is one that I complete disagree with.  I
am hoping that I am missing some context here.

/Simon

> concerned if readers draw the conclusion that we expect to include
> data plane authentication and / or encryption mechanisms as a
> mandatory part of the solution.  There is no such expectation.  While
> there is reason to be concerned about exposure of information across
> the Internet, the document begins by specifically noting that this
> architecture is for use with a single administrative domain.
> 
> > security area directors.  Document editors and WG chairs should
> > treat these comments just like any other last call comments.
> >
> > The security considerations that you would expect to be discussed
> > in an architecural document are those on an architectural level.
> > The archicture proposed here is to change how network services are
> > NAT, proxies, packet filtering, anti-spam measures, anti-DDOS
> > measure, QoS, and so on.
> >
> > far as I understand, is a dynamic model where delivery of these
> > services can be moved around more dynamically, by tunneling traffic
> > to the service and back.
> >
> >    machine to a machine sitting somewhere else, there ought to be
> > some consideration to authenticating the involved entities and
> > encrypting the traffic between them.
> >
> >    different -- before you evaluated the wires and who had access
> > to the machines connected to the wires.  Now you have to review the
> > policies configured in the machines and what external entities are
> > involved, together with the operational aspects of this boxes that
> > perform the service delivery.
> >
> > If the above is a bit handwavy, allow me to be more concrete.
> > Adding something like the following to the security considerations
> > would at least acknowledge that there are inherent security
> > considerations with this architecture:
> >
> >    The architecture described here is different from the current
> > model, and moving to the new model will lead to different security
> >    arrangements and modeling. For example, when service functions
> > are moved from on-path static machines to dynamic remote machines,
> > this introduce security and privacy aspects that needs to be
> > addressed.
> >

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 26 May 2015 17:22:58 -0400

Given the expected construction and usage for this, if we rite into the 
archtiecture that encryption and authentication of data plane messages 
are mandatory, then
presumably we will also write such "mandatory" mechanisms into the data 
plane mechanism we specify.

At which point we are writing a specification which will be widely 
ignored.

Given that we are talking about passing packets through a series of 
service functions, requiring encryption between them causes a drastic 
increase in complexity and latency.  As far as I can tell from the way 
customers expect to use this, it is simply unacceptable.  For inter-DC 
(or POP<->DC) operators who wish to protect that traffic wil likely want 
to do so whether or not they are using service chaining.  As such, the 
protection is not a service chaining issue.

So, sorry, but I have to respectfully disagree with you Simon.

Yours,
Joel

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 26 May 2015 22:33:56 +0100

I've yet to read this one so could be plain wrong but I don't
see that our choices here are an architecture that defines (or
re-uses) no security mechanisms/services at all or one that
encrypts everything, but fwiw your response below Joel and earlier
ones read as if those are the only choices and I find that hard
to believe.

S.

On 26/05/15 22:22, Joel M. Halpern wrote:
> At which point we are writing a specification which will be widely ignored.
> 
> _______________________________________________
> secdir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/secdir
> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 26 May 2015 19:07:29 -0400

There may well be something that can be said in the architecture that 
would be helpful.  My concern is that given teh current IETF 
environment, adding the suggested wording to the architecture could 
easily lead the IESG to expect mandatory-to-implement data plane packet 
authentication and / or encryption.

There are proposals to add optional mechanisms to the dataplane 
protocol.  The proposals I have seen have no impact on the architecture.

Yours,
Joel

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 27 May 2015 00:28:35 +0100

> authentication and / or encryption.

Perhaps it would be more useful to respond to the actual
review and not a presumption of what might happen 10 steps
down the road in response to what is a really innocuous
statement that changing the network changes its security
and privacy characteristics.

Again though I've yet to read the draft so I'm not saying
that text is or is not appropriate.

S.

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 26 May 2015 19:41:42 -0400 (EDT)

Hi Carlos,

On Tue, 26 May 2015, Carlos Pignataro (cpignata) wrote:

> I may have misunderstood, but what I read in Simon's review (admittedly
> oversimplified) was: in SFC you move services from on-network-path
> (which, as an aside, is really the other way around; it is moving from
> creating an on-network-path steering of network topology through the
> service) to a machine ‘elsewhere' — and thus, consequently, you have to
> encrypt.

I do not think anyone is saying "you must encrypt".

My take of the key point is that SFC is (potentially) going to be making
the actual physical flow of data very different from how it currently is,
and potentially also divorced from the conceptual topology of the service
function chain (if the service functions are laid out "strangely" compared
to the physical topology).  This has the potential to drastically change
the security issues an operator deploying things has to consider, and an
architecture document should point out that both protocol designers
implementing the architecture and operators using such protocols should be
aware of the new security environment.  Thus, we are proposing that it is
mandatory for protocol designers and operators to consider whether they
should be encrypting, but not mandatory for them to encrypt (if they are
satisfied with their topology).

> There may be additional security and privacy considerations needed in
> the DC, in mobile networks, etc. However, the SFC architecture does not
> change that, and mandating encryption on SFCs might not be the right
> answer. As we wrote, the solution realizing the architecture need to
> perform part of that analysis.

I think that the SFC architecture does have the potential to change where
additional security and privacy considerations are needed.  There can
definitely be security and privacy considerations within a single
administrative domain, and I do not think the current document has
sufficient acknowledgement of the potential for the new architecture to
require drastically different security and privacy measures in some (not
all!) cases.  (Yes, I did read through it before composing this mail.)

I see some text in each of the three areas listed which sort-of addresses
my concerns, ("Used transport mechanisms should satisfy the security
requirements of the specific SFC deployment", "These include [...]
potential confidentiality issues of that policy", "solutions should
consider whether there is a risk of sensitive information slipping out of
the operators control.  Issues of information exposure should also
consider flow analysis"), but they could easily be missed by the reader,
and do not convey a single central sense that adopting SFC will involve a
full reevaluation of network security policy.  That reevaluation will
include security/privacy issues for the original payload as well as the
classification and encapsulation data added by the SFC protocol(s).

> As I had said, I am more than happy adding text strengthening the
> security considerations — as long as we do not mandate a solution at a
> specific layer.

To partially crib from Simon's proposal, how about

The architecture described here is different from the current model, and
moving to the new model could lead to different security arrangements and
modeling. For example, when service functions are moved from on-path
static machines to dynamic remote machines, this can change the flow of
data through the network, and the security and privacy considerations of
the protocol and deployment will need to be reevaluated in light of the
new topology.

The word "reevaluated" is intended to indicate that a new analysis should
be performed, but not that a different conclustion must necessarily be
reached.

-Ben

P.S. "consdierations" in the second paragraph of section 6 is a typo

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 27 May 2015 07:13:15 +0200

Den Tue, 26 May 2015 19:41:42 -0400 (EDT)
skrev Re: [secdir] Review of draft-ietf-sfc-architecture-08:

> > > insist that encryption always be used, but please do not claim
> > > that being in a single administrative domain excuses the operator
> > > from considering whether encryption is necessary.
> > >
> >
> > I may have misunderstood, but what I read in Simon's review
> > (admittedly oversimplified) was: in SFC you move services from
> > on-network-path (which, as an aside, is really the other way
> > around; it is moving from creating an on-network-path steering of
> > network topology through the service) to a machine ‘elsewhere' —
> > and thus, consequently, you have to encrypt.
> 

Agreed.

> and moving to the new model could lead to different security
> can change the flow of data through the network, and the security and
> privacy considerations of the protocol and deployment will need to be
> reevaluated in light of the new topology.
> 
> The word "reevaluated" is intended to indicate that a new analysis
> should be performed, but not that a different conclustion must
> necessarily be reached.

That's better, thank you.  I believe it would have been better to
include a discussion of security concerns in the architecture document
itself -- doing security right sometimes requires architectural
changes, so if it is done later you might realize serious issues -- but
barring that, adding a statement to acknowledge that no security
analysis has been done, and that it has to be done, seems appropriate.

/Simon

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Wed, 27 May 2015 16:50:35 +0000

Hi, Ben,

Thanks for the follow-up, please see inline.

> On May 26, 2015, at 7:41 PM, Benjamin Kaduk <[email-masked]> wrote:
> 
> Hi Carlos,
> 
> aware of the new security environment.

Fully agree — and I believe this is what the current Security Considerations section achieves.

In particular, Section 6 highlights the areas of the new architecture (Overlay, Classification, Encapsulation) of which designers and operators ought to be aware.

>  Thus, we are proposing that it is

Further specifically, the "SFC Encapsulation” seems to cover this.

But as I said, I would not oppose strengthening this section even more.

> all!) cases.  (Yes, I did read through it before composing this mail.)

I do not disagree. Are there areas beyond what’s already in the Security considerations that require specific focus?

> full reevaluation of network security policy.

This is the key of the review, IMHO. On one hand, you seem to acknowledge that your security concerns are already addressed with the existing text. On the other hand, you seem to want to child-proof the text in case a reader misses what is already there already addressing the concern.

I support your view of elevating the message with a central sense of ‘this is an architecture and re-evaluate security’. However, that is not (in my read) what the text proposed by Simon achieved.

I’ll be happy to add a short preamble sentence/paragraph to Section 6 with this, if the WG agrees.

>  That reevaluation will

Yes — which is what the doc already says.

> the protocol and deployment will need to be reevaluated in light of the

“Reevaluated” is significantly better, of course. Here’s another proposal:

"The architecture described here is different from the current model, and
moving to the new model could lead to different security arrangements and
modeling. In the SFC architecture, a relatively static topologically-dependent
deployment model is replaced with the chaining of sets of service functions.
This can change the flow of data through the network, and the security and
privacy considerations of the protocol and deployment will need to be
reevaluated in light of the model.”

Simon, Ben, Joel, Jim, Thomas, Alia, WG,

Thoughs?

— Carlos.

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Wed, 27 May 2015 16:54:08 +0000

Simon,

> On May 27, 2015, at 1:13 AM, Simon Josefsson <[email-masked]> wrote:
> 

A security analysis has been done, resulting in the identification of key areas of security considerations to be taken into account during protocol design and solution deployment.

At an architectural level, Section 6 identifies the architectural building blocks and their specific security considerations, to be addressed by the realization of the architecture. This statement is not an acknowledgement that no security analysis has been done.

> P.S. "consdierations" in the second paragraph of section 6 is a typo

Thank you, Ben. This is already corrected in our working copy.

Best,

— Carlos.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 27 May 2015 13:00:02 -0400

While I can live with the change you propose, I do not think it improves 
the document in any way.

Yours,
Joel

> Hi, Ben,
...

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 27 May 2015 14:16:03 -0400 (EDT)

> Considerations section achieves.

I think we disagree on what the current Security Considerations section
achieves.

> In particular, Section 6 highlights the areas of the new architecture
> (Overlay, Classification, Encapsulation) of which designers and
> operators ought to be aware.
>

So, you believe that the SFC Encapsulation section is intended to cover
the potential need for confidentiality protection of the plaintext payload
which is being encapsulated by SFC?

I think that given the way the current text flows from "an operator may
consider the SFC Metadata as sensitive" straight into "from a privacy
perspective, a user may be concerned about the operator revealing data
about [...] the customer", it causes me to read that privacy concern as
applying only to the SFC Metadata (i.e., not to the original payload).
Likewise for the "risk of sensitive information slipping out of the
operators [sic] control"; since the paragraph started with the SFC
Metadata, it seems like this paragraph may apply only to the metadata.

> But as I said, I would not oppose strengthening this section even more.

But more generally, I think the rhetoric is better (stronger) if it is of
the form "you should do this thing (general concept); here are some
concrete examples", rather than "you should do this list of things"
without giving the overarching motivation.  This is a lot of why I am
pushing for added (summary) text.

> I do not disagree. Are there areas beyond what’s already in the Security
> considerations that require specific focus?

I think I only have the points I mentioned above (lack of clarity
regarding protecting the original payload, and clear rhetoric).  But let's
see if Simon has anything else to add, as well.

> This is the key of the review, IMHO. On one hand, you seem to
> acknowledge that your security concerns are already addressed with the
> existing text. On the other hand, you seem to want to child-proof the
> text in case a reader misses what is already there already addressing
> the concern.

I'm sorry that my message was unclear; I was not intending to "acknowledge
that [my concerns] are already addressed", but rather to say that the
existing text gets some of the way there, but there were still things
missing.  (Hopefully this email is helping clarify already.)

> Yes — which is what the doc already says.

Just to ensure we're getting through to each other, do you mind pointing
to the specific text that you have in mind that is supposed to already
say this?

> reevaluated in light of the model.”

I might add in "new" or "chained" before the very last "model", but this
seems to catch the sentiment I was going for.  The idea would be to insert
this as a new paragraph after the first paragraph of section 6?

Thank you,

Ben

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Wed, 27 May 2015 18:53:19 +0000

Ben,

> On May 27, 2015, at 2:16 PM, Benjamin Kaduk <[email-masked]> wrote:
> regarding protecting the original payload, and clear rhetoric).

OK, let’s make sure we have a way forward for both of them.

> to the specific text that you have in mind that is supposed to already

What changes the flow of data in the network (i.e., direct user traffic to the ‘remote machine’ (as you called it) is the overlay — that is why in the “Service Overlay” section of the Security Considerations we have:

        and can also include authenticity and integrity checking, and/or
        confidentiality provisions.

The use of the SFC Encapsulation is for SFP encapsulation and metadata sharing.

> seems to catch the sentiment I was going for.

Either ‘chain’ or ‘new’ univocally disambiguates ‘model’ — sure.

> The idea would be to insert

Yes, or as the first paragraph of Section 6, as a preamble to the section. Either.

Thank you,

— Carlos.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 27 May 2015 15:08:22 -0400

The "plain text payload" is an IP packet.  Customer IP packet protection 
needs are, in almost all cases I can think of, independent of the 
routing path through the network that the packet takes.  As such, I do 
not see why SFC adding yet another means to direct traffic flows changes 
the protection needs for customer IP packets.

Note that many of the results SFC is trying to simplify are achieved 
today, albeit with more complexity.

So I am having trouble seeing what requirement you want the SFC 
architecture to call out.

Yorus,
Joel

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 28 May 2015 00:02:21 -0400 (EDT)

On Wed, 27 May 2015, Joel M. Halpern wrote:

> The "plain text payload" is an IP packet.  Customer IP packet protection needs
> are, in almost all cases I can think of, independent of the routing path
> through the network that the packet takes.  As such, I do not see why SFC
> adding yet another means to direct traffic flows changes the protection needs
> for customer IP packets.
>
> Note that many of the results SFC is trying to simplify are achieved today,
> albeit with more complexity.
>
> So I am having trouble seeing what requirement you want the SFC architecture
> to call out.

I believe that the main motivating factor is the case where the NSA or
some other "three-letter agency" is sniffing traffic within a network.
There was a bunch of news about "ssl added and removed here" a while back,
motivating some companies to increase the use of encryption within their
networks.

If the attacker only has access to a small number of nodes or links within
the network, then changing the paths over which data passes can
potentially expose it to surveillance when it was not before.  You are
correct that SFC itself may not be adding new real requirements on what
data (paths) should be protected, but it is, in some sense, the first "new
thing" now that we are aware of the extent to which networks come under
attack.  As such, we are inclined to take the opportunity to remind
readers of the potential for these attacks and that they may want to
consider countermeasures as appropriate.

So, it is not exactly an additional requirement in practice, but rather an
additional requirement in terms of what we document in IETF protocols, an
addition made to reflect our changed understanding of the world in which
we operate.

-Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 28 May 2015 00:24:45 -0400 (EDT)

On Wed, 27 May 2015, Carlos Pignataro (cpignata) wrote:

> What changes the flow of data in the network (i.e., direct user traffic
> to the ‘remote machine’ (as you called it) is the overlay — that is why
> in the “Service Overlay” section of the Security Considerations we have:
>

Now that you have pointed me at it, I do see how you feel that the issue
is already covered.  Let me see if I have any suggestions for new text
that would not have required you to point me at it in order for me to see
it.

One thing that comes to mind would be to add a clause at the end of the
sentence to reiterate what data is being protected.  It is late here, so I
have confused myself as to whether that should be "for both the traffic
being forwarded and its encapsulation" or just "for the traffic being
forwarded".

It seems like it would also be helpful to spend another clause or sentence
expounding how the security requirements of the specific SFC deployment
are determined -- perhaps, "These security requirements will depend both
on the structure of the network where SFC is being deployed and the
details of the protocol implementing the SFC architecture; the security
assessment should consider potential threats from both inside and outside
the network."  That's probably overkill, but is perhaps illustrative.

> Yes, or as the first paragraph of Section 6, as a preamble to the section. Either.

Sounds good.

-Ben

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Thu, 28 May 2015 17:30:03 +0000

Hi, Ben,

> On May 28, 2015, at 12:02 AM, Benjamin Kaduk <[email-masked]> wrote:
> 

This is a very noble goal, but let’s not DoS-attack this draft to solve that higher-level objective. :-)

I look forward to satisfactorily addressing the security concerns, and strengthening the SFC architecture. I believe we have convergence points in your other response. I will reply with the specifics there, but a couple additional thoughts below.

> potentially expose it to surveillance when it was not before.

“Changing the path" can potentially remove traffic from surveillance points also, net-improving the situation. My point is that it is conjecture.

>  You are

Given this objective, and the fact you acknowledge that SFC may not be adding new real requirements, I’d recommend a more holistic approach instead of reminding only SFC readers in a corner of the security considerations.

Best,

— Carlos.

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Thu, 28 May 2015 17:31:11 +0000

Ben,

> On May 28, 2015, at 12:24 AM, Benjamin Kaduk <[email-masked]> wrote:
> 

OK.

> forwarded”.

I can add “, for both the network overlay transport and traffic it encapsulates” at the end of that sentence? Or "for both the traffic being forwarded and its encapsulation” as well. I thought this was understood, however.

> the network."  That's probably overkill, but is perhaps illustrative.

To me, it is closer to overkill, but I would not oppose if you very strongly feel it adds value, even if merely illustrative.

>> Yes, or as the first paragraph of Section 6, as a preamble to the section. Either.

Done. Thanks.

— Carlos.