Subject: Re: [mpls] MPLS working group last call on draft-ietf-mpls-lsp-ping-relay-reply

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 5 Jun 2015 17:34:08 +0100

Hi,

Just being a good citizen and reviewing this I-D during WG last call.
I didn't have much time so I only found a number of nits most of which
are probably not significant.

Cheers,
Adrian

---

idnits notes the presence of a pre-RFC5378 disclaimer. Do you really 
need that?

---

Abstract

You expand "LSR" correctly, but not on first use.

---

Abstract

   a replying LSR may not have the available route to the
   initiator

s/the/an/

---

Section 1

You need to expand "LSR" on first use.

---

Section 1

   This document describes the extensions to the Label Switched Path
   (LSP) Ping as specified in [RFC4379], by adding a relayed echo reply
   mechanism which could be used to detect data plane failures for the
   inter autonomous system (AS) and inter-area LSPs. 

s/the extensions/extensions/
s/detect/report/ ???
s/for the/for/

---

Section 1

Delete "The extensions are to update the [RFC4379]." as it duplicates
the previous sentence.

---

Section 1

   may not have the available route

s/the/an/

---

Section 2

   LSP Ping [RFC4379] defines a mechanism to detect the data plane
   failures and localize faults. 

s/the data/data/

---

Section 2

OLD
   using an UDP packet with
   the IPv4/IPv6 address of the originating LSR
NEW
   using a UDP packet with
   the IPv4/IPv6 destination address set to an address of the
   LSR that originated the Echo Request.

---

Section 2

OLD
   IP addresses reachability are allowed
NEW
   IP address reachability is allowed

---

Section 2

OLD
   In fact, it
   is almost uniformly the case that in inter-AS scenarios, it is not
   allowed the distribution or direct routing to the IP addresses of any
   of the nodes other than the ASBR in another AS.
NEW
   In fact, it
   is almost always the case that in inter-AS scenarios the only node in
   one AS to which direct routing is allowed from the other AS is the 
   ASBR, and routing information from within one AS is not distributed 
   into another AS.

---

Section 2

   Figure 1 demonstrates a case where one LSP is set up between PE1 and

s/one/an/

---

Section 2

You should expand "AN" on first use.

---

Section 3

   A new TLV named Relay Node Address Stack TLV is defined in this
   document, to carry the IP addresses of the possible relay nodes for
   the replying LSR.

In what way are they "possible" relay nodes? The description of the
mechanism seems to say that these addresses must be used an in the
supplied order.

---

Section 3.1 and onwards

It would help IANA if you distinguished your two instances of "TBD" by
using "TBD1", "TBD2", and "TBD3".

---

Section 3.2

It looks to me that you intend that the address list can include 
addresses of mixed types (otherwise you would not need the address
type in each entry). However, your offset is provided as a counter
and that means that each time this list is processed, the list must
be walked from top down since each entry may be of a different length.
Thus, while the stack is optimized for stripping unwanted addresses 
from the end of the TLV, it is as suboptimal as you could have made it
for parsing because every node that processes the TLV must scan every
entry in the list.

Why not replace the count of addresses with a count of octets to enable
quicker access into the list?

---

Section 3.2

   K bit: if the K bit is set to 1, then this sub-TLV MUST be kept in
   Relay Node Address Stack during TLV compress process described in
   section 4.2.

The address stack entry is not a sub-TLV.

I am inferring from this text that set to 0 the K bit indicates that the
address stack entry can be kept in or left out at will, but actually 4.2
gives some considerably more complex rules for stripping or not 
stripping when k=0. Perhaps you need...

   K bit: if the K bit is set to 1, then this address stack entry MUST
   NOT be stripped from the Relay Node Address Stack during processing
   described in Section 4.2. If the K bit is clear, the entry might be
   stripped according to the processing described in Section 4.2.

---

Section 3.3 seems very "sudden". It doesn't seem to be related to this
document in particular. It is true that the presence of a Relay Node 
Address Stack TLV increases the size of the Echo Reply (or Relayed
Echo Reply) message, but presumably the problem with exceeding the
MTU is only exacerbated by, not caused by, this TLV.

