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

["Lizhong Jin" <[e-mail]>]

Hi Adrian,
The draft authors suggest to separate "security" section into "management" and "security", and the new content is as below. Are you OK with the following changes?

6.  Management Considerations

   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.


7.  Security Considerations

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

   ICCP is now deployed between two PEs or ASBRs, the two PEs or ASBRs
   should be connected by a well managed and highly monitored network.
   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.

   The activitiy on the inter-domain and intra-domain pseudowire may
   cause security threats or be exploited to create denial of service
   attackes.  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.

Regards
Lizhong

> -----Original Message-----
> From: Lizhong Jin [mailto:[e-mail]]
> Sent: Monday, March 31, 2014 10:47 PM
> To: [e-mail]; draft-ietf-l2vpn-vpls-inter-domain-
> [e-mail]
> Cc: [e-mail]
> Subject: RE: AD review of draft-ietf-l2vpn-vpls-inter-domain-redundancy
> 
> 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
> 
> > -----Original Message-----
> > From: Adrian Farrel [mailto:[e-mail]]
> > Sent: 2014年3月31日 3:41
> > To: 'Lizhong Jin'; draft-ietf-l2vpn-vpls-inter-domain-
> > [e-mail]
> > Cc: [e-mail]
> > Subject: RE: AD review of draft-ietf-l2vpn-vpls-inter-domain-
> redundancy
> >
> > Hi Lizhong,
> >
> > > Sorry for the late reply. Please see my reply inline below.
> > > Please co-authors help to correct if I am wrong.
> >
> > [snip]
> >
> > > > 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).
> > >
> > > [Lizhong] thank you for pointing out this. We will change to
> Standards
> > > Track.
> >
> > Good. I hope the WG is paying attention!
> [Lizhong] OK, we will post a new version accordingly.
> 
> >
> > > > 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.
> > > [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.
> >
> > Works for me.
> [Lizhong] Thanks.
> >
> > [snip]
> >
> > > > Figure 2 might usefully be redrawn to show how PW3 and PW4 attach
> to
> > > > the PEs.
> > > [Lizhong] do you mean the PW is broken to the PE in the figure?
> Will fix
> > > that.
> > > Thanks.
> >
> > Yeah. PW3 should connect to PE3 etc.
> [Lizhong] Thanks.
> >
> > > > 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.
> > > [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] I understand. At current stage, let's keep it simple.
> 
> >
> > > > 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?
> > > [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] OK, thanks.
> 
> >
> > > > 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.
> > > [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
> > > >
> > > > 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?
> > > [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.
> >
> > 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."
> [Lizhong] OK, thanks.
> 
> >
> > Cheers,
> > Adrian
> >