Subject: AD review of draft-ietf-l2vpn-vpls-inter-domain-redundancy

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 22 Mar 2014 17:02:18 -0000

As is my usual practice, I am doing a review of your document as AD to
support the publication request from the WG chairs.  Thanks to Lizhong
for answering my early questions. I understand the intention of the
document and have a number of updates that I think you need to make to
improve the quality and direction of the work.

FWIW I disagree with Lizhong that this is not a protocol specification.
This document specifically gives instructions of process that an 
implementation has to follow (look at Section 5.3) and those procedures
will change what messages the implementation sends. That means that the
text changes what happens on the wire. So, although there are no bits 
and bytes changes, this is a protocol specification.

I have put the document into "Revised I-D Needed" state. When I see a 
new revision, I'll move it forward. In the meantime, you should feel
free to debate any of these points with me if you disagree.

Thanks for the work,
Adrian

==========                               

It would be really nice to fix idnits

---

Please check the text for acronyms that have not been expanded.

---

Several places in the text (but not the boilerplate) please
s/draft/document/

---

I can't see how this is a BCP. I realise that RFC 2026 section 5 is not
really clearly written, but this is a technical spec that describes how
to build a particular function in the network. Standards Track would be
just fine (even though there are no bits and bytes defined) because you
are defining procedures (using 2119 language) that an implementation has
to perform to make this function work (i.e., interoperate).

---

Section 1

Please give a little more information about what the "solution" is. You
don't need to go into full detail, but you do need to give some 
overview. Things I'd like to see covered...
- motivation is to provide service protection mechanisms in the event of
  edge node failure
- basic mechanism is to provide edge node redundancy
- solution is dependent on the use of ICCP (with reference) to 
  coordinate between redundant edge nodes
- no changes to any protocol message formats are needed for this 
  solution and no new protocol options are defined
- this solution is a description of how existing protocol building 
  blocks may be deployed to achieve the desired function, but also
  defines implementation behavior necessary for the function to work.

---

Section 4

3/PE4/PE5/PE6 should read PE3/PE4/PE5/PE6

---

The figures in Section 4 use "RG" but this term is not introduced until
Section 5.

---

Figure 2 might usefully be redrawn to show how PW3 and PW4 attach to the
PEs.

---

Section 5 says

   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 redundancy group (RG).

But you don't say how this is achieved.

---

Section 5.2

   Before
   deploying this inter-domain VPLS, the operators MUST negotiate to
   configure same PW high/low priority at two PW end-points.

How do they do this?

---

Section 5.3

   In this use case, there are generally three options

So, sometimes two options and sometimes four options? :-)
Delete "generally", but also make clear what the three options are.

---

Section 5.3

   support of 'request switchover' bit is required

It would have helped me if this had used the same name as in RFC 6870
(Request Switchover status bit) and had included a reference to RFC
6870.

---

Section 6

There seem to be some independent actions needed (operator negotiation,
setting of mode). Are these security vulnerabilities?

ICCP is being run on the Internet and not in a chassis. Does that make a
difference to the security model?

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 25 Mar 2014 21:35:44 -0000

Hi,

I just want to add to these comments that the Security AD's review of
draft-ietf-pwe3-iccp reads...

> The
> security model relies upon physical security with some (not great)
> provisions for authentication and access controls (address filtering,
> anti-spoofing, MD5 authentication).  Monitoring provides the ability to
> catch a problem if a security breach arises s was described in the
> response to the SecDir review.  Our threat models and understanding of
> them continues to evolve with service providers being a major target, as
> well as administrators.  Stronger authentication options and session
> encryption should be considered if a redesign as suggested in other IESG
> reviews is done.

This suggests that your work should not simply lean on the security
considerations of draft-ietf-pwe3-iccp because they will not be considered to be
sufficient for wider deployment in the Internet.

Thanks,
Adrian

> -----Original Message-----
> From: L2vpn [mailto:[email-masked]] On Behalf Of Adrian Farrel
> Sent: 22 March 2014 17:02
> To: [email-masked]
> Cc: [email-masked]
> Subject: AD review of draft-ietf-l2vpn-vpls-inter-domain-redundancy
>

---

From: "Lizhong Jin" <[email-masked]>
Date: Wed, 26 Mar 2014 09:17:11 +0800

Hi Adrian,
Thank you for the review. We will reply the comments soon.

Regards
Lizhong