Furthermore, section 3.3 talks about dropping TLVs (or sending them 
with length zero), but gives no hints about which should or can be 
dropped to get the MTU down to size. For example, dropping the Relay
Node Address Stack TLV would presumably be frowned upon.

Lastly, I cannot understand how the new return code is handled when
some other return code is also demanded.

Maybe there is text missing from section 4. All I could find was the
last paragraph of 4.2.

---

Section 4.1

   In addition to the procedures described in section 4.3 of [RFC4379],
   a Relay Node Address Stack TLV MUST be carried in the Echo Request
   message to facilitate the relay functionality.

This is ambiguous. The update to 4379 is not that the new TLV must be 
included in the echo request in order to facilitate the relay 
functionality. I think you mean that you have defined an optional TLV
that can be included in an echo request message to facilitate the relay
functionality, and that where that functionality is needed in order to
relay echo reply messages, the new TLV must be included in the echo
request message.

---

Section 4.1

   The source UDP port field MUST be set
   to the source UDP port.

There is no "source UDP port" field. Perhaps the "Initiator Source Port"
field?

But also, this text is quite confusing. The text in 3.2 is much clearer.

---

Section 4.1 appears to lack guidance about how to construct a Relay Node
Address Stack TLV to include in an Echo Request message. One may cross-
reference to 4.6 and then a lot becomes clear (including the processes 
in 4.2 that otherwise appear convoluted!).

I believe that what you have in mind is that before you can do end-to-
end LSP ping, you must perform a traceroute in order to collect and
construct the full Relay Node Address Stack TLV. Shouldn't the document
make this clear?

---

Section 4.2

   An LSR that does not recognize the Relay Node Address Stack TLV,
   SHOULD ignore it as per section 3 of [RFC4379].

You are not seeking to change 4379 behavior here, so using 2119 SHOULD
is confusing. Indeed, you cannot change legacy behavior in this 
document. 

I think you need...
                                                                
   The Type of the Relay Node Address Stack TLV is chosen from the range
   32768 to 49161 so that (per section 3 of [RFC4379]) an LSR that does
   not recognize the TLV knows that the TLV is optional and can safely
   ignore it.

---

I tried to work out how things would pan out if two ASes on the path 
used the same address space within their AS. Would an address appear in
the stack and seem to be routable when it is really an address in the
other AS?

---

4.3 has

   If the first IP address in the Relay Node Address Stack TLV is not
   the next relay node address

There are two questions that follow:
- You have a "SHOULD" to resolve this "if". What are the conditions for
  varying that behavior?
- You don't say what to do if this "if" is not satisfied. Presumably, in
  this case it sends an Echo Reply and you can address my question with
  a pointer to 4.5.

Similarly, 4.4 has:

   If the next relay node address is not the first one in the address
   list, i.e., another intermediate relay node, the relay node MUST send
   an Relayed Echo Reply message to the determined upstream node with
   the payload unchanged other than the Relay Node Address Stack TLV.

If this "if" does not hold, what does the implementation do? Again, a 
pointer to 4.5 may be enough.

---

The third case in 4.5 is when the receiver does not understand the TLV
and ignores it. In this case it will send an Echo Reply without itself
including the TLV.

---

Section 6 should note that the new TLV provides a way for Echo Reply
messages to be diverted so that information can be collected. For
example, if a stack entry can be inserted, the Echo Reply messages can
be caused to transit another AS unrelated to the LSP under test. Since
the Echo Reply reveals path information about the LSP, this is a
valuable attack.  Having said that, you can say how this TLV is 
protected in the Echo Reply message.
> -----Original Message-----
> From: mpls [mailto:[email-masked]] On Behalf Of Loa Andersson
> Sent: 27 May 2015 10:21
> To: [email-masked]; [email-masked]; draft-ietf-mpls-lsp-ping-relay-
> [email-masked]; BRUNGARD, DEBORAH A
> Subject: [mpls] MPLS working group last call on
draft-ietf-mpls-lsp-ping-relay-
> reply
> 
> Working Group,
> 
> This is to initiate a two week working group last call on
> draft-ietf-mpls-lsp-ping-relay-reply.
> 
> Please send your comments to the mpls wg mailing list ([email-masked]).
> 
> There are two IPR disclosures against this document. All the authors
> and contributors have stated on the working group mailing list that
> they are not aware of any other IPRs that relates to this draft.
> 
> This working group last call ends June 10, 2015.
> 
> A little bit of background. We requested publication for this draft
> earlier, but very late in the process it was discovered that the
> document needed more work - and it was returned to the working group.
> Document has been updated, and you can find a diff:
> 
> https://www.ietf.org/rfcdiff?url1=draft-ietf-mpls-lsp-ping-relay-reply-
> 05&url2=draft-ietf-mpls-lsp-ping-relay-reply-09
> 
> A discussion on the updates can be found at:
> http://www.ietf.org/proceedings/92/slides/slides-92-mpls-8.pdf
> 
> /Loa
> for the MPLS wg chairs
> --
> 
> 
> Loa Andersson                        email: [email-masked]
> Senior MPLS Expert                          [email-masked]
> Huawei Technologies (consultant)     phone: +46 739 81 21 64
> 
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls

