Subject: [ippm] Éric Vyncke's No Objection on draft-ietf-ippm-stamp-option-tlv-07: (with COMMENT)

From: Éric Vyncke via Datatracker <[email-masked]>
Date: Mon, 13 Jul 2020 03:23:45 -0700

Éric Vyncke has entered the following ballot position for
draft-ietf-ippm-stamp-option-tlv-07: No Objection

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/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for the work put into this document.

Please find below a couple of non-blocking COMMENTs (and I would appreciate a
reply to my COMMENTs).

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

-- Section 4 --
The text "A system that has received a STAMP test packet with extension TLVs
MUST validate each TLV:" is unclear whether it is Session-Sender or
Session-Reflector or both. Clarification welcome.

The A-bit is linked to HMAC and looks like "Authentication" while section 4.8
says HMAC is only for integrity. Hence, why not using "I-bit" rather than
"A-bit" (cosmetic issue)

-- Section 4.1 --
For the 'Extra Padding' field, "a pseudo-random sequence of bits.  The field
MAY be filled with all zeros.". Is it 'bits' or 'octets' ? (the latter most
probably). I also have hard time to reconciliate "pseudo-random" with "MAY be
filled with 0"; this seems like an oxymoron to me.

-- Section 4.2 --
How to handle cases where the MAC address is not 6-bytes long ? AFAIK IEEE
802.15.4 uses 16 or 64-bit addresses and future MAC layers could use different
MAC addresses length. What should be the MAC address field value when there is
no associated MAC address?

-- Section 4.8
What is the expected behavior of a Session-Sender when receiving a STAMP packet
whose HMAC verification fails ?

I must also say that I am a little puzzled by the Session-Reflector behavior
when HMAC verification fails: logging and replying anyway seems opening an
avenue for STAMP service theft or DoS. Or am I missing something ?

-- Section 5.3 --
In table 5, is there a reason why Galileo is not listed ?

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 14 Jul 2020 12:54:32 -0700

Hi Eric,
thank you for your review and comments. Please find my answers and notes
below under the GIM>> tag. Also, attached is the diff to the working
version of the draft that highlights changes made so far.

Regards,
Greg

> https://datatracker.ietf.org/doc/draft-ietf-ippm-stamp-option-tlv/
GIM>> Absolutely. Thank you for your comments and questions.

> Session-Reflector or both. Clarification welcome.
GIM>> The new text is:
    A STAMP system, i.e., either a Session-Sender or a Session-Reflector,
   that has received a STAMP test packet with extension TLVs MUST
   validate each TLV:
Is it clearer now?

> says HMAC is only for integrity. Hence, why not using "I-bit" rather than
GIM>> Yes, agree. Updated draft accordingly.

> filled with 0"; this seems like an oxymoron to me.
GIM>> I agree, that it should refer to numbers. Here's the updated text:
      Extra Padding - SHOULD be filled by a sequence of a pseudo-random
      numbers.  The field MAY be filled with all zeros.  An
      implementation MUST control the type of filling of the Extra
      Padding field.

> no associated MAC address?
GIM>> Very interesting, thank you for the question. As I understand, IEEE
802.15.4 use is in the very limited and isolated space. I think that is
unlikely STAMP will be used in a network based on technology like
BlueTooth.If a different than 48 bits length of MAC be used to carry IP, we
might add another TLV.
And for the second question, I propose the following new text:
      Source MAC - 6-octet-long field.  The Session-Reflector MUST copy
      the Source MAC of the received STAMP packet into this field.  If
      there is no Source MAC field in the received test packet, the
      Session-Reflector MUST zero the Source MAC field in the reflected
      STAMP packet.

> whose HMAC verification fails ?
GIM>> I propose the following new text to append the paragraph:
   If the Session-Sender receives the HMAC TLV with I flag set to 1,
   then the Session-Sender MUST stop processing TLVs in the reflected
   test packet.  If HMAC verification by the Session-Sender fails, then
   the Session-Sender MUST stop processing TLVs in the reflected
   extended STAMP packet.

> avenue for STAMP service theft or DoS. Or am I missing something ?
GIM>> Our thinking was that the integrity of TLVs may be protected because
STAMP is in the authenticated mode or because an operator has chosen to
protect TLVs in the STAMP unauthenticated mode. If the former, then it is
likely that the HMAC verification of the STAMP base packet fails and rules
of RFC 8762 take precedence. In the latter case or if HMAC verification of
the base packet passes, the specification allows the base measurement but
does not process any TLV. Does that make sense?

