Subject: [secdir] SECDIR review of draft-ietf-l2vpn-vpls-inter-domain-redundancy-05

From: Stephen Kent <[email-masked]>
Date: Tue, 15 Apr 2014 17:04:54 -0400

I 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 a very brief document, just 12 pages. The Abstract for this 
document, n its entirety, says: "In many existing Virtual Private LAN 
Service (VPLS) deployments based on RFC 4762, inter-domain connectivity 
has been deployed without node redundancy, or with node redundancy in a 
single domain. This document describes a solution for inter-domain VPLS 
based on RFC 4762 with node and link redundancy in both domains."

Unfortunately, this confusing wording is typical of the writing in 
several areas of this document. The RFC Editor will need to work closely 
with the authors to make this document easier to read. Also, there are 
several instances of acronyms used without expansion (e.g., ASBR), 
making reading even harder.

I like the fact that the document includes a "Motivation" section. It 
provided a good description of why a new approach to achieving 
redundancy in the VPLS context is needed.

Section 5 ends with a curious statement:

There are two PW redundancy modes defined in [RFC6870]:

Independent mode and Master/Slave mode.For the inter-

domain four-PW scenario, it is required for PEs to ensure

that the same mode is supported on the two ICCP peers in

the same RG.One method to ensure mode consistency is by

manual operation.Other methods are also possible and are

out of the scope of this document.

This says that two ASes have to ensure that both employ the same 
redundancy mode choice, notes that they can verify this manually, and 
that says there are other options to meet this requirement, but provides 
no description of the other options.Not very useful.

Sections 5.1.1-3 provide switchover rules for redundancy. Sections 5.1.1 
and 5.1.2 both include SHOULDs, but 5.1.3 contains no analogous RFC 2119 
key words. This lack of parallelism is confusing.

Section 5.3 describes switchover operation in the more complex four PW 
cases. It contains some RFC 2119 key words, but there are several 
instances of lowercase "should". Is this intentional?

The Security Considerations section is brief, only 4 short paragraphs.It 
cites the Security Considerations sections of RFCs 4762 and 6870, plus 
the I-D (draft-ietf-pwe3-iccp) that forms the basis of part of the 
solution described here.

RFC 4762 also contains a brief Security Considerations section, 
referring the reader to RFC 4111, the PPVPN Security Framework. That 
document discusses security in detail, although most of the discussion 
does not appear to be directly applicable to the redundancy mechanisms 
of this document.

RFC 6870 is directly relevant. It contains a two-sentence Security 
Considerations section (almost a record for brevity?) with a lowercase 
"must" for emphasis? This section refers to RFC 4447, which contains a 
meaningful SC section (finally). That document mandates use of the 
TCP/MD5 option for LDP. This is almost consistent with the second 
paragraph of the SC section in this document (which weakens this to a 
MAY), but not with the third paragraph (which seems to call for TCP-AO).

The SC section of draft-ietf-pwe3-iccp calls for use of TCP-AO (SHOULD), 
which reinforces the references in the third paragraph of this SC, but 
is inconsistent with the second paragraph!

The second paragraph in the SC section of this document uses a lowercase 
"could." I wonder if this should be uppercase, as per RFC 6919 J? The 
next paragraph directs implementers to three RFCs (6941, 6952, and 
5925), and specifically cites TCP-AO. This is confusing guidance, given 
the MAY for TCP/MD5 use with LDP in the previous paragraph. Merely 
calling attention to these docs is not useful guidance.

The final paragraph of this section contains two obvious spelling errors 
in the first sentence:

The *activitiy* on the inter-domain and intra-domain

pseudowire may cause security threats or be exploited to

create denial of service *attackes*.

Even if the spelling errors are corrected, it is not clear what value 
this sentence adds. The remaining two sentences of the paragraph provide 
useful guidance, and thus should be retained.

My bottom line: the SC section of this document is internally 
inconsistent and conflicts with SC guidance in several of the other docs 
cited in the SC section. This needs

---

From: "Lizhong Jin" <[email-masked]>
Date: Wed, 16 Apr 2014 23:34:25 +0800

Hi Stephen,

Thank you for the detail review. See my reply inline below.

Regards

