Re: [ippm] WGLC for STAMP Extensions

[Greg Mirsky <[e-mail]>]

Hi Al,
we now have a proposal to address the open question related to the Access
ID in the Access Report TLV. I've front-copied it for the convenience.

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

We propose the following updates:
- do not create the Access ID sub-registry
- define only two values - 3GPP Network and Non-3GPP Network with all
others being invalid
- change the length of the Access ID field from one octet to four bits
- make the remaining four bits a new Resv field (for optional use in the
future)

Attached are the new working version and the diff to -04 version of the
draft.
I much appreciate your consideration, comments, and questions.

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