---

From: "[email-masked]" <[email-masked]>
Date: Wed, 10 Jun 2015 00:09:45 +0800

Hi Adrian,
Thank you for the review. Please see my reply inline below. Correct me if other authors have different opinion.
I will update the draft after the end of last call.

Regards
Lizhong
 
From: Adrian Farrel
Date: 2015-06-06 00:34
To: 'Loa Andersson'; [email-masked]; [email-masked]; [email-masked]; 'BRUNGARD, DEBORAH A'
Subject: RE: [mpls] MPLS working group last call on draft-ietf-mpls-lsp-ping-relay-reply
Hi,

Cheers,
Adrian
 
---
 
idnits notes the presence of a pre-RFC5378 disclaimer. Do you really 
need that?
[Lizhong] this may need the answer from chairs and AD. We only follow the rules.
 
---
 
Abstract

You expand "LSR" correctly, but not on first use.
[Lizhong] Good catch, thanks.
 
---
 
Abstract

s/the/an/
[Lizhong] accept
 
---
 
Section 1
 
[Lizhong] accept
 
---
 
Section 1

[Lizhong] accept
 
---
 
Section 1
 
[Lizhong] accept
 
---
 
Section 1

s/the/an/
[Lizhong] accept
 
---
 
Section 2

s/the data/data/
[Lizhong] accept
 
---
 
Section 2
 
OLD
   using an UDP packet with
 [Lizhong] accept

---
 
Section 2
 
OLD
 [Lizhong] accept
---
 
Section 2
 
OLD
   In fact, it
 [Lizhong] accept
---
 
Section 2

s/one/an/
[Lizhong] accept
---
 
Section 2
 
 [Lizhong] accept
---
 
Section 3

In what way are they "possible" relay nodes? The description of the
mechanism seems to say that these addresses must be used an in the
supplied order.
[Lizhong] the word "possible" is not correctly used here. I will remove it.
 
---
 
Section 3.1 and onwards
 
 [Lizhong] accept
---
 
Section 3.2

Why not replace the count of addresses with a count of octets to enable
quicker access into the list?
[Lizhong] either is OK. George has same preferrence for octets. I will
change to octets number across the document.
 
---
 
Section 3.2

 
 
[Lizhong] accepted, much clear now.
 
---

Furthermore, section 3.3 talks about dropping TLVs (or sending them 
with length zero), but gives no hints about which should or can be 
dropped to get the MTU down to size. For example, dropping the Relay
Node Address Stack TLV would presumably be frowned upon.
[Lizhong] section 4.2 talks about this as below. How about to add a 
reference in section 3.3?
   If the full reply message would exceed the MTU size, the Relay Node
Address Stack TLV SHOULD be included in the Echo Reply message (i.e.,
other optional TLVs are excluded).
 
Lastly, I cannot understand how the new return code is handled when
some other return code is also demanded.
[Lizhong] I will add the following:
In section 4.4 of [RFC4379], step 7 will be updated. 
Before sending Echo Reply, the new packet size should be checked.
If Best-return-code is 3 ("Replying router is an egress for the FEC at stack depth"), 
or 8 ("Label switched at stack-depth"), and if the packet size exceeds MTU size, then
Best-return-code is TBD3 ("One or more TLVs not returned due to MTU size")

