Subject: rtg-dir review: ross, russ: draft-ietf-mpls-lsp-ping-09.txt

From: Alex Zinin <[email-masked]>
Date: Wed, 1 Jun 2005 22:18:10 -0700

skill-specific: Ross (MPLS)
round-robin: Russ

This one is out of the MPLS WG, on its way to the IETF LC, which I'm
starting.

http://www.ietf.org/internet-drafts/draft-ietf-mpls-lsp-ping-09.txt

> Abstract
> 
>    This document describes a simple and efficient mechanism that can be
>    used to detect data plane failures in Multi-Protocol Label Switching
>    (MPLS) Label Switched Paths (LSPs).  There are two parts to this
>    document: information carried in an MPLS "echo request" and "echo
>    reply" for the purposes of fault detection and isolation; and
>    mechanisms for reliably sending the echo reply.

Thank you.
-- 
Alex
http://www.psg.com/~zinin

---

From: Ross Callon <[email-masked]>
Date: Thu, 02 Jun 2005 22:43:35 -0400

Okay. I can look at this.

When do you want the review?

thanks, Ross

---

From: Russ White <[email-masked]>
Date: Fri, 03 Jun 2005 09:11:16 -0400

>>   mechanisms for reliably sending the echo reply.

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."

==

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.

==

:-)

Russ

---

From: Alex Zinin <[email-masked]>
Date: Fri, 3 Jun 2005 12:17:37 -0700

Ross,

  Thanks. Within a week should be fine.

---

From: Alex Zinin <[email-masked]>
Date: Fri, 3 Jun 2005 12:19:17 -0700

Russ,

  Thanks for the review.
  How would you split your comments into substantial and minor/editorial?

Friday, June 3, 2005, 6:11:16 AM, Russ White wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1

> -----BEGIN PGP SIGNATURE-----
> Version: PGP Desktop 9.0.0 (Build 2001)

> iQA/AwUBQqBXAxEdu7FIVPTkEQLpiACaAnU7c8J1N18LHqhWCSG3Wp64ZZgAoJi4
> pBd5+izMGriKTbuSh5DfI3dM
> =pP5V
> -----END PGP SIGNATURE-----

---

From: Russ White <[email-masked]>
Date: Fri, 03 Jun 2005 15:31:09 -0400

>   How would you split your comments into substantial and minor/editorial?

I would say the comments about the formatting are just editorial, as 
well as the extra words, and such. The comment on using the AFI format 
could be viewed either way, as something that would make this 
substantially better, or just as a minor comment. I'd rather see it 
designed so it can be extended without worrying about going through the 
entire process again for each protocol, but....

:-)

Russ

- -- 
__________________________________
[email-masked] CCIE <>< Grace Alone

---

From: Ross Callon <[email-masked]>
Date: Mon, 13 Jun 2005 10:07:26 -0400

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.

Thanks, Ross

---

From: Alex Zinin <[email-masked]>
Date: Mon, 13 Jun 2005 23:34:33 -0700

Ross, Russ-

 Thanks for reviewing, guys. I'll send your comments to the WG cc'ing the
 rtg-dir.

 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.