Subject: Re: Last Call: <draft-ietf-mpls-sfc-04.txt> (An MPLS-Based Forwarding Plane for Service Function Chaining) to Proposed Standard

From: S Moonesamy <[email-masked]>
Date: Sat, 09 Feb 2019 05:41:55 -0800

Hi Adrian,
At 11:52 AM 17-01-2019, The IESG wrote:
>The IESG has received a request from the Multiprotocol Label Switching WG
>(mpls) to consider the following document: - 'An MPLS-Based Forwarding Plane
>for Service Function Chaining'
>   <draft-ietf-mpls-sfc-04.txt> as Proposed Standard
>
>The IESG plans to make a decision in the next few weeks, and solicits final
>comments on this action. Please send substantive comments to the
>[email-masked] mailing lists by 2019-01-31. Exceptionally, comments may be

I took a quick look at the draft.  Section 15 states that the draft 
does not introduce any security vulnerabilities and leaves it to the 
underlying technologies using the design to address the security 
vulnerabilities which they might introduce.  That is like the IETF 
stating that there are no known or unknown defects in the design 
except for what has been stated in the first three paragraphs of Section 15.

Regards,
S. Moonesamy

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 11 Feb 2019 10:29:09 -0600

Hi SM,

>From a purely rhetorical perspective, you are just making some statements
about the document that seem to be statements of fact.  If you are asking
for the document to change, it would probably be useful to actually say
what you would change.

-Ben

---

From: S Moonesamy <[email-masked]>
Date: Mon, 11 Feb 2019 08:56:42 -0800

Hi Ben,
>for the document to change, it would probably be useful to actually say

As a mild suggestion, the last paragraph in Section 15 of 
draft-ietf-mpls-sfc-04 could be removed.

Regards,
S. Moonesamy

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 11 Feb 2019 17:34:23 -0000

Ben,

Thanks for responding to this and so for bringing it to my attention
(somehow it was missing from my inbox).

SM, 

I had some exchanges (on this list) with Russ Mundy who did a SecDir review
during WG last call. I believe that this will lead to some edits to the
Security Considerations section.

But I don't think that this document has holes to plug. There are, of
course, no control plane implications in this document, so that doesn't need
attention. That leaves us with the architecture/function of SFC itself, and
the underlying transport. 

The text should make clear that the security properties are exactly the
security properties of SFC as described in the SFC architecture together
with the security properties of the MPLS data plane. This is perhaps not
clear enough in the document, and my discussion with Russ left me with a
plan to include some discussion:
- of the security of the MPLS forwarding plane (with references)
- about what would happen if someone was able to tamper with a packet
- of the fact that if someone can successfully tamper with an MPLS packet
   in flight then they can do a lot of other bad things as well

In your other email you suggested removing the last paragraph. We could
certainly do that. Are you objecting to it because it states the obvious
(which can be frustrating, but is hardly harmful), or because it says
something that is fundamentally wrong (in which case I don't see what it
is)?

Thanks,
Adrian

-----Original Message-----
From: Benjamin Kaduk <[email-masked]> 
Sent: 11 February 2019 16:29
To: S Moonesamy <[email-masked]>
Cc: Adrian Farrel <[email-masked]>; [email-masked]
Subject: Re: Last Call: <draft-ietf-mpls-sfc-04.txt> (An MPLS-Based
Forwarding Plane for Service Function Chaining) to Proposed Standard

Hi SM,

-Ben

---

From: S Moonesamy <[email-masked]>
Date: Mon, 11 Feb 2019 12:03:58 -0800

Hi Adrian,
>(somehow it was missing from my inbox).

I noticed that the email was not delivered.  I'll reach out to you 
off-list if the issue occurs again.

>Security Considerations section.

Ok.

>the underlying transport.

I thought about the control plane angle.  The usual security 
considerations are not directly applicable in the case of this draft [1].

>    in flight then they can do a lot of other bad things as well

The "classifier" caught my attention because of the way it is 
described in Section 15.  I assume that you already covered that in 
the discussion about "control/management plane".   I'll say okay to 
the above to avoid getting entangled into the SecDir thread.

>something that is fundamentally wrong (in which case I don't see what it

I didn't read the text as stating the obvious; I may be reading it 
incorrectly.  I would not argue that the text is harmful as that 
would be an exaggeration.

What if a security vulnerability is discovered in the design in 
future?  I read the text as meaning that it would be up to the 
underlying technologies to address that.  That does not make sense to 
me.  The text could also be read as meaning that an (intended) 
proposed standard will not have any unknown defects.  The draft is 
not at that maturity level yet.

Regards,
S. Moonesamy

1.  I oversimplified the sentence for ease of discussion.

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 11 Feb 2019 20:36:59 -0000

Thanks SM.

> the above to avoid getting entangled into the SecDir thread.

OK. Yes, the Classifier is configured through the management or control plane, so it is worth me highlighting the whole thing.

> would be an exaggeration.

Good, I must have told you a million times not to exaggerate 😊

> underlying technologies to address that.  That does not make
> sense to me.  The text could also be read as meaning that an 
> (intended) proposed standard will not have any unknown
> defects.  The draft is not at that maturity level yet.

Right, I get it. Wordsmithing is needed.

Thanks,
Adrian