Re: [ippm] WGLC for STAMP Extensions

[Rakesh Gandhi <[e-mail]>]

Sure, thanks Greg.



On Thu, Jun 11, 2020 at 12:38 PM Greg Mirsky <[e-mail]> wrote:

> Hi Rakesh,
> many thanks for the suggested text. I understand the intention of the
> change but I think that the text proposed earlier, that Al has agreed to,
> does not mandate that a Session-Reflector was provisioned with a specific
> for the particular STAMP test session value of SSID. Provisioning, in my
> view, could be as simple as leaving it a wildcard, i.e. Any. If we can
> agree with this interpretation in this document, we'll decide on the
> default values for all elements in the STAMP YANG data model. I hope you
> can accept that.
>
> Regards,
> Greg
>
> On Thu, Jun 11, 2020 at 8:07 AM Rakesh Gandhi <[e-mail]>
> wrote:
>
>> Hi Greg,
>> Basically removing the need to provision the SSID on the reflector node.
>> So new text may look like:
>>
>>    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 elements of the usual 4-tuple for the 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.
>>
>>
>>
>> Thanks,
>>
>> Rakesh
>>
>>
>>
>>
>>
>> On Thu, Jun 11, 2020 at 10:44 AM Greg Mirsky <[e-mail]>
>> wrote:
>>
>>> 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
>>>>
>>>>