Re: [ippm] WGLC for STAMP Extensions

[Greg Mirsky <[e-mail]>]

Hi Rakesh,
thank you for your quick response. Below is the text proposed in the update:
   Before a test session commenced, a Session-Reflector MUST be
   provisioned with all the elements that identify the STAMP Session.  A
   STAMP Session-Reflector MUST discard the non-matching STAMP test
   packet(s).  The means of provisioning the STAMP Session
   identification is outside the scope of this specification.
The intention of the update is to point to the need to use the management
or control plane to provision a STAMP session on the Session-Reflector. At
the same time, the text does not specify which of the informational
elements be provisioned to the explicit values and which may use a
wildcard. If you have concerns with the update, could you please suggest
modifications or propose an alternative?

Regards,
Greg

On Thu, Jun 11, 2020 at 7:28 AM Rakesh Gandhi (rgandhi) <[e-mail]>
wrote:

> Hi Greg,
>
> The current (OLD) text in the document looks good to me.
>
> P.S. The goal for STAMP (with Simple) is to simplify such things when
> compared to TWAMP (RFC 5357).
>
>
>
> Thanks,
>
> Rakesh
>
>
>
>
>
> *From: *ippm <[e-mail]> on behalf of Greg Mirsky <
> [e-mail]>
> *Date: *Thursday, June 11, 2020 at 10:21 AM
> *To: *Rakesh Gandhi <[e-mail]>
> *Cc: *"MORTON, ALFRED C (AL)" <[e-mail]>, Ian Swett <ianswett=
> [e-mail]>, "IETF IPPM WG ([e-mail])" <
> [e-mail]>
> *Subject: *Re: [ippm] WGLC for STAMP Extensions
>
>
>
> Hi Rakesh,
>
> I agree with your scenario. Do you feel that the document, including the
> updated text, precludes it? Would you suggest text clarifications?
>
>
>
> Regards,
>
> Greg
>
>
>
> On Thu, Jun 11, 2020 at 7:13 AM Rakesh Gandhi <[e-mail]>
> wrote:
>
> Thanks Greg.
>
> SSID can be internally generated by the sender node. Expecting sender node
> to communicate this to the controller and then to the reflector node for
> *each* session may be overkill.
>
>
>
> The destination UDP port to use on the reflector node is already
> provisioned value and not any arbitrary port can be used anyways. So that
> should help with such issues.
>
>
>
> My 2c.
>
>
>
> Thanks,
>
> Rakesh
>
>
>
>
>
>
>
> On Wed, Jun 10, 2020 at 9:32 PM Greg Mirsky <[e-mail]> wrote:
>
> Hi Rakesh,
>
> as Al clarified, and I agree with this scenario, a Session-Reflector must
> be provisioned with a session identifier (some elements, I think, might be
> specified as a wild card) before the session is commenced. All test packets
> that do not match the provisioned identifier must be discarded without
> processing. I've tried to capture that in the latest update sent earlier.
>
> What do you think of this scenario?
>
>
>
> Regards,
>
> Greg
>
>
>
> On Wed, Jun 10, 2020 at 4:36 PM Rakesh Gandhi <[e-mail]>
> wrote:
>
> Hi Greg, Al,
>
> I am not sure if I follow the scenario.
>
> Between nodes A and B, there can be more than one STAMP sessions, e.g.
> {Node-A, Node-B, Src-Port-1, Dst-Port-1, SSID1} and {Node-A, Node-B,
> Src-Port-1, Dst-Port-1, SSID2}. I assume this is allowed? If yes, how do we
> know when there is now a third session between them with SSID3 (with same 4
> tuple), it is a change (from SSID1 or SSID2?) or a new third session?
>
> Thanks,
>
> Rakesh
>
>
>
>
>
>
>
>
>
> On Wed, Jun 10, 2020 at 7:21 PM Greg Mirsky <[e-mail]> wrote:
>
> Hi Al,
>
> many thanks for your quick response, much appreciated. We'll need some
> more time to discuss your suggestion related to the Access Report TLV. I've
> front-copied the other open issue and added my notes under the tag GIM2>>
> below.
>
>
>
>    An implementation of STAMP Session-Reflector that supports this
>
>    specification SHOULD identify a STAMP Session using the SSID in
>
>    combination with elements of the usual 4-tuple
>
> [acm] <insert> for the session. If the Session-Reflector finds that
>
> the SSID and 4-tuple combination changes during a test session, then
>
> the Session-Reflector MUST discard the non-matching packet(s) and take
>
> no further action on them.
>
>    .  A conforming...
>
> GIM>> We've discussed the scenario and couldn't define how a
> Session-Reflector can distinguish between a new STAMP test session and the
> event of a change in identifiers, i.e., SSID and 4-tuple of the ongoing
> test session. Could you kindly help us here?
>
>
>
> *[acm] Thanks, I’m surprised that a new test session (with new SSID) can
> begin without any Session-Reflector agreement or communication from the
> Session-Reflector’s management interface. Since the Sending address and
> port could be spoofed, Session-Reflectors could receive lots of unexpected
> traffic, if you know what I mean.....*
>
> GIM2>> Thank you for the clarification. I was not thinking out of a box.
> Please review the proposed new text below. I hope it captures the scenario
> you've pointed out.
>
> OLD TEXT:
>
>    An implementation of STAMP Session-Reflector that supports this
>    specification SHOULD identify a STAMP Session using the SSID in
>    combination with elements of the usual 4-tuple for the session.  A
>    conforming implementation of STAMP Session-Reflector MUST copy the
>    SSID value from the received test packet and put it into the
>    reflected packet, as displayed in Figure 2.
>
> NEW TEXT:
>
>    An implementation of STAMP Session-Reflector that supports this
>    specification SHOULD identify a STAMP Session using the SSID in
>    combination with elements of the usual 4-tuple for the session.
>    Before a test session commenced, a Session-Reflector MUST be
>    provisioned with all the elements that identify the STAMP Session.  A
>    STAMP Session-Reflector MUST discard the non-matching STAMP test
>    packet(s).  The means of provisioning the STAMP Session
>    identification is outside the scope of this specification.  A
>    conforming implementation of STAMP Session-Reflector MUST copy the
>    SSID value from the received test packet and put it into the
>    reflected packet, as displayed in Figure 2.
>
>
>
> Would the new text address your concern?
>
>
>
> Regards,
>
> Greg
>
>
>
>
>
> On Wed, Jun 10, 2020 at 8:01 AM MORTON, ALFRED C (AL) <
> [e-mail]> wrote:
>
> Hi Greg, Thanks for all replies.
>
> Let’s concentrate on those needing some additional thought...
>
> Al
>
>
>
>
>
>    An implementation of STAMP Session-Reflector that supports this
>
>    specification SHOULD identify a STAMP Session using the SSID in
>
>    combination with elements of the usual 4-tuple
>
> [acm] <insert> for the session. If the Session-Reflector finds that
>
> the SSID and 4-tuple combination changes during a test session, then
>
> the Session-Reflector MUST discard the non-matching packet(s) and take
>
> no further action on them.
>
>    .  A conforming...
>
> GIM>> We've discussed the scenario and couldn't define how a
> Session-Reflector can distinguish between a new STAMP test session and the
> event of a change in identifiers, i.e., SSID and 4-tuple of the ongoing
> test session. Could you kindly help us here?
>
>
>
> *[acm] Thanks, I’m surprised that a new test session (with new SSID) can
> begin without any Session-Reflector agreement or communication from the
> Session-Reflector’s management interface. Since the Sending address and
> port could be spoofed, Session-Reflectors could receive lots of unexpected
> traffic, if you know what I mean..... *
>
>
>
>
>
> ...
>
>  …                 | 2     |   Non-3GPP  | This document |
>
>                   +-------+-------------+---------------+
>
> [acm] these seem overly broad, and unlikely to be extended because they
> *cover everything*!!
>
> GIM>> Here we've turned to our 3GPP expert... The current (Rel-16)
> specification of ATSSS defines only two access types - 3GPP and Non-3GPP.
> Creating a sub-registry and leaving a space for new types might help to
> accommodate potential changes in 5G specification and the development of
> new specifications, e.g., 6G, in the future.
>
> *[acm] *
>
> *Yes, but your examples of 5G and 6G would fall under the general category
> of “3GPP” (which I accidentally delated above).*
>
> *Maybe some additional detail would help, like “3GPP-LTE”, “3GPP-5G”, and
> make “Non-3GPP” the first entry so that expansion with new technologies
> starts at 2, 3, …*
>
>                             Table 8: Access IDs
>
>
>
> ...
>
>
>
>               +-------+---------------------+---------------+
>
>               | Value |     Description     | Reference     |
>
>               +-------+---------------------+---------------+
>
>               | 1     |  Network available  | This document |
>
>               | 2     | Network unavailable | This document |
>
>               +-------+---------------------+---------------+
>
> [acm] these seem overly broad, and imply knowledge where the STAMP
> end-point has limited insights!!
>
> GIM>>  These are defined in ATSSS specification of Performance Measurement
> Function. The value for the Return Code field is passed to STAMP system and
> it only transports it. Would a new text clarify the role of a STAMP system:
>
> OLD TEXT:
>
>    o  Return Code - one octet long field that identifies the report
>       signal, e.g., available, unavailable.  The value is one of those
>       listed in Section 5.5.
>
> NEW TEXT:
>
>    o  Return Code - one octet long field that identifies the report
>       signal, e.g., available, unavailable.  The value is passed,
>       supplied to the STAMP end-point through some mechanism that is
>       outside the scope of this document.  The value is one of those
>       listed in Section 5.5.
>
> *[acm] *
>
> *OK*
>
>                           Table 10: Return Codes
>
>
>
> ...
>
>
>
> 6.  Security Considerations
>
>
>
>    Use of HMAC in authenticated mode may be used to simultaneously
>
>    verify both the data integrity and the authentication of the STAMP
>
>    test packets.
>
> [acm] That's it? At least add reference to STAMP 8762 Security Section?
>
> GIM>> Thank you for your suggestion. The new text is below:
>
> NEW TEXT:
>
>    This document defines extensions to STAMP [RFC8762] and inherits all
>
>    the security considerations applicable to the base protocol.
>    Additionally, the HMAC TLV is defined in this document to protect the
>    integrity of optional STAMP extensions.  The use of HMAC TLV is
>    discussed in detail in Section 4.8.
>
>
>
> *[acm] OK*
>
> [acm] I suspect there will be some challenges for "Location" in future
>
>
>
>
>
> *From:* ippm [mailto:[e-mail]] *On Behalf Of *Ian Swett
> *Sent:* Friday, May 22, 2020 5:26 PM
> *To:* IETF IPPM WG ([e-mail]) <[e-mail]>
> *Subject:* [ippm] WGLC for STAMP Extensions
>
>
>
> Hi IPPM,
>
> At our virtual interim meeting, we decided
> draft-ietf-ippm-stamp-option-tlv was ready for last call. This email starts
> a two-week WGLC for this draft.
>
> The latest version can be found here:
> https://tools.ietf.org/html/draft-ietf-ippm-stamp-option-tlv-04
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dippm-2Dstamp-2Doption-2Dtlv-2D04&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=-FQ_7VkardtUOemNdXjWGCdxDzw_8jcaV16Ots-GfRo&s=zadhVvE6IwVbJd0BcDUJdpX4xXqA4i60susVdbT5Pvg&e=>
>
> This last call will end on *Monday, June 8th*. Please reply to
> [e-mail] with your reviews and comments.
>
> Thanks,
> Ian & Tommy
>
> _______________________________________________
> ippm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ippm
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ippm&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=_6cen3Hn-e_hOm0BhY7aIpA58dd19Z9qGQsr8-6zYMI&m=AJPt25JReJLCcKTac6bW207kN8j0F2v7N7paNXkrS0Y&s=9RnqOZ8tzteJbGK2PJMpE2Y8RqKl-bvq-QfiStX4ywc&e=>
>
> _______________________________________________
> ippm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ippm
>
>