Re: [secdir] secdir review of draft-ietf-mpls-residence-time-12

[Benjamin Kaduk <[e-mail]>]

On Fri, Jan 20, 2017 at 05:47:00PM -0800, Greg Mirsky wrote:
> Hi Ben,
> thank you for the careful review and the most helpful comments and
> suggestions. We're working on the new version to address GEN-ART, OPS and
> Security comments. I've attached the diff and current working version of
> the draft. Please find my responses to your comments in-lined and tagged
> GIM>>.

Thanks!
Most of the changes are helpful; the only thing I would note about the
new text is in the security considerations, where the discussion of
"complex crypto schemes" seems like it should come after the mention
of "for further study", not before.

I as a new reader to the field would still benefit from some discussion
and/or examples of how the new data structures interact with each other
and the parent containers, but I should defer to the experts as to what
is actually needed.

I will trim the parts of the message that I sound good and I have no
further comment on.

> 
> On Tue, Jan 17, 2017 at 10:00 PM, Benjamin Kaduk <[e-mail]> wrote:
> 
> > This document also mentions RFC 7384, whose entirety is security
> > requirements
> > of time procotols, which probably contains more detail than this document
> > would
> > need if discussion was inline.  However, the security considerations of
> > draft-ietf-mpls-residence-time-12 also contains discussion about how
> > PTP-aware nodes on the path are required to modify the messages, and the
> > needed trust model involves these nodes being trusted to perform those
> > modifications.
> > That seems true and is probably fine for a protocol that is running on
> > "trusted infrastructure", but the claim is also made that the messages
> > modified
> > by intermediate nodes "cannot be authenticated".  This is only somewhat
> > true, as one can create complex crypto schemes that involve giving key
> > material to intermediate nodes that can let them make authenticated
> > (but detectable) modifications.  Such schemes seem far too complex for the
> > topic at hand, though, as they are likely to increase the processing delay
> > for the time packets, and it seems fine to defer investigating them in the
> > same way that it is fine to defer investigating authenticating/encrypting
> > the RTM data that does not need to be modified by intermediate nodes, which
> > is explicitly noted in the security considerations.
> >
> GIM>> I agree with your suggestion. Would the following change address your
> comment:
> 
> ---
> 
> OLD TEXT:
> 
>    As a result, the content of the PTP-related data in RTM messages that
> 
>    will be modified by intermediate nodes cannot be authenticated, and
> 
>    the additional information that must be accessible for proper
> 
>    operation of PTP 1-step and 2-step modes MUST be accessible to
> 
>    intermediate nodes (i.e. - MUST NOT be encrypted in a manner that
> 
>    makes this data inaccessible).
> 
> ...
> 
>    The ability for potentially authenticating and/or encrypting RTM and
> 
>    PTP data that is not needed by intermediate RTM/PTP-capable nodes is
> 
>    for further study.
> 
> NEW TEXT:
> 
>   That likely to require some complex crypto schemes that involve giving key
> 
> material to intermediate RTM/PTP-capable nodes that can let them make
> 
> authenticated (but detectable) modifications to the additional
> 
> information in RTM messages.
> 
>    The ability for potentially authenticating and/or encrypting RTM and
> 
>    PTP data for scenarios both with and without participation of
> 
>    intermediate RTM/PTP-capable nodes is for further study.

I think this should be reordered to be more useful, something like
(with a few more tweaks):

   In addition - particularly as applied to use related to PTP - there
   is a presumed trust model that depends on the existence of a trusted
   relationship of at least all PTP-aware nodes on the path traversed by
   PTP messages.  This is necessary as these nodes are expected to
   correctly modify specific content of the data in PTP messages and
   proper operation of the protocol depends on this ability.  In practice,
   this means that those portions of the messages cannot be covered by
   either confidentiality or integrity protection.  Though there are
   methods that make it possible in theory to provide either or both such
   protections and still allow for intermediate nodes to make
   detectable but authenticated modifications, such methods do not seem
   practical at present, particularly for timing protocols that are
   sensitive to latency.

   The ability for potentially authenticating and/or encrypting RTM and
   PTP data for scenarios both with and without participation of
   intermediate RTM/PTP-capable nodes is left for further study.