---
 
Section 4.1

[Lizhong] correct. Rephrased as below:
message if the relay functionality is required.
 
---
 
Section 4.1

 
But also, this text is quite confusing. The text in 3.2 is much clearer.
[Lizhong] yes, should be: 
The source UDP port field MUST be set to the initiator source port.
 
---
 
[Lizhong] accept, will add reference to 4.6.
 
I believe that what you have in mind is that before you can do end-to-
end LSP ping, you must perform a traceroute in order to collect and
construct the full Relay Node Address Stack TLV. Shouldn't the document
make this clear?
[Lizhong] traceroute is not mandatory before ping. If operator has knowledge 
of the relay nodes, the initiator could directly send ping with Relay Node 
Address Stack TLV containing the already known relay nodes.
 
---
 
Section 4.2

 
I think you need...
                                                                
[Lizhong] accept
 
---
 
I tried to work out how things would pan out if two ASes on the path 
used the same address space within their AS. Would an address appear in
the stack and seem to be routable when it is really an address in the
other AS?
[Lizhong] we have an example in section 5. And address of P1 and P2 could be 
same. In that case, ASBR1 must adds its interface address facing ASBR2 with 
the K bit set. Then relay reply will not be miss-routed.
 
---
 
4.3 has

There are two questions that follow:
- You have a "SHOULD" to resolve this "if". What are the conditions for
  varying that behavior?
- You don't say what to do if this "if" is not satisfied. Presumably, in
  this case it sends an Echo Reply and you can address my question with
  a pointer to 4.5.
[Lizhong] accept. Will add the following:
   When the next relay node address is the first one in the address 
list, please refer to section 4.5. 
 
Similarly, 4.4 has:

If this "if" does not hold, what does the implementation do? Again, a 
pointer to 4.5 may be enough.
[Lizhong] accept, will add the following:
   When the next relay node address is the first one in the address 
list, please refer to section 4.5. 
 
---
 
The third case in 4.5 is when the receiver does not understand the TLV
and ignores it. In this case it will send an Echo Reply without itself
including the TLV.
[Lizhong] the receiver is unable to send the Echo Reply, because it does
know the destination IP address and UDP port number. So if the receiver
could not understand the TLV, then the relay message will be dropped.
 
---
 
Section 6 should note that the new TLV provides a way for Echo Reply
messages to be diverted so that information can be collected. For
example, if a stack entry can be inserted, the Echo Reply messages can
be caused to transit another AS unrelated to the LSP under test. Since
the Echo Reply reveals path information about the LSP, this is a
valuable attack.  Having said that, you can say how this TLV is 
protected in the Echo Reply message.
[Lizhong] Do you mean the new TLV could be used to collect path information
unrelated to the LSP under test? This is not true. Only the node along the LSP 
will add path information into the new TLV. The relay node in the new TLV
will only relay the Echo Reply to the initiator, and will not add information to
the new TLV.

---

From: Loa Andersson <[email-masked]>
Date: Thu, 11 Jun 2015 11:19:27 +0200

Working group,

This wglc is closed. There are comments. Can the authors please address
the comments, close loops with the people making comments and make sure
that they are comfortable with how the comments are addressed.

After that post a new version of the document.

/Loa
mpls wg co-chair

On 2015-05-27 11:20, Loa Andersson wrote:
> https://www.ietf.org/rfcdiff?url1=draft-ietf-mpls-lsp-ping-relay-reply-05&url2=draft-ietf-mpls-lsp-ping-relay-reply-09
>
>

--

---

From: "[email-masked]" <[email-masked]>
Date: Wed, 17 Jun 2015 22:31:55 +0800

Hi George,
For Adrian's below comments related with MTU Exceeded Return Code, in the draft, it says: "The return sub-code MUST be set to the value that otherwise would have been sent". I tend to set the return sub-code to zero also. Since we have changed the return code, then it is meanless to retain the original sub-code. Any comments?

Regards
Lizhong
 
From: [email-masked]
Date: 2015-06-10 00:09
To: adrian; loa; mpls; mpls-chairs; draft-ietf-mpls-lsp-ping-relay-reply; db3546
Subject: RE: [mpls] MPLS working group last call on draft-ietf-mpls-lsp-ping-relay-reply
Hi Adrian,
Thank you for the review. Please see my reply inline below. Correct me if other authors have different opinion.
I will update the draft after the end of last call.

