Subject: Re: [ippm] Roman Danyliw's Discuss on draft-ietf-ippm-stamp-option-tlv-07: (with DISCUSS and COMMENT)

From: Greg Mirsky <[email-masked]>
Date: Wed, 19 Aug 2020 11:44:54 -0700

Hi Roman,
I hope this note finds you well.
We've worked on addressing your DISCUSSes and the updates are in the
recently published version
<https://datatracker.ietf.org/doc/draft-ietf-ippm-stamp-option-tlv/>. I
much appreciate your feedback on these updates whether we've understood
your DISCUSSes and have addressed them.

Regards,
Greg

On Tue, Jul 14, 2020 at 4:53 PM Greg Mirsky <[email-masked]> wrote:

> Hi Roman,
> thank you for your review, questions, and comments. Please find my answers
> below tagged GIM>>.
>
> Regards,
> Greg
>
> On Mon, Jul 13, 2020 at 10:12 AM Roman Danyliw via Datatracker <
> [email-masked]> wrote:
>
>> Roman Danyliw has entered the following ballot position for
>> draft-ietf-ippm-stamp-option-tlv-07: Discuss
>>
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut this
>> introductory paragraph, however.)
>>
>>
>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>> for more information about IESG DISCUSS and COMMENT positions.
>>
>>
>> The document, along with other ballot positions, can be found here:
>> https://datatracker.ietf.org/doc/draft-ietf-ippm-stamp-option-tlv/
>>
>>
>>
>> ----------------------------------------------------------------------
>> DISCUSS:
>> ----------------------------------------------------------------------
>>
>> ** Section 4.2.  The Location TLV is explicitly trying to extract network
>> configuration information that would be elided by the first hop router
>> (MAC) or
>> a NAT (real IP address).  RFC8762 helpfully notes that “When using STAMP
>> over
>> the Internet … impact of the STAMP-Test packets MUST be thoroughly
>> analyzed.”
>> Please provide a bit of text describing the privacy implications here (or
>> bound
>> this with an applicability statement).
>>
> GIM>> You have a valid concern that the Location TLV provides information
> on the penultimate to the Session-Reflector router. We can recommend using
> the Location TLV either in the STAMP Authenticated mode or in combination
> with HMAC TLV. Would that address your concern?
>
>>
>> ** Section 4.8.  Is the key used for the HMAC TLV the same as the one in
>> the
>> HMAC in the STAMP authenticated packet?  Could one use different keys?
>>
> GIM>> From practical POV, an implementation may choose so that HMAC TLV
> will always use the same key as HMAC in the STAMP base packet. But that is
> not required as the document leaves the key management outside its scope by
> way of reference to Section 4.4 RFC 8762.
>
>>
>>
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>>
>> Thank you for responding to the SECDIR review (and thank you to Charlie
>> Kaufman
>> for doing it).
>>
>> ** Section 4.6.  Per the “ID (Access ID)”, I was a surprised that the
>> values
>> are hard-coded as this complicates future extensibility (e.g., providing
>> further fidelity into the type “non-3gpp network” used).  Perhaps this was
>> intentional to meet the PMF component of TS23501?
>>
> GIM>> Indeed, it is how 3GPP defined the PMF. From its POV, any network,
> 3GPP or Non-3GPP of any kind, that connects to 5GNC uses the same
> interfaces and APIs as 3GPP. But that doesn't say that 3GPP may decide to
> use other IDs in the future.
>
>>
>> ** Section 4.8.  This mechanism like, RFC8762, does not provide for
>> algorithm
>> agility.  As RFC8762 at least says “Future specifications may define the
>> use of
>> other, more advanced cryptographic algorithms, …” it would be useful to
>> say
>> that this TLV is anticipated to track updates in the base STAMP protocol.
>>
> GIM>> Agree. Below is the proposed update:
> OLD TEXT:
>    As defined in [RFC8762], STAMP uses HMAC-SHA-256 truncated to 128
>    bits ([RFC4868]).  All considerations regarding using the key and key
>    distribution and management listed in Section 4.4 of [RFC8762] are
>    fully applicable to the use of the HMAC TLV.
> NEW TEXT:
>     As defined in [RFC8762], STAMP uses HMAC-SHA-256 truncated to 128
>    bits ([RFC4868]).  All considerations regarding using the key and key
>    distribution and management listed in Section 4.4 of [RFC8762] are
>    fully applicable to the use of the HMAC TLV.  HMAC TLV is anticipated
>    to track updates in the base STAMP protocol [RFC8762], including the
>    use of more advanced cryptographic algorithms.
>

