Re: [ippm] John Scudder's Discuss on draft-ietf-ippm-stamp-srpm-13: (with DISCUSS and COMMENT)

[Rakesh Gandhi <[e-mail]>]

Thank you John for your comments on this.

We can remove the following sentence from the security section.
 "The usage of STAMP extensions defined in this document is intended for
deployment in SR domains [RFC8402]. "

Does that address your concern?

thanks,
Rakesh


On Thu, Jun 29, 2023 at 4:08 PM John Scudder <[e-mail]> wrote:

> Hi Rakesh,
>
> Version 15 addresses many of my concerns, thank you. I think this point
> was dropped though:
>
> > On Jun 22, 2023, at 1:09 PM, John Scudder <[e-mail]> wrote:
> >
> > In looking over the new version, it occurred to me that although the
> document is called “... for Segment Routing Networks” and although that was
> the use case that motivated it, the only elements whose applicability
> actually is limited to SR are the Return Path SR-MPLS Segment-List Sub-TLV
> and the Return Path SRv6 Segment-List Sub-TLV. All the rest are generically
> applicable. This is basically a good thing IMO — one likes to see specs
> whose applicability is greater than just the use case that led to their
> development — but it does mean that "The usage of STAMP protocol is
> intended for deployment in SR domains [RFC8402]” isn't sufficient, I’m
> afraid — whether the use case that led to the development was restricted to
> SR or not, one can easily see how (for example) a Return Address Sub-TLV
> could be used outside of an SR deployment. That use might be by design, or
> it might be by an attacker.
>
> That’s understandable, we were focused on the other aspect of the DISCUSS
> for some time and it’s easy to lose track of the threads.
>
> To repeat the concern in different words: You’ve rewritten the first
> paragraph of the Security Considerations as
>
>    The usage of STAMP extensions defined in this document is intended
>    for deployment in SR domains [RFC8402].  It is assumed that a node
>    involved in STAMP protocol operation has previously verified the
>    integrity of the path and the identity of the far-end Session-
>    Reflector.
>
> This eliminates the reliance on the Limited Domains RFC (good) but you’re
> improperly (I think) assuming that you can rely on the SR domain definition
> instead. This is still true even though you changed “STAMP protocol” (the
> version I commented on in the quote above) to “STAMP extensions”. Again, to
> repeat: I don’t think it’s either reasonable or desirable to restrict the
> extensions you’ve defined to be only for use in an SR domain, and
> therefore, I think the SecCons can’t rest on the foundation of the SR
> document set. If you did want to rest on that foundation, I think you would
> have to be much more prescriptive about saying the extensions MUST NOT be
> processed other than in an SR context (that’s probably not the right
> wording) — but I think that would be undesirable, and I think if you did
> want to make that change, it would be a pretty fundamental change requiring
> a new WGLC.
>
> I’ll re-review your other text and reply again if there are any other
> lingering issues. Then I’ll update my DISCUSS to clarify that the above is
> the outstanding point.
>
> Thanks,
>
> —John
>
> > On Jun 22, 2023, at 6:12 PM, Rakesh Gandhi <[e-mail]>
> wrote:
> >
> >
> > Thank you John for the review.
> > I have incorporated your suggestions in the following version:
> >
> > URL:
> https://www.ietf.org/archive/id/draft-ietf-ippm-stamp-srpm-15.txt
> > Html:
> https://www.ietf.org/archive/id/draft-ietf-ippm-stamp-srpm-15.html
> > Diff:
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-ippm-stamp-srpm-15
> >
> > Thanks for your help.
> >
> > Regards,
> > Rakesh
> >
> >
> >
> >
> > On Thu, Jun 22, 2023 at 4:36 PM John Scudder <[e-mail]> wrote:
> > [snipped extraneous stuff]
> >
> > > On Jun 22, 2023, at 2:40 PM, Rakesh Gandhi <[e-mail]>
> wrote:
> > >
> > > <RG> In the example, the DA in the STAMP Session-Sender test packet
> IPv4 header (127.0.0.1) does not match the address of the Session-Reflector
> which is 1.1.1.2.
> >
> > We seem to be talking across each other. I guess maybe I am
> misunderstanding what you mean by “the Session-Reflector”. Surely, “the
> Session-Reflector” must mean a node functioning as a Session-Reflector?
> This is strongly implied by the name of the TLV, “Destination _Node_
> Address” (emphasis added). To repeat, any given IP node has many addresses
> (well, at least two, of which loopback will be one). So it doesn’t make
> sense to talk about “the” (singular) “address of the Session-Reflector”,
> and 127.0.0.1 most certainly is one address of the Session-Reflector node.
> Indeed, if it weren’t an address of every Session-Reflector node, the
> problem you illustrate wouldn’t exist.
> >
> > (In a previous version of this reply I went through a hair-splitting
> exercise where I tried to entertain the idea that “the Session-Reflector”
> means “a process on the node, which is bound to one and only one address”
> but that’s not a readily-supported interpretation, and it led me to a long
> and tortured chain of reasoning… which ended up at the same conclusion
> anyway.)
> >
> > If this is still unclear, it might be beneficial for us to schedule a
> short call to discuss further. But perhaps my OLD/NEW text below will help.
> >
> > > <RG> In the following example (without Destination Address TLV), if
> LSP or forwarding path is broken, the STAMP packet may be punted on an
> unintended Reflector node (let's say 1.1.1.9) and it will send a reply
> STAMP test packet. Such errors can not be easily detected.
> > >
> > > MPLS Header
> > >      Label: 16001
> > >      Label: 16002 [EOS]
> > > IPv4 Header
> > >      SA: 1.1.1.1
> > >      DA: 127.0.0.1
> > > UDP header
> > > STAMP PAYLOAD
> >
> > Yes, I understand that. My point, again, is that your words say that
> 127.0.0.1 is not an address of the node. It ABSOLUTELY IS an address of
> essentially every IPv4 node in the universe.
> >
> > > <RG> Destination Address TLV carrying the intended Session-Reflector
> address of 1.1.1.2 helps detect this error. Using 1.1.1.2 then as the SA of
> the reply test packet is also good (instead of 127.0.0.1).
> >
> > I get that, too.
> >
> > > <RG> Does this use-case help? Will reply to the other comments below
> once we progress the above comment.
> >
> > I guess I will just jump ahead and outline some text that I *think* is
> right and that would address my concern.
> >
> > OLD:
> >    The Session-Sender may need to transmit test packets to the Session-
> >    Reflector with a destination address that is not matching the address
> >    of the Session-Reflector e.g. when the STAMP test packet is
> >    encapsulated by a tunneling protocol.  Examples are, STAMP test
> >    packets encapsulated with an SR-MPLS Segment List and IPv4 header
> >    containing destination IPv4 address from 127/8 range or STAMP test
> >    packets encapsulated with outer IPv6 header and Segment Routing
> >    Header (SRH) with inner IPv6 header containing IPv6 destination IPv6
> >    address ::1/128.
> >
> >    In an ECMP environment, the hashing function in forwarding may decide
> >    the outgoing path using the source address, destination address, UDP
> >    ports, IPv6 flow-label, etc. from the packet.  Hence for IPv4, for
> >    example, different values of IPv4 destination address from 127/8
> >    range may be used in the IPv4 header of the STAMP test packets to
> >    measure different ECMP paths.  For IPv6, for example, different
> >    values of flow-label may be used in the IPv6 header of the STAMP test
> >    packets to measure different ECMP paths.  In those cases, the STAMP
> >    test packets may reach the node that is not the Session-Reflector for
> >    this STAMP session in an error condition, and an un-intended node may
> >    transmit reply test packet that can result in reporting of invalid
> >    measurement metrics.
> >
> > NEW:
> >    The Session-Sender may need to transmit test packets to the Session-
> >    Reflector with a destination address that is not a routable (i.e.,
> >    suitable for use as the Source Address of the reply test packet)
> >    address of the Session-Reflector. This can be facilitated, for
> example,
> >    by encapsulating the STAMP packet by a tunneling protocol, see <xref>
> >    for a worked example.
> >
> > Then, if you wish, take the use case text I removed in my NEW version
> and use it as the basis of a Section 3.1 or Appendix A (the target of the
> xref I stubbed in above).
> >
> > It seems to me the following would be a good change as well:
> >
> > OLD:
> >    The Destination Node Address TLV indicates an address of the intended
> >    Session-Reflector node of the test packet.  The Destination Node
> >    Address is also used to uniquely identify the STAMP session on the
> >    Session-Reflector when the optional SSID is not sent.  If the
> >    received Destination Node Address is one of the addresses of the
> >    Session-Reflector, it SHOULD be used as the Source Address in the IP
> >    header of the reply test packet.
> >
> > NEW:
> >    The Destination Node Address TLV indicates an address of the intended
> >    Session-Reflector node of the test packet.  If the received
> >    Destination Node Address is one of the addresses of the
> >    Session-Reflector, it SHOULD be used as the Source Address in the IP
> >    header of the reply test packet.
> >
> >    If the Destination Node Address TLV is sent, the SSID TLV MUST also
> >    be sent.
> >
> > This lets you get rid of the “is also used to” which muddies the water.
> I don’t insist on this, it’s just a suggestion, the old way isn’t broken,
> just weird (to me).
> >
> > —John
>
>