Re: [ippm] WGLC for STAMP Extensions

[Rakesh Gandhi <[e-mail]>]

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
>