Regards
Lizhong
 
From: Adrian Farrel
Date: 2015-06-06 00:34

Cheers,
Adrian
 
---

---
 
Abstract

---
 
Abstract

s/the/an/
[Lizhong] accept
 
---
 
Section 1

---
 
Section 1

 
---
 
Section 1

---
 
Section 1

s/the/an/
[Lizhong] accept
 
---
 
Section 2

s/the data/data/
[Lizhong] accept
 
---
 
Section 2
 
OLD
   using an UDP packet with

---
 
Section 2
 
OLD
 
Section 2
 
OLD
   In fact, it
 
Section 2

s/one/an/
[Lizhong] accept
---
 
Section 2

Section 3

 
---
 
Section 3.1 and onwards

Section 3.2

 
---
 
Section 3.2

 

---

 

---
 
Section 4.1

 
---
 
Section 4.1

 
 
---

 
---
 
Section 4.2

 
I think you need...

---

---
 
4.3 has

 
Similarly, 4.4 has:

 
---

---

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 17 Jun 2015 19:28:01 +0100

Lizhong,

Apologies, I fumbled your response.

I snipped out the stuff we agree on.

>> [Lizhong] this may need the answer from chairs and AD. We only follow

If you are following the rules, that's fine. I think the rules are that you only
need to include the disclaimer if text included in the document was written
before the date of RFC 5378 and if at least one of the authors of the text has
not given up their copyright as described in that RFC.

[snip]

> The source UDP port field MUST be set to the initiator source port.

Hmmm, I think...

"The Initiator Source Port field MUST be set to the source UDP port."
 
[snip]
 
> Address Stack TLV containing the already known relay nodes.

That would make a valuable addition to 4.1, as well.

[snip]

> the K bit set. Then relay reply will not be miss-routed.

Ah, I get it.
But this relies on ASBT1 setting the K bit. 
So I suspect this needs to not be a special case: you need to require that the
domain boundary always sets the K bit.
 
[snip]
 
> could not understand the TLV, then the relay message will be dropped.

Section 4.5 of 4379 says:

   The destination IP address and UDP port are copied from the
   source IP address and UDP port of the echo request.

That is what the legacy receiver will attempt to do. It doesn't matter whether
the optional Relay Node Address Stack TLV is in the echo request message or not,
the legacy node will follow 4379. So it *will* be able to respond.

> will only relay the Echo Reply to the initiator, and will not add information
to

I think you misunderstand how security attacks might work. Suppose I am able to
do one of two things:
1. Modify the control plane code on a router that adds or processes a
    Relay Node Address Stack TLV so that it adds a bogus entry to the
     TLV. The prospect of modifications to control plane code is generally
     considered to be so disastrous that it is just noted without any 
     further precautions (after all, if you can get at the control plane
     code, you can make the routers do anything).
2. Intercept and modify a packet in transit. This is the main risk I am 
    talking about.

Cheers,
Adrian

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 18 Jun 2015 17:46:27 +0800

Hi Adrian,
Thanks for the reply. Please see inline below.

Regards
Lizhong
 
From: Adrian Farrel
Date: 2015-06-18 02:28
To: [email-masked]; 'loa'; 'mpls'; 'mpls-chairs'; 'draft-ietf-mpls-lsp-ping-relay-reply'; 'db3546'
Subject: RE: [mpls] MPLS working group last call on draft-ietf-mpls-lsp-ping-relay-reply
Lizhong,

 

 
[snip]

Hmmm, I think...
 
[Lizhong] accepted.
 
[snip]

That would make a valuable addition to 4.1, as well.
[Lizhong] OK, then we could add the following in section 4 to avoid misunderstanding:
In the following section, we describe the relay reply procedures with traceroute 
operation. If operator has knowledge of the relay nodes, the initiator could do LSP 
Ping by directly sending Echo Request with Relay Node Address Stack TLV 
containing the already known relay nodes.
 
[snip]

