[mpls] Re: Working Group Last Call for draft-ietf-mpls-spring-lsp-ping-path-sid (was Re: Working Group Last Call on draft-xp-mpls-spring-lsp-ping-path-sid)

[Greg Mirsky <[e-mail]>]

Apologies, but I missed to note that I have the same concern with the
validation of the Headend in the SR Policy originated by BGP.

Regards,
Greg

On Mon, Aug 19, 2024 at 4:31 PM Greg Mirsky <[e-mail]> wrote:

> Dear All,
>
> I paused to arrange my concerns about the draft and put them in front of
> you more clearly. Below is what it came to:
>
>    - The purpose of Target FEC Stack TLV in LSP echo request, as I
>    understand it, is to verify consistency between the data plane and the
>    control plane view of the data plane. That is why the sender of an echo
>    request with Target FEC Stack TLV includes a sub-TLV that, from the
>    sender's perspective, sufficiently represents the control plane information
>    associated with the verifiable label.
>    - If the above is correct, I move to the next point. All sub-TLVs in
>    the Target FEC Stack TLV must be validated. The validation process is
>    sub-TLV-specific. This draft defines the validation process, using PCEP as
>    an example, as follows:
>
> *  Validate that the signaled headend, color, end-point,
>
> originator ASN, originator address, and discriminator
>
> defined in [I-D.ietf-pce-segment-routing-policy-cp]
>
> and [I-D.ietf-pce-sr-path-segment], for the PSID,
>
> matches with the corresponding fields in the received
>
> SR Candidate Path's PSID sub-TLV.
>
> Now, my question: What is meant as validation of Headend?
>
>    - The reason for my question above is that I cannot find that the
>    identity of the Headend is included in PCEP constructs defined for the
>    configuration of an SR Policy. Am I missing something in PCE-related
>    specifications, or must they be enhanced to convey the identity of the SR
>    Policy's Headend?
>    - There's a possible way to use information already available in the
>    IP-encapsulated echo request message and source IP address. Personally, I
>    would consider such a check a security measure rather than validation, but
>    how would validation work if no IP/UDP encapsulation of the echo request is
>    used?
>
> I hope that I made my concern more evident now. I welcome your comments
> and questions.
>
>
> Regards,
>
> Greg
>
>
> On Tue, Aug 6, 2024 at 10:13 AM Tarek Saad <[e-mail]> wrote:
>
>> Hi WG,
>>
>>
>>
>> I am correcting a mistake to reference to the WG adopted draft (as
>> opposed to the individual draft for the same document). Sorry for the
>> confusion.
>>
>>
>>
>> Regards,
>>
>> Tarek
>>
>>
>>
>> *From: *Tarek Saad <[e-mail]>
>>
>> *Date: *Tuesday, August 6, 2024 at 9:53 AM
>> *To: *[e-mail] <[e-mail]>
>> *Cc: *MPLS Working Chairs <[e-mail]>,
>> [e-mail] <
>> [e-mail]>
>> *Subject: *Working Group Last Call on
>> draft-xp-mpls-spring-lsp-ping-path-sid
>>
>> Dear WG,
>>
>>
>>
>> This email starts a two-week working group last call for
>> draft-ietf-mpls-spring-lsp-ping-path-sid
>> <https://datatracker.ietf.org/doc/draft-ietf-mpls-spring-lsp-ping-path-sid/>
>> .
>>
>>
>>
>> Please indicate your support or concern for this draft. If you are
>> opposed to the progression of the draft to RFC, please articulate your
>> concern. If you support it, please indicate that you have read the latest
>> version, and it is ready for publication in your opinion. As always, review
>> comments and nits are most welcome.
>>
>>
>>
>> Please send your comments to the mpls wg mailing list ([e-mail])
>>
>> If necessary, comments may be sent unidirectional to the WG chairs.
>>
>>
>>
>> Note, currently there are no IPR disclosures
>> <https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-xp-mpls-spring-lsp-ping-path-sid>
>> against this document.
>>
>>
>>
>> This poll runs until August 20, 2024.
>>
>>
>>
>> Thank you,
>>
>> Tarek (for the MPLS WG co-chairs)
>>
>>
>> _______________________________________________
>> mpls mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
>>
>