Subject: [mpls] Comment on draft-ietf-mpls-return-path-specified-lsp-ping-04

From: Sriganesh Kini <[email-masked]>
Date: Mon, 28 Nov 2011 15:34:51 -0800

Hi,

Some comments -

First of all I don't buy this argument that it "MAY" be applicable to
MPLS-TP (as stated by Mach in another email thread). Either it is, or
it is not, it should be stated clearly. I don't see a strong reason
why this should not be applicable.
sec 3.3 - What if tunnel is static and not signaled ?
sec 3.3.1, 3.3.2 - I would suggest that we derive the RP tunnel ID
from the Tunnel ID as defined in RFC 6370. That should handle the
static case as well.
sec 3.3.3 - Is RP TC sub-TLV applicable when RP TLV is not present but
echo-response is being sent over a LSP (i.e. an LSP chosen by egress
but not explicitly requested by ingress).
sec 4.2 - What does a LSR do when it sees the new reply-mode (and
understands it) but is not the egress of the LSP. Does it reply with
an error code ? Or does it silently drop the packet ?
sec 4.3 - If a routable IP network is not present how is source address chosen ?
sec 4.3 - Value to be set for MPLS TTL must be specified.
sec 5 - The security attack by "proxying" still seems possible when
the label on the last hop is NULL. Verifying return path solely using
an address would not avoid all possible attacks. Strict authentication
would still be needed.
sec 6.2.1 - Is explicitly identifying the setup protocol RSVP required
? If we remove that, the static case could be wrapped in.
Generic comment - What if tunnel is P2MP ?

Editorial nits -
sec 6.2.2 - "from the" is repeated twice

-- 
- Sri

---

From: Mach Chen <[email-masked]>
Date: Tue, 29 Nov 2011 09:30:55 +0000

Hi Sri,

Many thanks for your comments!

Please see my reply inline...
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Sriganesh Kini
> Sent: Tuesday, November 29, 2011 7:35 AM
> To: [email-masked]; [email-masked]
> Subject: [mpls] Comment on draft-ietf-mpls-return-path-specified-lsp-ping-04
> 
> Hi,
> 
> Some comments -
> 

The draft is originally designed for IP/MPLS network, and theoretically, as you said, the idea can apply to MPLS-TP as well, but some extensions and updates are needed to cover MPLS-TP scenarios. That's the main reason why I said "MAY".

I am OK to extend the draft to cover MPLS-TP if there is no objection from the WG.

> sec 3.3 - What if tunnel is static and not signaled ?

Then the sub-TLVs defined in RFC6426 will be used, which are designed for static LSP and PW.

> from the Tunnel ID as defined in RFC 6370. That should handle the

If MPLS-TP is in scope, then it should be as you suggested. 

> but not explicitly requested by ingress).

RP TC sub-TLV is carried in RP TLV, and if the "reply via specified path" mode is used, RP TLV must be carried in either echo request or echo reply. 
If the RP TLV is not present, there will be no RP TC sub-TLV, so the RP TC sub-TLV can not apply to the scenario your described.

> an error code ? Or does it silently drop the packet ?

This should be a typical CV error, and there will be an error code(e.g., return code 3 - Replying router is an egress for the FEC at stack-depth <RSC>) returned if there is a return path, the related procedures defined in RFC4379 will be inherited here. If there is no return path, it should drop the packet.

> sec 4.3 - If a routable IP network is not present how is source address chosen ?

This is also related to MPLS-TP scenario, the current text does not cover this. And also, if MPLS-TP is in scope, some Non-IP-based encapsulation should be defined.   

> sec 4.3 - Value to be set for MPLS TTL must be specified.

Why does it need to specify the TLL? Could you please elaborate the scenario?

> an address would not avoid all possible attacks. Strict authentication

Yes, there are also some other comments about the security consideration, the authors will think over the comments and improve it in the next revision 

> ? If we remove that, the static case could be wrapped in.

Yes, if MPLS-TP is in scope.

> Generic comment - What if tunnel is P2MP ?

The P2MP is out of scope :-)

> sec 6.2.2 - "from the" is repeated twice

Good catch! Will fix it in next revision.

Many thanks,
Mach

> 
> --
> - Sri
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls

---

From: Sriganesh Kini <[email-masked]>
Date: Tue, 29 Nov 2011 11:29:33 -0800

Mach, see inline.

On Tuesday, November 29, 2011, Mach Chen <[email-masked]> wrote:
>> To: [email-masked];
[email-masked]
>> Subject: [mpls] Comment on
draft-ietf-mpls-return-path-specified-lsp-ping-04
> The draft is originally designed for IP/MPLS network, and theoretically,
as you said, the idea can apply to MPLS-TP as well, but some extensions and
updates are needed to cover MPLS-TP scenarios. That's the main reason why I
said "MAY".

IMO it must include TP since lsp ping is a tool used in TP.

> Then the sub-TLVs defined in RFC6426 will be used, which are designed for
static LSP and PW.

Pls update the draft. When will static pw sub TLV be used ?

> If MPLS-TP is in scope, then it should be as you suggested.

Ok.

> RP TC sub-TLV is carried in RP TLV, and if the "reply via specified path"
mode is used, RP TLV must be carried in either echo request or echo reply.
> If the RP TLV is not present, there will be no RP TC sub-TLV, so the RP
TC sub-TLV can not apply to the scenario your described.

My point was whether RP TC sub TLV should be made a TLV instead. It's value
seems to be useful whenever the reply path is a LSP independent of whether
the ping originator has requested the reply via a specific tunnel.

> This should be a typical CV error, and there will be an error code(e.g.,
return code 3 - Replying router is an egress for the FEC at stack-depth
<RSC>) returned if there is a return path, the related procedures defined
in RFC4379 will be inherited here. If there is no return path, it should
drop the packet.

Thinking some more on this is it really necessary to special case this ? If
the trace route mode of rfc 4379 is used as-is and the RP TLV applies to
the node at which TTL expired shouldn't it work ?

> This is also related to MPLS-TP scenario, the current text does not cover
this. And also, if MPLS-TP is in scope, some Non-IP-based encapsulation
should be defined.
> Why does it need to specify the TLL? Could you please elaborate the
scenario?

We don't want implementations to guess the value of TTL. It should be 255
but the draft should explicitly state it. Similar to rfc 4379 specifying IP
TTL value when using IP for echo reply.

> Yes, there are also some other comments about the security consideration,
the authors will think over the comments and improve it in the next revision
> Yes, if MPLS-TP is in scope.

Independent of whether TP is in scope this should be addressed.

> The P2MP is out of scope :-)

P2MP lsp ping is an RFC. Why would that be out of scope ?

-- 
Sriganesh Kini (Sri)