---

From: Roman Danyliw <[email-masked]>
Date: Fri, 21 Aug 2020 19:14:16 +0000

Hi Greg!

Thanks the -08 update.  Per one of the DISCUSSes, could you please add a trivial scoping sentenced described below.

Thanks,
Roman

From: Greg Mirsky <[email-masked]>
Sent: Wednesday, August 19, 2020 2:45 PM
To: Roman Danyliw <[email-masked]>
Cc: The IESG <[email-masked]>; [email-masked]; IPPM Chairs <[email-masked]>; IETF IPPM WG <[email-masked]>; Yali Wang <[email-masked]>
Subject: Re: Roman Danyliw's Discuss on draft-ietf-ippm-stamp-option-tlv-07: (with DISCUSS and COMMENT)

Hi Roman,
I hope this note finds you well.
We've worked on addressing your DISCUSSes and the updates are in the recently published version<https://datatracker.ietf.org/doc/draft-ietf-ippm-stamp-option-tlv/>. I much appreciate your feedback on these updates whether we've understood your DISCUSSes and have addressed them.

Regards,
Greg

On Tue, Jul 14, 2020 at 4:53 PM Greg Mirsky <[email-masked]<mailto:[email-masked]>> wrote:
Hi Roman,
thank you for your review, questions, and comments. Please find my answers below tagged GIM>>.

Regards,
Greg

On Mon, Jul 13, 2020 at 10:12 AM Roman Danyliw via Datatracker <[email-masked]<mailto:[email-masked]>> wrote:
Roman Danyliw has entered the following ballot position for
draft-ietf-ippm-stamp-option-tlv-07: Discuss

** Section 4.2.  The Location TLV is explicitly trying to extract network
configuration information that would be elided by the first hop router (MAC) or
a NAT (real IP address).  RFC8762 helpfully notes that “When using STAMP over
the Internet … impact of the STAMP-Test packets MUST be thoroughly analyzed.”
Please provide a bit of text describing the privacy implications here (or bound
this with an applicability statement).
GIM>> You have a valid concern that the Location TLV provides information on the penultimate to the Session-Reflector router. We can recommend using the Location TLV either in the STAMP Authenticated mode or in combination with HMAC TLV. Would that address your concern?

Thanks.  The additional concern I had in mind was the confidentiality of the network infrastructure information being sent in the clear over the Internet.  Again, this is case where Section 4.5 of RFC8762 already has the right word (and you cite it in the Security Considerations generically).  As a COMMENT, I would suggest you reiterate that guidance in particular for this TLV because of the information it carries.

** Section 4.8.  Is the key used for the HMAC TLV the same as the one in the
HMAC in the STAMP authenticated packet?  Could one use different keys?
GIM>> From practical POV, an implementation may choose so that HMAC TLV will always use the same key as HMAC in the STAMP base packet. But that is not required as the document leaves the key management outside its scope by way of reference to Section 4.4 RFC 8762.

[Roman] The revised language is much clearer, thank you for adding it.  I would also ask that you repeat that the keying is out of scope.  My read of Section 4 of RFC8762 is that it provides guidance in the context of only the base specification.

Thank you for responding to the SECDIR review (and thank you to Charlie Kaufman
for doing it).

** Section 4.6.  Per the “ID (Access ID)”, I was a surprised that the values
are hard-coded as this complicates future extensibility (e.g., providing
further fidelity into the type “non-3gpp network” used).  Perhaps this was
intentional to meet the PMF component of TS23501?
GIM>> Indeed, it is how 3GPP defined the PMF. From its POV, any network, 3GPP or Non-3GPP of any kind, that connects to 5GNC uses the same interfaces and APIs as 3GPP. But that doesn't say that 3GPP may decide to use other IDs in the future.

[Roman] Understood.  Thanks for explaining.

** Section 4.8.  This mechanism like, RFC8762, does not provide for algorithm
agility.  As RFC8762 at least says “Future specifications may define the use of
other, more advanced cryptographic algorithms, …” it would be useful to say
that this TLV is anticipated to track updates in the base STAMP protocol.
GIM>> Agree. Below is the proposed update:
OLD TEXT:
   As defined in [RFC8762], STAMP uses HMAC-SHA-256 truncated to 128
   bits ([RFC4868]).  All considerations regarding using the key and key
   distribution and management listed in Section 4.4 of [RFC8762] are
   fully applicable to the use of the HMAC TLV.