Ah, I get it.
But this relies on ASBT1 setting the K bit. 
So I suspect this needs to not be a special case: you need to require that the
domain boundary always sets the K bit.
[Lizhong] yes, we use "SHOULD" to make the requirement. See below description in section 4.2:
If a node spans two addressing domains (with respect to this 
message) where nodes on either side may not be able to reach nodes in the 
other domain, then the final address added SHOULD set the K bit.
 
[snip]

 
 
That is what the legacy receiver will attempt to do. It doesn't matter whether
the optional Relay Node Address Stack TLV is in the echo request message or not,
the legacy node will follow 4379. So it *will* be able to respond.
[Lizhong] Are you referring the case when the receiver receives Echo Request? In that
case, yes, it will respond without including the TLV. It is a sub-case of case 1. And I
will add the following in the first case:
If the receiver does not recognize the Relay Node Address Stack TLV, as per 
section 3 and 4.5 of [RFC4379], it will send an Echo Reply without including the TLV.
If you are referring the case when the receiver receives Relayed Echo Reply, if it could
not understand the TLV, it will also not understand the message type "Relayed Echo Reply".
So the packet will be dropped.

I think you misunderstand how security attacks might work. Suppose I am able to
do one of two things:
1. Modify the control plane code on a router that adds or processes a
    Relay Node Address Stack TLV so that it adds a bogus entry to the
     TLV. The prospect of modifications to control plane code is generally
     considered to be so disastrous that it is just noted without any 
     further precautions (after all, if you can get at the control plane
     code, you can make the routers do anything).
2. Intercept and modify a packet in transit. This is the main risk I am 
    talking about.
[Lizhong] If one router's control plane in the network is hijacked, it could send any 
information to the third party. It is a general problem. But I understand you concern.
I will add the following to try to mitigate your concern.
The Relay Node Address Stack TLV has the path information of the LSP, and 
such information may be maliciously used by any uncontrolled LSR/LER. We have
two ways to reduce the path information in the TLV:
1. it is recommended to clear the K bit in the relay address entry unless you have to.
2. it is encouraged to use NIL address entry to hide node information if possible.
 
Cheers,
Adrian

---

From: "George Swallow (swallow)" <[email-masked]>
Date: Tue, 23 Jun 2015 15:30:12 +0000

Lizhong -

If there's any text left from the original draft, then it belongs to
either me or Tom.  I hereby surrender my rights.

Tom?

George

On 6/17/15 2:28 PM, "Adrian Farrel" <[email-masked]> wrote:

>> unrelated to the LSP under test? This is not true. Only the node along
>>the
>LSP 
>> will only relay the Echo Reply to the initiator, and will not add
>>information
>to
>> the new TLV.
>

---

From: "George Swallow (swallow)" <[email-masked]>
Date: Tue, 23 Jun 2015 15:45:03 +0000

Lizhong, Adrian - 

Inline -

>not given up their copyright as described in that RFC.

GS> Sent mail giving up my rights.  Need to get Tom as well.
>"The Initiator Source Port field MUST be set to the source UDP port."

GS> Agree.
>That would make a valuable addition to 4.1, as well.

GS> Indeed.  One of the applications here is to trace only so that you can
successfully ping.
>domain boundary always sets the K bit.

GS>  I made such a change awhile back.  It got shot down on the list.
There was push back due to the requirement for topological awareness
within the LSP Ping module.

Adrian - If you want to try pushing back on that, would you send a message
to the list on just this topic and see if we can convince folks.

>the legacy node will follow 4379. So it *will* be able to respond.

GS> Adrian - what you say about what the receiver will do is spot on.
However, there is no guarantee that it will be routable back to the source

>2. Intercept and modify a packet in transit. This is the main risk I am

GS> This is a good thing to include.

Thanks for the review.

George

---

From: Loa Andersson <[email-masked]>
Date: Wed, 24 Jun 2015 10:32:42 +0200

George,

I sympathize with this, but as I recall it the current document is the
result of a merger between two earlier drafts:

draft-ietf-mpls-interas-lspping (first version posted  March 2007) and
that one goes back to draft-nadeau-mpls-interas-lspping (first version
posted July 2005).
and
draft-zj-mpls-lsp-ping-reply-relay (first version posted October 2011)

