Re: [secdir] secdir review of draft-ietf-pwe3-redundancy-06

[Stewart Bryant <[e-mail]>]

Authors

Please can you answer or address these comments

Thanks

Stewart


On 19/03/2012 22:22, Radia Perlman wrote:
> I have 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 requirements document (intended as informational) for a
> routing protocol.
>
>
>
> At this level of abstraction, I don’t think there are any interesting
> security issues. There are some messages in the protocol that need to
> be communicated securely, and the security considerations section
> references some other RFCs and says the new messages will “inherit at
> least the same security properties” as the messages in those other
> RFCs. I didn’t look up what kind of protection existed there.
>
>
>
> The interesting routing protocol issue has to do with nesting of
> routing algorithms and the needed multipliers in timeouts. It would
> appear that pseudo-wires run over a conventional routed infrastructure
> and also connect parts of a conventional routed infrastructure. The
> spec assumes that failures within the inner routed infrastructure will
> heal themselves quickly enough to not be noticed by the pwe3
> redundancy protocol (if they are capable of healing at all), and that
> pseudo-wire failover (triggered by this inner failure) will happen
> quickly enough to not disrupt the routing protocol that is running
> over the pseudo-wires.
>
>
>
> But that requirement is not explicitly acknowledged in the document,
> and it intuitively seems like a significant challenge.
>
>
>
> Micro-level issues:
>
>
>
> In terminology (section 2), the Primary PW is defined as the one that
> will be used when any one will do, and that if it goes down and comes
> back the PW will revert to it. But it also defines non-revertive
> protection switching as an option where the traffic will not switch
> back to the primary unless the secondary fails, and in section 4.1 it
> says that non-revertive protection MUST be supported and revertive is
> optional.
>
>
>
> Typos:
>
>
>
> Section 4.1:
>
> besupported ->  be supported
>
> suported ->  supported
>
>
>
> Section 4.2:
>
> Orphaned bullet
>


-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html