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

[Radia Perlman <[e-mail]>]

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