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

["Adrian Farrel" <[e-mail]>]

Yes, good job.

Please post it.

Adrian

> -----Original Message-----
> From: Lizhong Jin [mailto:[e-mail]]
> Sent: 08 April 2014 14:26
> 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,
> 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
> > >