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 <[email protected]> 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 >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/gen-art > > _______________________________________________ > Gen-art mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/gen-art _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