> From: Adrian Farrel [mailto:[email-masked]]
> Sent: 2014年3月26日 5:36
> Subject: RE: AD review of draft-ietf-l2vpn-vpls-inter-domain-redundancy
> 
> Hi,
> 
draft-
> ietf-pwe3-iccp reads...
> > anti-spoofing, MD5 authentication).  Monitoring provides the ability
> > to catch a problem if a security breach arises s was described in the
> > them continues to evolve with service providers being a major target,
> > as well as administrators.  Stronger authentication options and
> > session encryption should be considered if a redesign as suggested in
> > other IESG reviews is done.
> 
> considerations of draft-ietf-pwe3-iccp because they will not be considered
to
> be sufficient for wider deployment in the Internet.
> 
> Thanks,
> Adrian
> 
> > implementation has to follow (look at Section 5.3) and those
> > procedures will change what messages the implementation sends. That
> > means that the text changes what happens on the wire. So, although
> > there are no bits and bytes changes, this is a protocol specification.
> >
> > I can't see how this is a BCP. I realise that RFC 2026 section 5 is
> > not really clearly written, but this is a technical spec that
> > describes how to build a particular function in the network. Standards
> > Track would be just fine (even though there are no bits and bytes
> > defined) because you are defining procedures (using 2119 language)
> > that an implementation has to perform to make this function work (i.e.,
> interoperate).
> >
> > ---
> >
> > Section 1
> >
> > Please give a little more information about what the "solution" is.
> > You don't need to go into full detail, but you do need to give some
> > The figures in Section 4 use "RG" but this term is not introduced
> > until Section 5.
> >
> > ---
> >
> > Figure 2 might usefully be redrawn to show how PW3 and PW4 attach to
> > the PEs.
> >
> > ---
> >
> > Section 5 says
> >
> > So, sometimes two options and sometimes four options? :-) Delete
> > "generally", but also make clear what the three options are.
> >
> > ---
> >
> > Section 5.3
> >
> > There seem to be some independent actions needed (operator
> > negotiation, setting of mode). Are these security vulnerabilities?
> >
> > ICCP is being run on the Internet and not in a chassis. Does that make
> > a difference to the security model?

---

From: "Lizhong Jin" <[email-masked]>
Date: Fri, 28 Mar 2014 00:59:51 +0800

Hi Adrian,
Sorry for the late reply. Please see my reply inline below.
Please co-authors help to correct if I am wrong.

Regards
Lizhong

> Sent: Sunday, March 23, 2014 1:02 AM
[Lizhong] accepted

> Please check the text for acronyms that have not been expanded.
[Lizhong] accepted

> Several places in the text (but not the boilerplate) please
[Lizhong] accepted

> to perform to make this function work (i.e., interoperate).
[Lizhong] thank you for pointing out this. We will change to Standards Track.

>   defines implementation behavior necessary for the function to work.
[Lizhong] accepted, and I try to rephrase as below:
In many existing Virtual Private LAN Service (VPLS) deployments based on [RFC4762], inter-domain connectivity has been deployed without node redundancy, or with node redundancy in a single domain.  This document is to provide a service protection mechanism for inter-domain VPLS based on [RFC4762]. The protection mechanism will provide edge node redundancy and link redundancy in both domains.  The domain in this document refers to autonomous system (AS), or other administrative domains.
The solution relies on the use of ICCP [ietf-pwe3-iccp] to coordinate between redundant edge nodes, and use of Pseudowire (PW) Preferential Forwarding Status Bit [RFC 6870] to negotiate the PW status. There is no change to any protocol message formats and no new protocol options introduced. This solution is a description of reusing existing protocol building blocks to achieve the desired function, but also defines implementation behavior necessary for the function to work.

> 3/PE4/PE5/PE6 should read PE3/PE4/PE5/PE6
[Lizhong] accepted
> The figures in Section 4 use "RG" but this term is not introduced until
[Lizhong] accepted
> the
[Lizhong] do you mean the PW is broken to the PE in the figure? Will fix that. Thanks.
> But you don't say how this is achieved.
[Lizhong] will add: One method to ensure mode consistency is by manual operation. Other methods are also possible and is out of the scope of this document.

>    configure same PW high/low priority at two PW end-points.
[Lizhong] we check this with the operator. When they do inter-AS connection, there will be some kind of contract to ensure the interconnection. The PW priority could be one part of the contract/negotiation. This is more of the operation method. Now I think we should not use RFC2119 word "MUST" here. "should" would be a better word here.