> -------
> 
> >
> > I do think there are some relevant security considerations that are not
> > mentioned, though -- for the two-step flow, an RTM-capable node is
> > required to wait for the follow-up RTM message and make the corresponding
> > residence time update.  This requirement is unbounded and could lead to
> > a resource leak if that follow-up packet fails to arrive, for an
> > implementation
> > that blindly follows the spec without resorting to practical engineering
> > knowledge.  I do not expect there to be any such implementations, but this
> > document should probably indicate that timing out is okay within
> > "reasonable" bounds, or whatever similar workaround is best practice in
> > this
> > domain.
> >
> GIM>> Indeed, we've implicitly relied on good engineering practice and left
> out discussion of the timer associated with two-step RTM.
> 
> I agree with your observation and propose the following update to text
> 
> in section One-step Clock and two-step Clock Modes (added sentence
> underlined):
> 
> If the S bit is already set, then the RTM capable node MUST wait for the
> RTM message with the PTP type of follow-up and matching
> 
> originator and sequence number to make the corresponding residence time
> update to the Scratch Pad field.
> 
> *The wait period MUST be reasonably bound.*


Sounds good.


> 
> >
> > On page 12, last paragraph, we have some text "If no RTM_SET TLV has been
> > found, then the LSP setup MUST fail [...]".  Is this only in the case
> > when the RTM_SET flag is set?  If so, that should probably be made more
> > clear in the text, as on my first reading I was surprised, since
> > the RTM_SET generally goes in the LSP_ATTRIBUTES and not the
> > LSP_REQUIRED_ATTRIBUTES, and as such would not be globally mandatory.
> >
> GIM>> Earlier, in the same paragraph, we've said
> 
> "If the RTM_SET flag set, the node MUST inspect the LSP_ATTRIBUTES object
> for presence of RTM_SET TLV." ("Node" is used in place of "RTM-capable
> node")
> Thus nodes that are not RTM-capable would not act on RTM_SET Attribure
> Flag, would not be chacking for presence of RTM_SET TLV.


Okay.


> > I'm also left puzzled by the last paragraph of section 7; it seems to say
> > that the *last* RTM(-capable) node of the LSP will generate the follow-up
> > message, but I thought it was generally an earlier node that would be
> > setting the S bit and generating the follow-up message.
> >
> GIM>> Updated text as the following:
> 
>    The egress RTM-capable node of the LSP will be removing RTM
>    encapsulation and, in case of two-step clock mode being indicated,
>    will generate PTP messages as appropriate (according to the
>    [IEEE.1588.2008]).  In this case, the common header of the PTP packet
>    carrying the synchronization message would have to be modified in the
>    twoStepFlag field indicating that there is now a follow up message
> associated to that.

Ah, maybe I have un-confused myself.  This about the case where the
underlying PTP is a one-step clock, but the RTM path includes two-step
nodes, so the node that removes the RTM wrapper has to synthesize a
follow-up PTP message to contain the correction?

Making (A) and (B) fully fledged subsections would let them have
indicative tiles, like "Two-step RTM with two-step upstream" and
"Two-step RTM with one-step upstream".

In any case, I would suggest being more explicit than "the associated RTM
packet must be created" means, explicitly describing what type of RTM packet
is being created (i.e., the follow-up one?).


> > There are also a lot of grammar nits (including very many missing
> > instances of the definite article), but it does not seem worth enumerating
> > them here.  I will try to send a diff to the authors later this week,
> > but time is a bit short at the moment.
> >
> GIM>> Many thanks and greatly appreciate your kind help.

I guess it is lucky that I did not have time last week, since there is
an updated version that I could be basing changes onto.  (Things are still
busy for me, so no guarantees of anything.)

-Ben