Lizhong

From: Stephen Kent [mailto:[email-masked]] 
Sent: Wednesday, April 16, 2014 5:05 AM
To: secdir; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; Adrian Farrel; [email-masked]; [email-masked]
Subject: SECDIR review of draft-ietf-l2vpn-vpls-inter-domain-redundancy-05

I 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 a very brief document, just 12 pages. The Abstract for this document, n its entirety, says: “In many existing Virtual Private LAN Service (VPLS) deployments based on RFC 4762, inter-domain connectivity has been deployed without node redundancy, or with node redundancy in a single domain. This document describes a solution for inter-domain VPLS based on RFC 4762 with node and link redundancy in both domains.” 

Unfortunately, this confusing wording is typical of the writing in several areas of this document. The RFC Editor will need to work closely with the authors to make this document easier to read. Also, there are several instances of acronyms used without expansion (e.g., ASBR), making reading even harder.

[Lizhong] I try to rephrase the abstract below to make it more clear. I will check again for the acronyms in detail. BTW, the ASBR has been expanded in section 3 line 193.

In many existing RFC 4762 based Virtual Private LAN Service (VPLS) inter-domain deployments, the pseudowire (PW) connectivity has been deployed without node redundancy, or with node redundancy only in a single domain. That will take high risk of service interruption, since at least one domain will not have PW node redundancy.  This document describes a inter-domain VPLS solution which could provide PW node redundancy in both domains.

I like the fact that the document includes a “Motivation” section. It provided a good description of why a new approach to achieving redundancy in the VPLS context is needed.

Independent mode and Master/Slave mode.  For the inter-

the same RG.  One method to ensure mode consistency is by

manual operation.  Other methods are also possible and are

This says that two ASes have to ensure that both employ the same redundancy mode choice, notes that they can verify this manually, and that says there are other options to meet this requirement, but provides no description of the other options.  Not very useful.

 [Lizhong] I think the text is OK. If you insist, I could remove.

Sections 5.1.1-3 provide switchover rules for redundancy. Sections 5.1.1 and 5.1.2 both include SHOULDs, but 5.1.3 contains no analogous RFC 2119 key words. This lack of parallelism is confusing.

 [Lizhong] accepted.

Section 5.3 describes switchover operation in the more complex four PW cases. It contains some RFC 2119 key words, but there are several instances of lowercase “should”. Is this intentional?

 [Lizhong] I will check again, some is intentional, but some is not.

The Security Considerations section is brief, only 4 short paragraphs.  It cites the Security Considerations sections of RFCs 4762 and 6870, plus the I-D (draft-ietf-pwe3-iccp) that forms the basis of part of the solution described here. 

RFC 4762 also contains a brief Security Considerations section, referring the reader to RFC 4111, the PPVPN Security Framework. That document discusses security in detail, although most of the discussion does not appear to be directly applicable to the redundancy mechanisms of this document.

RFC 6870 is directly relevant. It contains a two-sentence Security Considerations section (almost a record for brevity?) with a lowercase “must” for emphasis? This section refers to RFC 4447, which contains a meaningful SC section (finally). That document mandates use of the TCP/MD5 option for LDP. This is almost consistent with the second paragraph of the SC section in this document (which weakens this to a MAY), but not with the third paragraph (which seems to call for TCP-AO).

 [Lizhong] RFC6870 SC is only valid for PW control plane. The second, third and fourth paragraph is described for ICCP control plane. I will make that clear in the text.

The SC section of draft-ietf-pwe3-iccp calls for use of TCP-AO (SHOULD), which reinforces the references in the third paragraph of this SC, but is inconsistent with the second paragraph!

The second paragraph in the SC section  of this document uses a lowercase “could.” I wonder if this should be uppercase, as per RFC 6919 J? The next paragraph directs implementers to three RFCs (6941, 6952, and 5925), and specifically cites TCP-AO. This is confusing guidance, given the MAY for TCP/MD5 use with LDP in the previous paragraph. Merely calling attention to these docs is not useful guidance. 

The final paragraph of this section contains two obvious spelling errors in the first sentence:

The activitiy on the inter-domain and intra-domain

create denial of service attackes.