> Delete "generally", but also make clear what the three options are.
[Lizhong] it would be clear to say: In this use case, there are two options to provide protection: 1:1 and 3:1 protection.

> (Request Switchover status bit) and had included a reference to RFC
[Lizhong] Accepted. Thanks.

> difference to the security model?
[Lizhong] yes, more consideration is required. I try to change:
Besides of the security properties of [I-D.ietf-pwe3-iccp] and [RFC4762], this draft will have additional security consideration. 
When deploying the inter-domain redundancy mechanism described in this document, some manual operation/negotiation is required to be done correctly and securely. E.g., each node within one RG should be configured with same redundancy mode; the two operators should negotiate to configure same PW priority at two nodes. If the configuration consistency is broken, the inter-domain redundancy mechanism may not work properly.
Since ICCP is now deployed between two PEs or ASBRs, the LDP session could be secured with TCP Authentication Option [RFC5925]. This provides integrity and authentication for the ICCP messages. The LDP MD5 authentication key option, as described in section 2.9 of [RFC5036] MAY also be used.

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 30 Mar 2014 20:41:20 +0100

Hi Lizhong,

> Please co-authors help to correct if I am wrong.

[snip]

> > are defining procedures (using 2119 language) that an implementation
> > has to perform to make this function work (i.e., interoperate).
>

Good. I hope the WG is paying attention!

> > - motivation is to provide service protection mechanisms in the event
> >   of edge node failure
> In many existing Virtual Private LAN Service (VPLS) deployments based on
> [RFC4762], inter-domain connectivity has been deployed without node
> redundancy, or with node redundancy in a single domain.  This document is to
> provide a service protection mechanism for inter-domain VPLS based on
> [RFC4762]. The protection mechanism will provide edge node redundancy and
> link redundancy in both domains.  The domain in this document refers to
> autonomous system (AS), or other administrative domains.
> The solution relies on the use of ICCP [ietf-pwe3-iccp] to coordinate between
> redundant edge nodes, and use of Pseudowire (PW) Preferential Forwarding
> Status Bit [RFC 6870] to negotiate the PW status. There is no change to any
> protocol message formats and no new protocol options introduced. This solution
> is a description of reusing existing protocol building blocks to achieve the desired
> function, but also defines implementation behavior necessary for the function to
> work.

Works for me.

[snip]

> [Lizhong] do you mean the PW is broken to the PE in the figure? Will fix that.

Yeah. PW3 should connect to PE3 etc.

> [Lizhong] will add: One method to ensure mode consistency is by manual
> operation. Other methods are also possible and is out of the scope of this
> document.

I'm OK with that, but it is a bit thin. Operators are famous for not configuring the same thing at two ends of a link.

> [Lizhong] we check this with the operator. When they do inter-AS connection,
> there will be some kind of contract to ensure the interconnection. The PW
> priority could be one part of the contract/negotiation. This is more of the
> operation method. Now I think we should not use RFC2119 word "MUST" here.
> "should" would be a better word here.

Yup, "should" is better, and maybe add "The inter-domain VPLS relationship normally involves a contractual process between operators, and the configuration of PW roles forms part of this process."

> [Lizhong] it would be clear to say: In this use case, there are two options to
> provide protection: 1:1 and 3:1 protection.

OK

[snip]

> Besides of the security properties of [I-D.ietf-pwe3-iccp] and [RFC4762], this draft
> will have additional security consideration.
> When deploying the inter-domain redundancy mechanism described in this
> document, some manual operation/negotiation is required to be done correctly
> and securely. E.g., each node within one RG should be configured with same
> redundancy mode; the two operators should negotiate to configure same PW
> priority at two nodes. If the configuration consistency is broken, the inter-domain
> redundancy mechanism may not work properly.
> Since ICCP is now deployed between two PEs or ASBRs, the LDP session could be
> secured with TCP Authentication Option [RFC5925]. This provides integrity and
> authentication for the ICCP messages. The LDP MD5 authentication key option, as
> described in section 2.9 of [RFC5036] MAY also be used.

That is good except that MD5 is pretty much regarded as useless as a security tool these days.

How about adding to the end of your text:

"The attention of implementers and deployers is drawn to [RFC6941]  and [RFC6952] with special attention to the recommendation to use TCP-AO [RFC5925] for enhanced security of LDP sessions."

Cheers,
Adrian

---

From: Loa Andersson <[email-masked]>
Date: Mon, 31 Mar 2014 11:06:48 +0200

Adrian,

> Good. I hope the WG is paying attention!

