Re: [ippm] WGLC for STAMP Extensions

["MORTON, ALFRED C (AL)" <[e-mail]>]

OK, works for me,
Al

From: Greg Mirsky [mailto:[e-mail]]
Sent: Wednesday, June 10, 2020 9:47 PM
To: MORTON, ALFRED C (AL) <[e-mail]>
Cc: Ian Swett <ianswett=[e-mail]>; IETF IPPM WG ([e-mail]) <[e-mail]>
Subject: Re: [ippm] WGLC for STAMP Extensions

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]<mailto:[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]<mailto:[e-mail]>] On Behalf Of Ian Swett
Sent: Friday, May 22, 2020 5:26 PM
To: IETF IPPM WG ([e-mail]<mailto:[e-mail]>) <[e-mail]<mailto:[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]<mailto:[e-mail]> with your reviews and comments.

Thanks,
Ian & Tommy
_______________________________________________
ippm mailing list
[e-mail]<mailto:[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=>