Subject: [mpls] AD review of daft-ietf-mpls-loss-delay

From: Adrian Farrel <[email-masked]>
Date: Thu, 26 May 2011 12:20:43 +0100

Hi,

Don't panic!

I have performed my AD review of daft-ietf-mpls-loss-delay. The
purpose of the review is to catch any nits or issues before the
document goes forward to IETF last call and IESG review. By getting
these issues out at this stage we can hope for a higher quality 
review and a smoother passage through the process.

This is a good solid document: thanks!

I don't have any major technical issues with your draft. The intention
and solution are fine. However, I found a largish number of small
issues and questions. These are mainly concerns with clarity, although
I did have some more substantial concerns about the security section.

All of my comments are up for discussion, and you should not feel
rail-roaded into making changes. But I do think my comments need to be
addressed before this document goes to IETF last call.

I have moved the draft into "AD-review:Revised-ID-needed" state in
the datatracker, and I look forward to seeing the new revision which
I can put forward for IETF last call.

Thanks,
Adrian

---

Section 1

   o  The LM and DM protocols are applicable to the LSPs, pseudowires,
      and sections of networks based on the MPLS Transport Profile
      (MPLS-TP), because the MPLS-TP is based on a standard MPLS data
      plane.  The MPLS-TP is defined and described in [RFC5921], and
      MPLS-TP LSPs, pseudowires, and sections are discussed in detail in
      [RFC5960].

You should give an Informative forward reference to
draft-ietf-mpls-tp-loss-delay-profile.

---

Section 1

   o  The LM and DM protocols can be used for both continuous/proactive
      and selective/on-demand measurement.

s/for both/both for/

---

Section 2.3

This section on Throughput seems very thin.

In Section 2.4 you note:

   Measurement of the one-way delay quantities requires that the clocks
   of A and B be synchronized, whereas the two-way delay metrics can be
   measured directly even when this is not the case (provided A and B
   have stable clocks).

Doesn't the same logic apply to throughput measurement?

---

2.7.  Dyadic Measurement

It is so nice to see words used. But do you think that your readership
will really understand? And is this precisely the right word, anyway?
After all, it appears that you mean a specific limitation of a dyad to
the pair of ends.

You write:
   Consequently this document does not attempt to
   specify a dyadic operational mode.
Delete "attempt to"

---

2.9.11

   There are two significant timestamp formats in common use: the
   timestamp format of the Internet standard Network Time Protocol
   (NTP), described in [RFC5905], and the timestamp format used in the
   IEEE 1588 Precision Time Protocol (PTP) [IEEE1588].

Please avoid the word "standard" as RFC 5905 is not an Internet
Standard. Suggest you delete "Internet standard" without any loss of
meaning.

Can you please add to this section some text such as...

   To ensure interop it is necessary that support of at least one
   format is mandatory. This specification requires the support of
   the PTP format as discussed in Section 3.4 and Appendix A.

---

Section 3

   The message formats for direct and inferred LM are identical, as are
   the formats for the DLM+DM and ILM+DM messages.

A little care needed? I think you mean:

   The message formats for direct and inferred LM are identical. The
   formats for the DLM+DM and ILM+DM messages are identical.

---

Section 3.1

  Did you consider simply burning a new ACH type rather than including
  a version number field? Just idle curiosity...

---

Section 3.1

Control Code : Responses

This list starts off saying that the fields in the response either "MUST
NOT be used" or "do not contain valid measurement data". And then this
advice peters out in a way that might be inferred to mean that the data
*is* valid on other response codes. I think the turning point was when
you crossed the 0xf boundary, so you might simply say that for all
return codes > 0xf the data is not valid.

---

Section 3.1

   Message Length: Set to the total length of this message in bytes.

For the avoidance of doubt, it is usual to say "...including the
Version, Flags, Control Code, and Message Length fields."

I know one AD that will want you to say that the two-octet integer is
presented in line format.

---

Section 3.1

It wasn't clear to me until I read 3.4 that the timestamp field is
uniformly 64 bits. Could you add a note?

The way you have shown 8-byte quantities in the figure is slightly
unusual.

---

Sections 3.2 and 3.3
Some of the field description issues from 3.1 apply.

---

Section 3.4

   Implementations SHOULD also be capable of
   reading timestamps written in NTPv4 64-bit format and reconciling
   them internally with PTP timestamps for measurement purposes.
   Support for other timestamp formats is OPTIONAL.

Why is this "SHOULD" not "MUST"? It seems to me that unless you say
"MUST" you cannot achieve interoperability.

---

3.5

I am worried by two aspects of the parameter ranges defined here.

   Type           Definition
   -------------- ---------------------------------
   Mandatory
[snip]
   4-119          Reserved
   120-127        Implementation-specific usage

   Optional
[snip]
   131-247        Reserved
   248-255        Implementation-specific usage

1. s/Reserved/Unallocated/

2. Why so many (any!) implementation-specific TLVs.

Any changes need to be reflected in the IANA section.

---

3.5.1

   More than one padding object MAY be present, in which case they
   SHOULD be contiguous.  Padding objects SHOULD occur at the end of
   the TLV Block.  The Value field of a padding object is arbitrary.

Not sure what the point these two "SHOULD" statements is. The fact that
they are only "SHOULD" means that a parser must be able to process
variations.

---

Section 6 ends with the throw-away line:
   Authentication
   procedures can also be used to ensure that only queries from
   authorized devices are processed.

I assume you are referring to Access Lists rather than authentication
because there is no discussion here, or in Section 7, of any such
authentication procedure....

See my next comment about Section 7

---

Section 7

   If reception or
   alteration of performance-related data by unauthorized devices is an
   operational concern, authentication and/or encryption procedures
   should be used to ensure message integrity and confidentiality.  Such
   procedures are outside the scope of this document, but have general
   applicability to OAM protocols in MPLS networks.

There is no way you will get this through a review by anyone with
security clue! I understand that what you are saying is that we need a
generic solution to security for OAM and then you can shelter under that
umbrella, but what you have done is identified an attack vector, defined
it as a potential problem, and then left the protocol unprotected!

Unfortunately, this could easily turn into a blocking issue as currently
expressed.

My advice is:

1. Expand upon the text you have in this section to include a discussion
   of how modification, injection, or snooping is only possible from an
   on-path node (you would need to explain why). Go on to say that, in
   general, all LSRs within a domain share a common trust relationship
   such that malign or compromised LSRs are not considered a significant
   risk. Explain that this means that the security concerns only
   become apparent in multi-domain environments where it is less likely
   that end-to-end OAM is run.

2. Include a reference to draft-ietf-mpls-tp-security-framework for
   "an overview of security issues concerning OAM messages"

3. Include a forward reference to an I-D that has been started to give
   a solution to the security concerns. I think you are in a bit of a hole 
   and you may have to make the first version of this draft yourselves
  (before this I-D can go any further). Not a very comfortable situation.

Please note that I think this is the *least* we will get away with. If
I saw this coming up from a draft in another area and I was reviewing
it, I would probably push back quite hard to get the security details
properly worked out.