Even if the spelling errors are corrected, it is not clear what value this sentence adds. The remaining two sentences of the paragraph provide useful guidance, and thus should be retained.

My bottom line: the SC section of this document is internally inconsistent and conflicts with SC guidance in several of the other docs cited in the SC section. This needs 

[Lizhong] thank you for the comments. I tend to remove the conflict parts with [I-D.ietf-pwe3-iccp], and only describe the new security considerations. Please help to review the following text:

Besides the security properties of [I-D.ietf-pwe3-iccp] for ICCP control plane, [RFC4762] and [RFC6870] for PW control plane, this document will have additional security consideration for ICCP control plane.

In this document, ICCP protocol is deployed between two PEs or ASBRs. The two PEs or ASBRs should only be connected by a well managed and highly monitored network. This should be ensured by the operator.

The state flapping on the inter-domain and intra-domain pseudowire may cause security threats or be exploited to create denial of service attacks.  For example, excessive pseudowire state flapping (e.g., by malicious peer PE's implementation) may lead to excessive ICCP exchanges. Implementations SHOULD provide mechanisms to perform control-plane policing and mitigate such types of attacks.

---

From: Stephen Kent <[email-masked]>
Date: Thu, 17 Apr 2014 09:55:27 -0400

Lizhong,

Thanks for the quick reply.
> *From:*Stephen Kent [mailto:[email-masked]]
> *Sent:* Wednesday, April 16, 2014 5:05 AM
> *To:* secdir; [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; [email-masked]; Adrian Farrel; 
> [email-masked]; [email-masked]
> *Subject:* SECDIR review of 
> draft-ietf-l2vpn-vpls-inter-domain-redundancy-05
>
> 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.
>
> Service (VPLS) deployments based on RFC 4762, inter-domain 
> connectivity has been deployed without node redundancy, or with node 
> redundancy in a single domain. This document describes a solution for 
> inter-domain VPLS based on RFC 4762 with node and link redundancy in 
> both domains."
>
> several areas of this document. The RFC Editor will need to work 
> closely with the authors to make this document easier to read. Also, 
> there are several instances of acronyms used without expansion (e.g., 
> ASBR), making reading even harder.
>
> [Lizhong] I try to rephrase the abstract below to make it more clear. 
> I will check again for the acronyms in detail. BTW, the ASBR has been 
> expanded in section 3 line 193.
>
The first use of ASBR is before then, I believe.
The convention is to expand an acronym on first use.
>
> In many existing RFC 4762 based Virtual Private LAN Service (VPLS) 
> inter-domain deployments, the pseudowire (PW) connectivity has been 
> deployed without node redundancy, or with node redundancy only in a 
> single domain. That will take high risk of service interruption, since 
> at least one domain will not have PW node redundancy.  This document 
> describes a inter-domain VPLS solution which could provide PW node 
> redundancy in both domains.
>
I think it would be clearer to say:

In many existing Virtual Private LAN Service (VPLS) inter-domain 
deployments (based on RFC 4762), pseudowire (PW) connectivity offers no 
node redundancy, or offers node redundancy only with a single domain. 
This deployment approach incurs a high risk of service interruption, 
since at least one domain will not offer PW node redundancy. This 
document describes an inter-domain VPLS solution that provides PW node 
redundancy across domains.
> that says there are other options to meet this requirement, but 
> provides no description of the other options.  Not very useful.
>
the text is not OK, because its states that there are multiple ways to 
ensure consistency, but  identifies only one.
> ...
If you are defining rules for how to achieve switchover, use of 
non-normative text is not
of much value.
>
> The Security Considerations section is brief, only 4 short 
> paragraphs.  It cites the Security Considerations sections of RFCs 
> 4762 and 6870, plus the I-D (draft-ietf-pwe3-iccp) that forms the 
> basis of part of the solution described here.
>
> [Lizhong] RFC6870 SC is only valid for PW control plane. The second, 
> third and fourth paragraph is described for ICCP control plane. I will 
> make that clear in the text.
>
OK.
>
> ...
>
> [Lizhong] thank you for the comments. I tend to remove the conflict 
> parts with [I-D.ietf-pwe3-iccp], and only describe the new security 
> considerations. Please help to review the following text:
>
> Besides the security properties of [I-D.ietf-pwe3-iccp] for ICCP 
> control plane, [RFC4762] and [RFC6870] for PW control plane, this 
> document will have additional security consideration for ICCP control 
> plane.
>
> In this document, ICCP protocol is deployed between two PEs or ASBRs. 
> The two PEs or ASBRs should only be connected by a well managed and 
> highly monitored network. This should be ensured by the operator.
>
> The state flapping on the inter-domain and intra-domain pseudowire may 
> cause security threats or be exploited to create denial of service 
> attacks.  For example, excessive pseudowire state flapping (e.g., by 
> malicious peer PE's implementation) may lead to excessive ICCP 
> exchanges. Implementations SHOULD provide mechanisms to perform 
> control-plane policing and mitigate such types of attacks.
>
This is clearer.

Steve

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 17 Apr 2014 15:48:20 +0100

Hello,

Just pitching in on one of the points...

>>> This says that two ASes have to ensure that both employ the
>>> same redundancy mode choice, notes that they can verify
>>> this manually, and that says there are other options to meet
>>> this requirement, but provides no description of the other
>>> options.  Not very useful.
>>
> the text is not OK, because its states that there are multiple
> ways to ensure consistency, but  identifies only one. 

We had a bit of a go at this text during AD review, and I may be responsible for
it getting into this state.

Previously the document just said that it was required for PEs to ensure the
same mode was in use. I insisted that some description of how this was done was
added. I don't consider manual operation to be a very good solution (because of
the likely errors that will arise), but it is undoubtedly *a* solution.

I don't believe the current text says that there exist other ways of meeting the
requirement. The text uses the word "other methods are also possible" which is
inevitably true. Yet it is also the authors' contention that so long as *a*
method has been provided, other methods can be out of scope of this document (I
am sure they would be happy for people to invent new mechanisms, it's just that
they don't feel the need). 

So, "not very useful", but not false or misleading.

We could probably dilute the text to read:

  There are two PW redundancy modes defined in [RFC6870]: 
  Independent mode and Master/Slave mode.  For the inter-
  domain four-PW scenario, it is required for PEs to ensure
  that the same mode is supported on the two ICCP peers in
  the same RG.  This can be achieved using manual configuration
  at the ICCP peers. Other methods for ensuring consistency are
  out of the scope of this document.

Thanks to you both for the work.

Adrian

---

From: "Lizhong Jin" <[email-masked]>
Date: Thu, 17 Apr 2014 23:29:15 +0800

Hi Stephen,

See my reply inline below. Thank you.

Regards

Lizhong

From: Stephen Kent [mailto:[email-masked]] 
Sent: Thursday, April 17, 2014 9:55 PM
To: Lizhong Jin; 'secdir'; [email-masked]; [email-masked]; [email-masked]; [email-masked]; 'Adrian Farrel'; [email-masked]; [email-masked]
Subject: Re: SECDIR review of draft-ietf-l2vpn-vpls-inter-domain-redundancy-05

Lizhong,

Hi Stephen,

Regards

Lizhong

[Lizhong] I see the first use of ASBR now. Will fix it.

In many existing Virtual Private LAN Service (VPLS) inter-domain deployments (based on RFC 4762), pseudowire (PW) connectivity offers no node redundancy, or offers node redundancy only with a single domain. This deployment approach incurs a high risk of service interruption, since at least one domain will not offer PW node redundancy. This document describes an inter-domain VPLS solution that provides PW node redundancy across domains.
[Lizhong] accepted, thank you.

the text is not OK, because its states that there are multiple ways to ensure consistency, but  identifies only one. 
[Lizhong] hope you are OK with Adrian’s proposal.

... 

If you are defining rules for how to achieve switchover, use of non-normative text is not
of much value.

OK.

... 

This is clearer.

Steve

---

From: Lizhong Jin <[email-masked]>
Date: Fri, 18 Apr 2014 00:17:13 +0800

Hi Adrian,
OK with the proposal. Thanks.

Regards
Lizhong

---

From: Lizhong Jin <[email-masked]>
Date: Thu, 24 Apr 2014 23:22:27 +0800

Hi Stephen,
We upload the new version. The URL:
http://tools.ietf.org/html/draft-ietf-l2vpn-vpls-inter-domain-redundancy-06
Please check if you are OK with this version. Thank you for detail review.

Regards
Lizhong

On Thursday, April 17, 2014, Lizhong Jin <[email-masked]> wrote:

> *From:* Stephen Kent [mailto:[email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>]
>
> *Sent:* Thursday, April 17, 2014 9:55 PM
> *To:* Lizhong Jin; 'secdir'; [email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>;
> [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>;
> [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>;
> [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>;
> 'Adrian Farrel'; [email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>;
> [email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>
> *Subject:* Re: SECDIR review of
> *From:* Stephen Kent [mailto:[email-masked]]
> *To:* secdir; [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; Adrian Farrel; [email-masked];
> [email-masked]
> effort to review all IETF documents being processed by the IESG.  These
> directors.  Document editors and WG chairs should treat these comments just
> like any other last call comments.
>
>
>
> document, n its entirety, says: “In many existing Virtual Private LAN
> Service (VPLS) deployments based on RFC 4762, inter-domain connectivity has
> been deployed without node redundancy, or with node redundancy in a single
> domain. This document describes a solution for inter-domain VPLS based on
> RFC 4762 with node and link redundancy in both domains.”
>
>
>
> Unfortunately, this confusing wording is typical of the writing in several
> areas of this document. The RFC Editor will need to work closely with the
> authors to make this document easier to read. Also, there are several
> instances of acronyms used without expansion (e.g., ASBR), making reading
> even harder.
>
> [Lizhong] I try to rephrase the abstract below to make it more clear. I
> will check again for the acronyms in detail. BTW, the ASBR has been
> deployed without node redundancy, or with node redundancy only in a single
> domain. That will take high risk of service interruption, since at least
> one domain will not have PW node redundancy.  This document describes a
> inter-domain VPLS solution which could provide PW node redundancy in both
> domains.
>
> node redundancy, or offers node redundancy only with a single domain. This
> deployment approach incurs a high risk of service interruption, since at
> least one domain will not offer PW node redundancy. This document describes
> an inter-domain VPLS solution that provides PW node redundancy across
> domains.
> I like the fact that the document includes a “Motivation” section. It
> provided a good description of why a new approach to achieving redundancy
> in the VPLS context is needed.
>
>
>
> redundancy mode choice, notes that they can verify this manually, and that
> says there are other options to meet this requirement, but provides no
> description of the other options.  Not very useful.
>
> cases. It contains some RFC 2119 key words, but there are several instances
> of lowercase “should”. Is this intentional?
>
>  The Security Considerations section is brief, only 4 short paragraphs.
> It cites the Security Considerations sections of RFCs 4762 and 6870, plus
> the I-D (draft-ietf-pwe3-iccp) that forms the basis of part of the solution
> described here.
>
>
>
> RFC 4762 also contains a brief Security Considerations section, referring
> the reader to RFC 4111, the PPVPN Security Framework. That document
> discusses security in detail, although most of the discussion does not
> appear to be directly applicable to the redundancy mechanisms of this
> document.
>
>
>
> “must” for emphasis? This section refers to RFC 4447, which contains a
> meaningful SC section (finally). That document mandates use of the TCP/MD5
> option for LDP. This is almost consistent with the second paragraph of the
> SC section in this document (which weakens this to a MAY), but not with the
> third paragraph (which seems to call for TCP-AO).
>
> third and fourth paragraph is described for ICCP control plane. I will make
> that clear in the text.
>
> OK.
>
>  ...
>
>
>
> [Lizhong] thank you for the comments. I tend to remove the conflict parts
> with [I-D.ietf-pwe3-iccp], and only describe the new security
> Besides the security properties of [I-D.ietf-pwe3-iccp] for ICCP control
> plane, [RFC4762] and [RFC6870] for PW control plane, this document will
> have additional security consideration for ICCP control plane.
>
>
>
> In this document, ICCP protocol is deployed between two PEs or ASBRs. The
> two PEs or ASBRs should only be connected by a well managed and highly
> monitored network. This should be ensured by the operator.
>
>
>
>