NEW TEXT:
    As defined in [RFC8762], STAMP uses HMAC-SHA-256 truncated to 128
   bits ([RFC4868]).  All considerations regarding using the key and key
   distribution and management listed in Section 4.4 of [RFC8762] are
   fully applicable to the use of the HMAC TLV.  HMAC TLV is anticipated
   to track updates in the base STAMP protocol [RFC8762], including the
   use of more advanced cryptographic algorithms.

[Roman] Makes sense.  Thanks.

---

From: Greg Mirsky <[email-masked]>
Date: Fri, 21 Aug 2020 12:47:32 -0700

Hi Roman,
thank you for your quick response and kind consideration of the updates.
Would the following update address your concern about the scope of the
document in regard to the HMAC key management and distribution mechanisms:
OLD TEXT:
   As defined in [RFC8762], STAMP uses HMAC-SHA-256 truncated to 128
   bits ([RFC4868]).  All considerations regarding using the key and key
   distribution and management listed in Section 4.4 of [RFC8762] are
   fully applicable to the use of the HMAC TLV.
NEW TEXT:
   As defined in [RFC8762], STAMP uses HMAC-SHA-256 truncated to 128
   bits ([RFC4868]).  All considerations regarding using the key listed
   in Section 4.4 of [RFC8762] are fully applicable to the use of the
   HMAC TLV.  Key management and the mechanisms to distribute the HMAC
   key are outside the scope of this specification.

Regards,
Greg

On Fri, Aug 21, 2020 at 12:14 PM Roman Danyliw <[email-masked]> wrote:

> Hi Greg!
>
>
>
> Thanks the -08 update.  Per one of the DISCUSSes, could you please add a
> trivial scoping sentenced described below.
>
>
>
> Thanks,
>
> Roman
>
>
>
> *From:* Greg Mirsky <[email-masked]>
> *Sent:* Wednesday, August 19, 2020 2:45 PM
> *To:* Roman Danyliw <[email-masked]>
> *Cc:* The IESG <[email-masked]>; [email-masked];
> IPPM Chairs <[email-masked]>; IETF IPPM WG <[email-masked]>; Yali
> Wang <[email-masked]>
> *Subject:* Re: Roman Danyliw's Discuss on
> draft-ietf-ippm-stamp-option-tlv-07: (with DISCUSS and COMMENT)
>
>
>
> Hi Roman,
>
> Thanks.  The additional concern I had in mind was the confidentiality of
> the network infrastructure information being sent in the clear over the
> Internet.  Again, this is case where Section 4.5 of RFC8762 already has the
> right word (and you cite it in the Security Considerations generically).
> As a COMMENT, I would suggest you reiterate that guidance in particular for
> this TLV because of the information it carries.
>
>
> [Roman] The revised language is much clearer, thank you for adding it.  I
> would also ask that you repeat that the keying is out of scope.  My read of
> Section 4 of RFC8762 is that it provides guidance in the context of only
> the base specification.
>
>
>
>

---

From: Roman Danyliw <[email-masked]>
Date: Fri, 21 Aug 2020 19:51:43 +0000

Hi Greg!

That looks good to me.

Thanks,
Roman

Sent: Friday, August 21, 2020 3:48 PM

Hi Roman,
thank you for your quick response and kind consideration of the updates. Would the following update address your concern about the scope of the document in regard to the HMAC key management and distribution mechanisms:
OLD TEXT:

Regards,
Greg

On Fri, Aug 21, 2020 at 12:14 PM Roman Danyliw <[email-masked]<mailto:[email-masked]>> wrote:
Hi Greg!

Thanks,
Roman

From: Greg Mirsky <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, August 19, 2020 2:45 PM
To: Roman Danyliw <[email-masked]<mailto:[email-masked]>>
Cc: The IESG <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; IPPM Chairs <[email-masked]<mailto:[email-masked]>>; IETF IPPM WG <[email-masked]<mailto:[email-masked]>>; Yali Wang <[email-masked]<mailto:[email-masked]>>
Subject: Re: Roman Danyliw's Discuss on draft-ietf-ippm-stamp-option-tlv-07: (with DISCUSS and COMMENT)

Hi Roman,

Regards,
Greg

Regards,
Greg

---

From: Greg Mirsky <[email-masked]>
Date: Fri, 21 Aug 2020 12:57:29 -0700

Hi Roman,
thank you. I'll upload -09 version with this update.

Regards,
Greg

On Fri, Aug 21, 2020 at 12:51 PM Roman Danyliw <[email-masked]> wrote:

> *Sent:* Friday, August 21, 2020 3:48 PM