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

["Eric Vyncke (evyncke)" <[e-mail]>]

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

-éric

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

    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) <[e-mail]> wrote:
    >
    > 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 <[e-mail]> on behalf of Greg Mirsky <[e-mail]>
    > Date: Tuesday, 14 July 2020 at 22:02
    > To: Eric Vyncke <[e-mail]>
    > Cc: IPPM Chairs <[e-mail]>, "[e-mail]" <[e-mail]>, The IESG <iesg@ietf..org>, Yali Wang <[e-mail]>, IETF IPPM WG <[e-mail]>
    > 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 <[e-mail]> wrote:
    >
    > É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,
    >
    > GIM>> Absolutely. Thank you for your comments and questions.
    >
    >
    > 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.
    >
    > 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?
    >
    >
    > 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)
    >
    > GIM>> Yes, agree. Updated draft accordingly.
    >
    >
    > -- 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.
    >
    > 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.
    >
    >
    > -- 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?
    >
    > 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.
    >
    >
    > -- Section 4.8
    > What is the expected behavior of a Session-Sender when receiving a 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.
    >
    >
    > 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.