Re: [Gen-art] Gen-art telechat review of draft-ietf-mpls-tp-psc-itu-03.txt

[Elwyn Davies <[e-mail]>]

Hi Jari and Adrian,

Yup!  This looks like a good way forwards.

I haven't seen the proposed updates for the editorials but I am sure it
will be fine.

Thanks,
Elwyn

On Thu, 2014-03-27 at 10:37 +0200, Jari Arkko wrote:
> Elwyn,
> 
> Thanks for the review & raising this important issue. Adrian's text suggestion looks like a good way to address the main concern (to me at least, and without going through the details myself). Your thoughts?
> 
> Jari
> 
> On Mar 26, 2014, at 10:39 PM, Adrian Farrel <[e-mail]> wrote:
> 
> > Hi Elwyn,
> > 
> >>> I understand from the document editor that there is a revision in waiting to
> > be
> >>> posted that clears up some remaining nits from your review.
> >> I haven't seen this as yet, nor the psc-updates new version.
> > 
> > PSC-updates just posted (got stuck in a tools snafu).
> > Update to this I-D is pending until after IESG evaluation completes.
> > 
> >> I was trying to capture essentially two points:
> >> - As it stands this doc both introduces capabilities/modes and provides
> >> a definition of one new mode as well as redefining RFC 6378 as providing
> >> a basic mode.  In its introductory function I felt it needed to be
> >> explicit that if you in future wanted a new combination of capabilities
> >> maybe using some additional extra capabiliies then you need to specify
> >> some extra mode in another doc that tells you the combination of bits in
> >> the TLV for the new mode.  OK, there might never be any other modes but
> >> I was told that wasn't the original plan, but I don't understand why it
> >> isn't helpful to be explicit here.
> > 
> > OK. I was distracted by the words in your proposed text :-)
> >>>>   Only combinations of capabilities specified by modes will be
> >>>>   supported by implementations.
> > I read this to mean that implementations *of*this*specification* would reject
> > combinations of capabilities that were not those specified in the two modes
> > described here.
> > My reaction was to say: but the text describes this in great detail.
> > 
> > Now I see what you are saying with respect to capabilities so, we could update
> > the last three paragraphs of the Introduction:
> > OLD
> >   This document introduces capabilities and modes.  A capability is an
> >   individual behavior.  The capabilities of a node are advertised using
> >   the method given in this document.  A mode is a particular
> >   combination of capabilities.  Two modes are defined in this document:
> >   PSC mode and Automatic Protection Switching (APS) mode.
> > 
> >   This document describes the behavior, the priority logic, and the
> >   state machine of the PSC protocol when all the capabilities
> >   associated with the APS mode are enabled.  The PSC protocol behavior
> >   for the PSC mode is as defined in [RFC6378].
> > 
> >   This document updates [RFC6378] by adding a capability advertisement
> >   mechanism.  It is recommended that existing implementations of the
> >   PSC protocol be updated to support this capability.  Backward
> >   compatibility with existing implementations is described in
> >   Section 9.2.1.
> > NEW
> >   This document introduces capabilities and modes.  A capability is an
> >   individual behavior.  The capabilities of a node are advertised using
> >   the method given in this document.  A mode is a particular
> >   combination of capabilities.  Two modes are defined in this document:
> >   PSC mode and Automatic Protection Switching (APS) mode.  Other modes
> >   may be defined as new combinations of the capabilities defined in
> >   this document or through the definition of additional capabilities. 
> >   In either case, the specification defining a new mode will be 
> >   responsible for documenting the behavior, the priority logic, and the
> >   state machine of the PSC protocol when the set of capabilities in the
> >   new mode are enabled.
> > 
> >   This document describes the behavior, the priority logic, and the
> >   state machine of the PSC protocol when all the capabilities
> >   associated with the APS mode are enabled.  The PSC protocol behavior
> >   for the PSC mode is as defined in [RFC6378].
> > 
> >   This document updates [RFC6378] by adding a capability advertisement
> >   mechanism.  It is recommended that existing implementations of the
> >   PSC protocol be updated to support this mechanism.  Backward
> >   compatibility with existing implementations that do not support this
> >   mechanism is described in Section 9.2.1.
> > 
> >   Implementations are expected to be configured to support a specific
> >   set of capabilities (a mode) and to reject messages that indicate the
> >   use of a different set of capabilities (a different mode). Thus, the
> >   capabilities advertisement is not a negotiation, but a verification
> >   that peers are using the same mode.
> > END
> > 
> >> - I had understood from an email exchange with Huub that the authors had
> >> the concept that PSC messages with duff values (such as wrong lengths)
> >> would be picked off as 'invalid messages' and never make it to the main
> >> protocol engine (I assume that this will be addressed in the
> >> psc-updates).  Huub seemed to imply that a message with a set of
> >> capability bits that did not match a mode understood by the node would
> >> be treated as an invalid message rather than triggering the operator
> >> intervention.  This seemed sensible so that the alarm would only be
> > 
> >> triggered if an operator acciedentally reconfigured a different mode.
> > 
> > Implementations can fiddle with their alarm thresholds. It is likely that an
> > implementation that has never talked will raise a flag at once; that an
> > implementation might soak an individual event; and that an implementation could
> > track soak-avoiding flip-flops. However, I don't believe in telling people how
> > to write good code if it doesn't change the bits on the wire. (Well, I do
> > believe in telling them, but I also believe in being paid to tell them :-)
> > 
> > The latest revision of the PSC-updates draft does not mention behaviour on
> > receiving a "malformed" or "unknown" TLV. We planned to raise this point as a
> > last call comment to ensure it is properly discussed, and I have done so just
> > now that last call has started.
> > 
> >> I think Stephen Farrell has picked up on the DoS aspect of this in his
> >> tracker comment.
> > 
> > I don't think Stephen was talking about DoS. I think he referred to fat fingers,
> > and my response was that this is not something dynamic in the configuration
> > within a network. You'll pick one mode for all your nodes, or you'll pick the/an
> > other mode. So if you get it wrong on a new box/interface it just won't come up
> > properly and you'll fix it.
> > 
> > The random splat is, covered by sensible implementation and rarity.
> > A subverted node has far better things to do with its subversion.
> > A MitM attacker could tamper with these bits, but again, they could do far more
> > interesting things to packets if they are able to catch and modify them and
> > reconcile the lower layer, link-level security.
> > 
> > Cheers,
> > Adrian
> > 
> >> 
> >> Regards,
> >> Elwyn
> >>> 
> >>>> Summary:
> >>>> Almost ready.  There are a couple of points which I raised at Last Call
> >>>> and discussed with the authors and others both by email and f2f in
> >>>> London that are not resolved.  These point revolve around being rigorous
> >>>> about wire encoding, clarifying error behaviour and being definite that
> >>>> implementations support modes as specfic combinations of capabilities so
> >>>> that arbitrary capability combinations are not allowed and result in
> >>>> invalid protocol messages.
> >>>> 
> >>>> Major Issues:
> >>>> 
> >>>> Minor Issues:
> >>>> s1: From my discussions with the authors and others associated with this
> >>>> document, it is my understanding that the intention is that only
> >>>> combinations of capabilities specified by modes should be legal and
> >>>> hence that implementations would support modes rather than arbitrary
> >>>> sets of capbilities. I think it would be worth being more explicit about
> >>>> this.  This would answer my comments at Last Call that it was unclear
> >>>> whether other combinations were allowed and would make it clear that a
> >>>> message that arrived with a corrupted bit in the flags field was
> >>>> definitely malformed.  I suggest adding the following text to para 16 of
> >>>> s1 (starts "This document introduces capabilities and modes.") before
> >>>> the last sentence:
> >>>>   Only combinations of capabilities specified by modes will be
> >>>>   supported by implementations.
> >>> 
> >>> While this is true, it is also not helpful!
> >>> Any combination of capabilities (these five and any of the future
> >>> nearly-infinite number of capabilities that can be represented in the bit
> > field)
> >>> could be specified as supported (i.e. as a mode) in the future.
> >>> There are two points of note:
> >>> 1. Only two modes are currently defined
> >>> 2. Any future mode must be specified in combination with the state machines
> >> for
> >>> the mode.
> >>> 
> >>> A message that is received containing a set of capabilities (i.e. a mode)
> > not
> >>> supported by the receiver would be rejected. See Section 9.1.1. That is,
> > this is
> >>> not a negotiation. This is a verification that both speakers are operating
> > in
> >>> the same mode.
> >>> 
> >>> For future compatibility, there is no distinction between a corrupted set of
> >>> capability bits and an unknown mode.
> >>> 
> >>>> Nits/Editorial Comments:
> >>>> 
> >>>> s4.4, para 1:
> >>>> OLD:
> >>>> When the modified priorities specified in this document is in use,..
> >>>> NEW:
> >>>> When the modified priorities specified in this document are in use,..
> >>>> (or maybe better:)
> >>>> When the modified priority order specified in this document is in use,..
> >>>> 
> >>>> s7.3 et seq: The term "selector bridge" is introduced without
> >>>> definition.  I suspect it is a piece of jargon I am supposed to know but
> >>>> I think a reference would help.
> >>> 
> >>> Yes, it is a piece of standard terminology in protection switching. I'm sure
> > the
> >>> authors can find a reference.
> >>> 
> >>>> s9.1: RFC 6378 doesn't define the encoding of the TLV type and TLV
> >>>> length fields, so it needs to be done here (Unsigned integers). It also
> >>>> doesn't define encoding of the overall TLV length field in
> >>>> the PSC header.  This may be thought to be 'obvious' but there is no
> >>>> default specified in IETF documents.
> >>> 
> >>> This is being fixed in draft-ietf-mpls-psc-updates that updates 4368. New
> >>> revision about to be posted before IETF last call.
> >>> 
> >>>> s9.1: Both RFC6378 and this document are incomplete as regards
> >>>> specifying what constitutes an invalid protocol message.  In particular
> >>>> there is no discussion of behaviour if correctly formed but unrecognized
> >>>> TLVs are received.  Do these make the message invalid or should they be
> >>>> ignored?
> >>> 
> >>> This should be included in draft-ietf-mpls-psc-updates as well.
> >>> 
> >>>> s9.1.1 and s12:
> >>>> In s12 it is stated (similar wording in s9.1.1):
> >>>>>   o  If the Capabilities TLV mismatches, the node MUST alert the
> >>>>>      operator and MUST NOT perform any protection switching until the
> >>>>>      operator resolves the mismatch in the Capabilities TLV.
> >>>> Having discussed the situation with the authors and others, I understand
> >>>> that there are circumstances, depending on the underlying transport,
> >>>> that bit errors might not be detected and hence that there is a small
> >>>> probability that corrupt PSC messages may be propagated up to the
> >>>> protocol machine.  At present there is no explicit statement that a
> >>>> corrupted flag word would be trapped as an invalid protocol message
> >>>> (this seems to be the intention) rather than triggering this operator
> >>>> alert.  I think that the best that can be done is specify that a PSC
> >>>> protocol message MUST have the flags for a recognized mode set exactly
> >>>> and otherwise it will be treated as an invalid message.  The wording in
> >>>> s9.1.1 and s12 would then catch an inadvertent reconfiguration.  I
> >>>> suggest adding the following to s9.1.1:
> >>>>   Any PSC message that has a combination of capability bits set that
> >>>>   does not correspond to a defined mode will be treated as an invalid
> >>>>   message and ignored.
> >>> 
> >>> This is plain wrong!
> >>> The receiving device is set to operate in a single mode.
> >>> If the received message is not identical to that mode, it cannot operate.
> >>> Section 9.1.1 already explains how this is handled.
> >>> To restate: this is not a negotiation.
> >>> It is an announcement.
> >>> 
> >>> The possibility of a corrupt message does exist. Neutrinos are remarkably
> >>> unpredictable beasts. And it is remotely possible that the error will arise
> >>> without the underlying transport detecting it. And it is further possible
> > that
> >>> the error will take out a single bit in the capabilities. The result is
> >>> indistinguishable from the sender deciding to tweak its capabilities. That
> > would
> >>> cause a mode mismatch and the process in 9.1.1 would be invoked. Given that
> >> it
> >>> is indistinguishable, why would this be a cause for any different behaviour?
> >>> 
> >>> BTW, Stewart was asking some time back whether there was any record
> >> anywhere of
> >>> an MPLS packet that had been misdelivered because the label had had a
> >> corruption
> >>> event on the wire. We didn't come up with anything and the general feeling
> >> was
> >>> that hardware memory was far more vulnerable.
> >>> 
> >>> 
> >>> 
> >>> 
> >>> 
> >>> 
> >>> 
> >>> _______________________________________________
> >>> Gen-art mailing list
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/gen-art
> > 
> > _______________________________________________
> > Gen-art mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/gen-art
> 
> _______________________________________________
> Gen-art mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/gen-art