RFC 5378 was published Oct 2008, to be on the safe side any work that
pre-dates RFC 5378 should have the "pre-RFC5378 disclaimer". So draft-zj
is in the clear.

However, since both draft-ietf-mpls-interas-lspping and
draft-nadeau-mpls-interas-lspping predates RFC 5378, we need the
pre-RFC5378 disclaimer unless both authors of the two draft grant their
rights to the IETF trust. My straw man advice would be to try to remove
the pre-RFC5378 disclaimer based on statements from both authors.

George does so in the mail below.

Tom are you willing to do so also?

/Loa

--

---

From: thomas nadeau <[email-masked]>
Date: Wed, 24 Jun 2015 06:02:25 -0400

> On Jun 24, 2015, at 4:32 AM, Loa Andersson <[email-masked]> wrote:
> 
> George,
> 

yes i agree.

---

From: Loa Andersson <[email-masked]>
Date: Thu, 25 Jun 2015 09:47:30 +0200

Lizhong,

It should be safe to remove the pre-RFC5378 disclaimer. I will address
the issue in the shepherds write-up.

/Loa

--

---

From: "Lizhong Jin" <[email-masked]>
Date: Thu, 25 Jun 2015 15:52:29 +0800

Thank you all for the help. We will update accordingly in the next version.

Regards
Lizhong

> From: Loa Andersson [mailto:[email-masked]]
> Sent: 2015年6月25日 15:48
> To: thomas nadeau; [email-masked]
> Cc: George Swallow (swallow); [email-masked]; mpls; mpls-chairs;
> draft-ietf-mpls-lsp-ping-relay-reply; db3546
> Subject: Re: [mpls] MPLS working group last call on
> draft-ietf-mpls-lsp-ping-relay-reply
> 
> Lizhong,
> 
> It should be safe to remove the pre-RFC5378 disclaimer. I will address the
issue
> in the shepherds write-up.
> 
> /Loa
> 
> >> I sympathize with this, but as I recall it the current document is
> >> the result of a merger between two earlier drafts:
> >>
> >> draft-ietf-mpls-interas-lspping (first version posted  March 2007)
> >> and that one goes back to draft-nadeau-mpls-interas-lspping (first
> >> version posted July 2005).
> >> and
> >> pre-dates RFC 5378 should have the "pre-RFC5378 disclaimer". So
> >> draft-zj is in the clear.
> >>
> >> pre-RFC5378 disclaimer unless both authors of the two draft grant
> >> their rights to the IETF trust. My straw man advice would be to try
> >> to remove the pre-RFC5378 disclaimer based on statements from both
> authors.
> >>
> >>>>> Thank you for the review. Please see my reply inline below.
> >>>>> Correct me if other authors have different opinion.
> >>>>>
> >>>>>> I didn't have much time so I only found a number of nits most of
> >>>>>> which are probably not significant.
> >>>>>> ---
> >>>>>>
> >>>>>> idnits notes the presence of a pre-RFC5378 disclaimer. Do you
> >>>>>> really need that?
> >>>> If you are following the rules, that's fine. I think the rules are
> >>>> that you only need to include the disclaimer if text included in
> >>>> the document was written before the date of RFC 5378 and if at
> >>>> least one of the authors of the text has not given up their
> >>>> copyright as described in that RFC.
> >>>>
> >>>> [snip]
> >>>>
> >>>>>> Section 4.1
> >>>>>>
> >>>>> [Lizhong] traceroute is not mandatory before ping. If operator has
> >>>>> knowledge of the relay nodes, the initiator could directly send
> >>>>> ping with Relay Node Address Stack TLV containing the already
> >>>>> known relay nodes.
> >>>>
> >>>>>> I tried to work out how things would pan out if two ASes on the
> >>>>>> path used the same address space within their AS. Would an
> >>>>>> address appear in the stack and seem to be routable when it is
> >>>>>> really an address in the other AS?
> >>>>> [Lizhong] we have an example in section 5. And address of P1 and
> >>>>> P2 could be same. In that case, ASBR1 must adds its interface
> >>>>> address facing ASBR2 with the K bit set. Then relay reply will not
> >>>>> be miss-routed.
> >>>>
> >>>> Ah, I get it.
> >>>> So I suspect this needs to not be a special case: you need to
> >>>> require that the domain boundary always sets the K bit.
> >>>>
> >>>> [snip]
> >>>>
> >>>>>> The third case in 4.5 is when the receiver does not understand
> >>>>>> the TLV and ignores it. In this case it will send an Echo Reply
> >>>>>> without itself including the TLV.
> >>>>> [Lizhong] the receiver is unable to send the Echo Reply, because
> >>>>> it does know the destination IP address and UDP port number. So if
> >>>>> the receiver could not understand the TLV, then the relay message
will
> be dropped.
> >>>> That is what the legacy receiver will attempt to do. It doesn't
> >>>> matter whether the optional Relay Node Address Stack TLV is in the
> >>>> echo request message or not, the legacy node will follow 4379. So
> >>>> it *will* be able to respond.
> >>>>
> >>>>>> Section 6 should note that the new TLV provides a way for Echo
> >>>>>> Reply messages to be diverted so that information can be
> >>>>>> collected. For example, if a stack entry can be inserted, the
> >>>>>> Echo Reply messages can be caused to transit another AS unrelated
> >>>>>> to the LSP under test. Since the Echo Reply reveals path
> >>>>>> information about the LSP, this is a valuable attack.  Having
> >>>>>> said that, you can say how this TLV is protected in the Echo Reply
> message.
> >>>>>
> >>>>> [Lizhong] Do you mean the new TLV could be used to collect path
> >>>>> information unrelated to the LSP under test? This is not true.
> >>>>> Only the node along the
> >>>> LSP
> >>>>> will add path information into the new TLV. The relay node in the
> >>>>> new TLV will only relay the Echo Reply to the initiator, and will
> >>>>> not add information
> >>>> to
> >>>>> the new TLV.
> >>>>
> >>>> I think you misunderstand how security attacks might work. Suppose
> >>>> I am able to do one of two things:

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 30 Jun 2015 12:30:42 +0100