As part of the working group I find that what you say above it not
entirely clear.

I can think of two things:

1. It will have an effect on the Shepherd Write-up, I guess that Giles
    can take care of that.

2. I also think that changing a draft from BCP to PS would need to
    confirmed by the working group. I support this change but I guess a
    short wglc would be in place.

/Loa

-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert                          [email-masked]
Huawei Technologies (consultant)     phone: +46 739 81 21 64

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 31 Mar 2014 13:19:18 +0100

Hi Loa,

>     short wglc would be in place.

Good, you see, you were paying attention.

Shepherd write-up is something between me and the shepherd, we can take care of that.

Change of status from BCP to Standards track is something the WG has to be happy with. The WG chairs are the people who assess whether the WG is happy. They can use any tool they like.

Cheers,
Adrian

---

From: "Lizhong Jin" <[email-masked]>
Date: Mon, 31 Mar 2014 22:47:24 +0800

Hi Adrian,
Thank you for the quick reply. See my reply inline below.
We will post a new version accordingly soon to reflect these comments.

Regards
Lizhong

> Sent: 2014年3月31日 3:41
> To: 'Lizhong Jin'; draft-ietf-l2vpn-vpls-inter-domain-
> [email-masked]
> Cc: [email-masked]
> > > describes how to build a particular function in the network.
> > > Standards Track would be just fine (even though there are no bits
> > > and bytes defined) because you are defining procedures (using 2119
> > > language) that an implementation has to perform to make this function
> work (i.e., interoperate).
> >
[Lizhong] OK, we will post a new version accordingly.

> > In many existing Virtual Private LAN Service (VPLS) deployments based
> > on [RFC4762], inter-domain connectivity has been deployed without node
> > redundancy, or with node redundancy in a single domain.  This document
> > is to provide a service protection mechanism for inter-domain VPLS
> > based on [RFC4762]. The protection mechanism will provide edge node
> > redundancy and link redundancy in both domains.  The domain in this
> > document refers to autonomous system (AS), or other administrative
> domains.
> > The solution relies on the use of ICCP [ietf-pwe3-iccp] to coordinate
> > between redundant edge nodes, and use of Pseudowire (PW) Preferential
> > Forwarding Status Bit [RFC 6870] to negotiate the PW status. There is
> > no change to any protocol message formats and no new protocol options
> > introduced. This solution is a description of reusing existing
> > protocol building blocks to achieve the desired function, but also
[Lizhong] Thanks.
> Yeah. PW3 should connect to PE3 etc.
[Lizhong] Thanks.
> > operation. Other methods are also possible and is out of the scope of
> > this document.
> 
[Lizhong] I understand. At current stage, let's keep it simple.

> > [Lizhong] we check this with the operator. When they do inter-AS
> > connection, there will be some kind of contract to ensure the
> > interconnection. The PW priority could be one part of the
> > contract/negotiation. This is more of the operation method. Now I think we
> should not use RFC2119 word "MUST" here.
> Yup, "should" is better, and maybe add "The inter-domain VPLS relationship
> normally involves a contractual process between operators, and the
> configuration of PW roles forms part of this process."
[Lizhong] OK, thanks.

> > [Lizhong] it would be clear to say: In this use case, there are two
> > options to provide protection: 1:1 and 3:1 protection.
> 
> OK
> 
> [snip]
> 
> > > Section 6
> > >
> > > ICCP is being run on the Internet and not in a chassis. Does that
> > > make a difference to the security model?
> > Besides of the security properties of [I-D.ietf-pwe3-iccp] and
> > [RFC4762], this draft will have additional security consideration.
> > document, some manual operation/negotiation is required to be done
> > correctly and securely. E.g., each node within one RG should be
> > configured with same redundancy mode; the two operators should
> > negotiate to configure same PW priority at two nodes. If the
> > configuration consistency is broken, the inter-domain redundancy
> mechanism may not work properly.
> > Since ICCP is now deployed between two PEs or ASBRs, the LDP session
> > could be secured with TCP Authentication Option [RFC5925]. This
> > provides integrity and authentication for the ICCP messages. The LDP
> > MD5 authentication key option, as described in section 2.9 of [RFC5036]
> MAY also be used.
> 
> "The attention of implementers and deployers is drawn to [RFC6941]  and
> [RFC6952] with special attention to the recommendation to use TCP-AO
> [RFC5925] for enhanced security of LDP sessions."
[Lizhong] OK, thanks.