> In table 5, is there a reason why Galileo is not listed ?
GIM>> Thank you for pointing to the Galileo navigation system. Added to the
list.

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Fri, 17 Jul 2020 08:46:05 +0000

Greg

Thank you for your quick reply. I agree all the proposed changes in the document even if I am still uneasy with the 48-bit MAC address.

-éric

From: iesg <[email-masked]> on behalf of Greg Mirsky <[email-masked]>
Date: Tuesday, 14 July 2020 at 22:02
To: Eric Vyncke <[email-masked]>
Cc: IPPM Chairs <[email-masked]>, "[email-masked]" <[email-masked]>, The IESG <[email-masked]>, Yali Wang <[email-masked]>, IETF IPPM WG <[email-masked]>
Subject: Re: Éric Vyncke's No Objection on draft-ietf-ippm-stamp-option-tlv-07: (with COMMENT)

Hi Eric,
thank you for your review and comments. Please find my answers and notes below under the GIM>> tag. Also, attached is the diff to the working version of the draft that highlights changes made so far.

Regards,
Greg

On Mon, Jul 13, 2020 at 3:24 AM Éric Vyncke via Datatracker <[email-masked]<mailto:[email-masked]>> wrote:
Éric Vyncke has entered the following ballot position for
draft-ietf-ippm-stamp-option-tlv-07: No Objection

Regards,

-éric

== COMMENTS ==

-- Section 4 --

-- Section 4.1 --

-- Section 4.2 --
GIM>> Very interesting, thank you for the question. As I understand, IEEE 802.15.4 use is in the very limited and isolated space. I think that is unlikely STAMP will be used in a network based on technology like BlueTooth.If a different than 48 bits length of MAC be used to carry IP, we might add another TLV.

-- Section 4.8

I must also say that I am a little puzzled by the Session-Reflector behavior
when HMAC verification fails: logging and replying anyway seems opening an
avenue for STAMP service theft or DoS. Or am I missing something ?
GIM>> Our thinking was that the integrity of TLVs may be protected because STAMP is in the authenticated mode or because an operator has chosen to protect TLVs in the STAMP unauthenticated mode. If the former, then it is likely that the HMAC verification of the STAMP base packet fails and rules of RFC 8762 take precedence. In the latter case or if HMAC verification of the base packet passes, the specification allows the base measurement but does not process any TLV. Does that make sense?

-- Section 5.3 --
In table 5, is there a reason why Galileo is not listed ?
GIM>> Thank you for pointing to the Galileo navigation system. Added to the list.

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 22 Jul 2020 12:54:11 -0700

Hi Eric,
we've worked with Benjamin on addressing the Location TLV in the NAT64
scenario. We came up with the proposal to use sub-TLVs for Source MAC
Address, Destination and Source IP Addresses. A Session-Sender uses
generic sub-TLV to query location information. The Session-Reflector
replies with sub-TLV types that are size-specific, e.g., EUI-48 or
EUI-64 for MAC, and IPv4 or IPv6 for IP addresses. Attached, please
find the current working version of the draft.

Regards,
Greg

On Fri, Jul 17, 2020 at 1:46 AM Eric Vyncke (evyncke) <[email-masked]> wrote:
> On Mon, Jul 13, 2020 at 3:24 AM Éric Vyncke via Datatracker <[email-masked]> wrote:
>

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Thu, 23 Jul 2020 13:46:08 +0000

Excellent, perhaps a little harder to parse but extensible: good move!

-éric

-----Original Message-----
From: iesg <[email-masked]> on behalf of Greg Mirsky <[email-masked]>
Date: Wednesday, 22 July 2020 at 21:54
To: Eric Vyncke <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, IPPM Chairs <[email-masked]>, The IESG <[email-masked]>, IETF IPPM WG <[email-masked]>, Yali Wang <[email-masked]>
Subject: Re: Éric Vyncke's No Objection on draft-ietf-ippm-stamp-option-tlv-07: (with COMMENT)

    Hi Eric,

    Regards,
    Greg

    On Fri, Jul 17, 2020 at 1:46 AM Eric Vyncke (evyncke) <[email-masked]> wrote:
    > Cc: IPPM Chairs <[email-masked]>, "[email-masked]" <[email-masked]>, The IESG <iesg@ietf..org>, Yali Wang <[email-masked]>, IETF IPPM WG <[email-masked]>