Following up: comments on draft-ietf-mpls-lsp-ping

[Alex Zinin <zinin at psg.com>]

Loa, George:

We got some comments from the routing and general directorate on
this document. Please check them and let me know what you think
should be fixed. I added my commentary with "AZ" prefix.

-- 
Alex


From Russ White:

Technical:

  One general thought is that there are a lot of "IPv4" TLVs and "IPv6"
  TLVs. It seems like it would generalize better if they just replaced
  these with SFI encoding--to describe any address (not label), use the
  AFI, the length described in the AFI, and then the address. Prefix
  length might be problematic in this context, though, but it might be
  worth considering.

Editorial:

  3.2:

      A Target FEC Stack is a list of sub-TLVs.  The number of elements is
      determined by the looking at the sub-TLV length fields.

  "the looking at the..." should be "looking at the...."

  ==

  3.2.3

      The value has the format below.  The value fields are taken from
      [RFC3209, sections 4.6.1.1 and 4.6.2.1].

  Would it be better to just reference this RFC, rather than repeating the
  information? If 3209 is ever obsoleted, this repeat of the fields might
  cause a problem (?).

  ==

  3.2.4

      The value has the format below.  The value fields are taken from
      [RFC3209, sections 4.6.1.2 and 4.6.2.2].

  Same thing here.

  ==

  3.2.8

  "....unless explicitly asked by configuration to use the old TLV.

  "....unless manually configured to use this TLV."

  ==

From Ross Callon:

On the most part the document looks quite good. My one substantial
issue is the lack of a defined mechanism for authentication in
draft-ietf-mpls-lsp-ping-09.txt.

One point might be the computational cost of this: However, this would
seem to be just as much an issue for BFD, which is after all supposed
to be do-able at a very rapid rate and which does authentication. Also,
LSP Ping is potentially useful at an "interact with a human trying to
debug things" rate, which would imply that authentication should be fast
enough for at least this common case. Also, making authentication
work at a very high rate is an implementation issue, and is possible (at
least if planned for in future products).

The most obvious authentication methods (password, MD5, SHA1) are
defined for BFD (see section 6.6 of draft-ietf-bfd-base-02.txt), and probably
should also be available for LSP Ping.

Other points: The security considerations section does discuss
authentication. For example:
         "Authentication will help reduce the number of seemingly valid
         MPLS echo requests, and thus cut down the Denial of Service
         attacks;"

First of all, I don't see how you can state that authentication could
be used for this purpose, when there is no authentication defined.

Secondly, authentication only helps prevent DoS for those parts of
the system which are *after* the packets with bad authentication are
discarded. For whatever part of the system has to actually check the
authentication and discard bad packets, authentication can make
DoS *worse*, due to the fact that checking authentication itself
requires work. Whether this is a win or a loss for the specific case of
DoS attacks therefore depends upon a variety of details (such as
whether checking the authentication is done in software on a central
CPU, or is done in some sort of dedicated hardware). Possibly the
security section should explain this. Also there are other more clearly
positive advantages of authentication, such as preventing a hacker
from initiating a ping, which also might be worth discussing in the
security section.

AZ:

>  Ross, regarding lack of authentication per se, I can see how an argument
>  can be made that this is not worse than what the current IP ping/tracert
>  have. I does seem strange that the doc tells what the authentication can
>  do while there is none.

From David Black (gen-art):

  Background for those who may be unaware of GenART:

  GenART is the Area Review Team for the General Area of the IETF.
  We advise the General Area Director (i.e. the IETF/IESG chair) by
  providing more in depth reviews than he could do himself of documents
  that come up for final decision in IESG telechat.  I was selected
  as the GenART member to review this document.  Below is my review,
  which was written specifically with an eye to the GenART process, but
  since I believe that it will be useful to have these comments more
  widely distributed, others outside the GenART group are included.

  Review criteria for WG submissions: "Is this document a reasonable
  contribution to the area of Internet engineering which it covers? If
  not, what changes would make it so?"

  This review was requested as a consequence of IETF Last Call, and
  I apologize for it arriving after completion of the Last Call.  I
  recommend that this review be addressed before IESG discussion.

  This draft is on the right track but has open issues.

  Let me start by saying that I'm not an MPLS expert.  Based on the
  level of MPLS expertise that has been applied to this draft, I'm in
  no position to check or question the MPLS design aspects of this
  draft.

  The issues I'm concerned about are more global:

  (1) IP ping and traceroute are robust debugging tools because they
  are based on a simple underlying TTL mechanism, so that if a ping
  or traceroute packet goes off into a void, one can be reasonably
  confident that something in the data plane is broken close to where
  the packet vanished.  MPLS ping/traceroute is considerably more
  complex (40+ page draft).  That's not necessarily bad, as MPLS
  is a more complex entity and ping/traceroute for MPLS has to deal
  with a known weakness in IP ping/traceroute, namely that an IP TTL
  mechanism can't see what's going on inside a tunnel ... and MPLS is
  all about what are essentially tunnels.  On balance, I think having
  a rich mechanism capable of probing the myriad ways in which MPLS
  could malfunction is highly desirable, but ...

  ... this complexity carries a risk of fragility - if an arbitrarily
  complex MPLS ping packet goes off into a void in the absence of other
  information, it's not as obvious that the data plane is broken (vs.
  the MPLS ping/traceroute logic being broken, or a mistake having been
  made in formatting the packet) in contrast to the IP case.  OTOH,
  there are a number of fairly simple examples in the draft that lead
  me to believe that the richness of the MPLS mechanism can be used
  with complexity commensurate to the problem being investigated, and
  that one can start simple and gradually increase the complexity as
  ping/traceroute success/failure yields more information about where
  the problem is (and isn't).  Section 4 on Theory of Operation contains
  some useful info, but it's mostly a complete specification of all
  the possible operational details at full depth.

  A complementary "advice on usage" and/or "examples of usage"
  section giving advice and/or examples of how to start with something
  simple and step up to more complex ping/traceroute probes as one
  learns more would be useful.  This sort of discussion of how to
  organize pursuit of problems would be valuable to both implementers
  (indication of what basic portions of MPLS ping/traceroute really
  need to be robust) and operators (advice on effective usage of the
  functionality). I realize that I started by noticing the length
  of the draft, and am nonetheless asking for it to be longer, but
  I think this would help.

  (2) The security considerations section vaguely refers to
  "Authentication" in the abstract without saying what is to be
  authenticated and how.  The reference to "some mechanism devised
  or suggested by the RPSec WG" as the solution to these issues is
  not promising.  In practice, I would not expect ping/traceroute
  to be particularly sensitive traffic, and hence suspect that the
  rate limiting described in the security considerations section is
  much of what's needed, probably complemented by some discipline
  in who or what one connects one's MPLS systems to.  Unfortunately,
  as currently written, the security considerations section portrays
  authentication of a to-be-specified nature as the primary counter-
  measure.  I would expect a "Discuss" from at least the Security ADs
  if this isn't refocused on what can and should be done today (vs.
  what has yet to be invented/designed/specified).

AZ: it seems that we really need to fix the security section.
    my suggestion would be to change it to describe what the specification
    provides and what level of security that yields rather than theorize
    about what could be done potentially.
  
  Nit: This draft uses "TTL" to refer the MPLS TTL and "IP TTL"
  to refer to the TTL in the IP header.  That convention makes
  sense for an MPLS draft, but it should be stated in the
  conventions section, just in case the reader is not an MPLS
  expert.

  Thanks,
  --David