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

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

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:[e-mail]] On Behalf Of Adrian Farrel
> Sent: 22 March 2014 17:02
> To: [e-mail]
> Cc: [e-mail]
> Subject: AD review of draft-ietf-l2vpn-vpls-inter-domain-redundancy
> 
> 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?