I'm fine with all this. Thanks.
 
See follow-up to catch one of George's points.
 
Adrian
 
From: [email-masked] [mailto:[email-masked]] 
Sent: 18 June 2015 10:46
To: adrian; loa; mpls; mpls-chairs; draft-ietf-mpls-lsp-ping-relay-reply; db3546
Subject: Re: [mpls] MPLS working group last call on draft-ietf-mpls-lsp-ping-relay-reply
 
Hi Adrian,
 
  _____  

Regards
Lizhong
 
From: Adrian Farrel <mailto:[email-masked]> 
Date: 2015-06-18 02:28
To: [email-masked]; 'loa' <mailto:[email-masked]> ; 'mpls' <mailto:[email-masked]> ; 'mpls-chairs' <mailto:[email-masked]> ; 'draft-ietf-mpls-lsp-ping-relay-reply' <mailto:[email-masked]> ; 'db3546' <mailto:[email-masked]> 
Subject: RE: [mpls] MPLS working group last call on draft-ietf-mpls-lsp-ping-relay-reply
Lizhong,

 

 
[snip]

Hmmm, I think...

[snip]

 
[snip]

Ah, I get it.
 
[snip]

 

 
 
Cheers,
Adrian

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 30 Jun 2015 12:35:42 +0100

Thanks George,

[snip]

> >> [Lizhong] we have an example in section 5. And address of P1 and P2
> >> could be same. In that case, ASBR1 must add its interface address
> >> facing ASBR2 with the K bit set. Then relay reply will not be miss-routed.
> >
> >Ah, I get it.
> >So I suspect this needs to not be a special case: you need to require
> >that the domain boundary always sets the K bit.
> 

Consider this to be the push-back! :-)

It seems that the domain boundary (probably just an ASBR?) either has to know
that some other domain in the path is using the same address space as it is
using, or it has to know that it is an ASBR. Without applying the K bit for one
of these criteria, the mechanism is broken.

I suggest that the former is hard to know, but the latter is easy and can be
injected into the "LSP Ping module". This is NOT topological awareness since it
does not do harm to have extra K bits set, so in the relatively rare case of an
ASBR being on the path of an LSP that does not actually exit the AS, no harm
will be done.

The authors may want to ask the chairs how they establish whether there is WG
agreement on this point.

Cheers,
Adrian