Re: [ippm] WGLC for STAMP Extensions

[Greg Mirsky <[e-mail]>]

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
>>>>
>>>