Re: [secdir] Secdir review of draft-ietf-ippm-stamp-option-tlv-06

Greg Mirsky <gregimirsky@gmail.com> Mon, 29 June 2020 20:19 UTC

Return-Path: <gregimirsky@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 486E43A087D; Mon, 29 Jun 2020 13:19:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.696
X-Spam-Level:
X-Spam-Status: No, score=-0.696 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_COMMENT_SAVED_URL=1.391, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_HTML_ATTACH=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6j8CrHkM31Q4; Mon, 29 Jun 2020 13:19:32 -0700 (PDT)
Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 522A13A087C; Mon, 29 Jun 2020 13:19:31 -0700 (PDT)
Received: by mail-lj1-x22b.google.com with SMTP id f5so3851939ljj.10; Mon, 29 Jun 2020 13:19:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jSTwFG4gENTuSoYc3yg+iwSvtpa4L7LlpPLJyneDqRE=; b=ZzCoZCuvt3Y+IWoYD88edo+7yF+6pK6E1vAa5+N7k/Dn8d3Sfc/HgZskAgkdTlsvwj 3dCfzIzY5EegZGAHFQ953lRGGJ/hDpjEIQEbTzwPR1QuLN5IwE1lzhK18x+gUV1+ARYg It7E7UpWizqNcizvmnnVmkOKHqc5HkBwbDzkkUf3na+cvaIPxA2vYMbIYwi7ed7tlTu2 +t6WDQNwSanUwNQaKPri9OYxvYJvKDDDG72BN5K5ykqI74B+ijAJR44adSWctbXKKyxw ng/qs+9HPFx/NZ37wXh5WjfC0/5dZuVONdBL/VxdRmRRtsZPhTWnzW4/sTg+R8H+W/dG bYhA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jSTwFG4gENTuSoYc3yg+iwSvtpa4L7LlpPLJyneDqRE=; b=JU/eQ73QpLSkB/4kkhVbISaDgfpom33Ks8QKjn6ZFajhMq67jGYNZiJv+NGDE9KaZw SyZajhJxkL6hRdWhVnOo1h/yHWGSAgYZzZZHMqBBxnMe5ssPfueIo/rIFaiZSHvaxsJT Af0kpSVidepSJHd30Ghz3f3I+f69PMqZaFJDTPZ5VFx/cj3BcEkwNC/8vUNlwbB51q7B 6DEhIWrWAjUyN1Z7l+eOm0xrsozV/xkM8HDYQbYZN5UGIZTyc3N4L/g25xmanjqtybEK BJvy08QE2sHra638C49V/ojEvV+1HFz8WyzSPi9BGuPj4omFD7XYXZEcm07qtkcs3d97 2wng==
X-Gm-Message-State: AOAM531RXSWFwBxSqSm9Q4+TYrZ+GLb2dOcmRdLLz1/OSpx0r1XrQ+60 CVzRqaNnr5nmURk+XmD0L9xNDa+lkuyRCifGwY4=
X-Google-Smtp-Source: ABdhPJxLqi7iShq7+V9bM5/1pc6zmnUa42jVy0TciDXAGif4h/fzuGOk3frzGAvAQFk03eCeghTUicIH0q9Ft29nrXY=
X-Received: by 2002:a2e:7804:: with SMTP id t4mr8990599ljc.8.1593461969082; Mon, 29 Jun 2020 13:19:29 -0700 (PDT)
MIME-Version: 1.0
References: <CY4PR0701MB36501A472EF93F5FCAE71413DF900@CY4PR0701MB3650.namprd07.prod.outlook.com>
In-Reply-To: <CY4PR0701MB36501A472EF93F5FCAE71413DF900@CY4PR0701MB3650.namprd07.prod.outlook.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Mon, 29 Jun 2020 13:19:18 -0700
Message-ID: <CA+RyBmWjF3Z9Dh=e8tWYpniHqbLQYQJ1dHH_W78Ye=r05qvbXA@mail.gmail.com>
To: Charlie Kaufman <charliekaufman@outlook.com>
Cc: "secdir@ietf.org" <secdir@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "draft-ietf-ippm-stamp-option-tlv.all@ietf.org" <draft-ietf-ippm-stamp-option-tlv.all@ietf.org>
Content-Type: multipart/mixed; boundary="000000000000a26e9f05a93ec681"
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/KdGgWgdnvCV0JiQbKWRuqcGBIQc>
Subject: Re: [secdir] Secdir review of draft-ietf-ippm-stamp-option-tlv-06
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 29 Jun 2020 20:19:41 -0000

Hi Charlie,
thank you for your thorough review, detailed questions, and
thoughtful suggestions. We've discussed your comments and propose changes
that are described below. Also, you can find the changes highlighted in the
attached diff between the -06 and the new working version of the document.
Please find my answers, notes in-line below under the GIM>> tag.

Regards,
Greg

On Fri, Jun 26, 2020 at 10:34 PM Charlie Kaufman <charliekaufman@outlook.com>
wrote:

> I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the IESG.
> These comments were written primarily for the benefit of the security area
> directors.  Document editors and WG chairs should treat these comments just
> like any other last call comments.
>
> This I-D specifies extensions to the STAMP protocol defined in RFC 8762.
> The STAMP protocol runs over UDP and is similar to an "echo" protocol
> intended to be used to test network speed and bandwidth. This I-D specifies
> a series of TLV encoded extensions that can be appended to the end of the
> UDP packets of the STAMP protocol (as well as defining the TLV mechanism
> itself).
>
> I could not find anything objectionable from a security standpoint in this
> extension mechanism. It is a bit odd that when extensions are added to an
> HMAC protected packet, instead of adding the extensions before the HMAC and
> having the HMAC protect the entire contents, they keep the existing HMAC
> that protects the base packet and add a second HMAC at the end of the
> extensions that protects only the extensions. This would potentially allow
> an attacker to "mix and match" the extensions from one packet with the base
> content of a different packet, but it's not clear what an attacker might be
> able to gain by doing that.
>
GIM>> I think that the STAMP YANG data model could be used to minimize the
possible attack vector you've described. We will certainly keep that as one
of the objectives when updating draft-ietf-ippm-stamp-yang
<https://datatracker.ietf.org/doc/draft-ietf-ippm-stamp-yang/>. Also, HMAC
TLV might be required even in unauthenticated STAMP mode to protect the
integrity on a certain TLV(s). Do you see this as a useful scenario or
unnecessary feature?

>
> One of the pieces of information an extension can request is the 6 byte
> MAC address of the incoming packet as seen by the peer (which will normally
> by the MAC address of the last router on the path). That information is not
> normally available to someone on a distant network, but it's not obvious
> what harm could come from their knowing it.
>
GIM>> As mentioned above, HMAC TLV may follow some STAMP TLVs. Do you think
that the document should recommend using HMAC TLV with the Location TLV?

>
> The protocol can also request the source and destination IP addresses as
> seen by the peer (presumably to detect NAT gateways), but the protocol
> assumes the originator will know whether the peer will see IPv4 or IPv6
> addresses, so dealing with 6-to-4 gateways could be tricky.
>
> On page 19 table 2, this document asks IANA to assign extension type
> codes. In all other documents of this sort that I have seen, the document
> assigns the codes and asks IANA to track subsequent additions.
>
GIM>> Martin Duke, the Responsible AD for IPPM WG, asked this question in
his review. He has agreed to leave the text as-is since no one asked for a
particular number.

>
> On some kinds of errors, the protocol specifies that the error is reported
> via and ICMP message. For others, it specifies that a field be returned
> containing all zeros. It's probably better to report errors "in band"
> because so many routers swallow ICMP messages. The spec does not - and
> should - specify what to do if the length of the TLV coded extensions does
> not match the length of the UDP packet containing them (or at least I
> couldn't find where it was specified).
>
GIM>> Thank you for pointing out this awkward handling. We had continued
discussion with Martin Duke and Rakesh Gandhi on improving the mechanism of
reporting TLV errors. The discussion is in the updated Section 4 of the new
working version and is copied below:
4.  TLV Extensions to STAMP

   Type-Length-Value (TLV) encoding scheme provides a flexible extension
   mechanism for optional informational elements.  TLV is an optional
   field in the STAMP test packet.  Multiple TLVs MAY be placed in the
   STAMP test packet.  A TLV MAY be enclosed in a TLV.  TLVs have the
   two octets long Type field, two octets long Length field that is
   equal to the length of the Value field in octets.  If a Type value
   for TLV or sub-TLV is in the range for Vendor Private Use, the Length
   MUST be at least 4, and the first four octets MUST be that vendor's
   the Structure of Management Information (SMI) Private Enterprise
   Codes, as recorded in IANA's SMI Private Enterprise Codes sub-
   registry, in network octet order.  The rest of the Value field is
   private to the vendor.  The following sections describe the use of
   TLVs for STAMP that extends STAMP capability beyond its base
   specification.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |U|L|R|R|R|R|R|R|     Type      |           Length              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ~                            Value                              ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Figure 5: TLV Format in a STAMP Extended Packet

   where fields are defined as the following:

   o  U - a one-bit flag, located as specified in Section 5.2.  A
      Session-Sender MUST set the U flag to 0 before transmitting an
      extended STAMP test packet.  A Session-Reflector MUST set the U
      flag to 1 if the Session-Reflector has not understood the TLV.

   o  L - a one-bit flag, located as specified in Section 5.2.  A
      Session-Sender MUST set the L flag to 0 before transmitting an
      extended STAMP test packet.  A Session-Reflector MUST set the L
      flag to 1 if the Session-Reflector determined the TLV is
      malformed, i.e., the Length field value of the fixed-size TLV is
      not equal to the value defined for the particular type, or the
      remaining length of the extended STAMP packet is less than the
      size of the TLV.

   o  R - reserved flags for future use.  These flags MUST be zeroed on
      transmit and ignored on receipt.

   o  Type - one-octet long field that characterizes the interpretation
      of the Value field.  It is allocated by IANA, as specified in
      Section 5.1

   o  Length - two-octets long field equals length on the Value field in
      octets.

   o  Value - a variable-length field.  Its interpretation and encoding
      determined by the value of the Type field.

   A STAMP node, whether Session-Sender or Session-Reflector, receiving
   a test packet MUST determine whether the packet is a base STAMP
   packet or includes one or more TLVs.  The node MUST compare the value
   in the Length field of the UDP header and the length of the base
   STAMP test packet in the mode, unauthenticated or authenticated based
   on the configuration of the particular STAMP test session.  If the
   difference between the two values is larger than the length of UDP
   header, then the test packet includes one or more STAMP TLVs that
   immediately follow the base STAMP test packet.

   A system that has received a STAMP test packet with extension TLVs
   MUST validate each TLV:

      if the U flag is set, the STAMP system MUST skip the processing of
      the TLV.  The implementation MUST try to process the next TLV if
      present in the extended STAMP packet.

      if the L flag is set, the STAMP system MUST stop processing the
      remainder of the extended STAMP packet.

      if an implementation of a Session-Reflector does not recognize the
      Type field value, it MUST include the copy of the TLV into the
      reflected STAMP packet.  The Session-Reflector MUST set the U flag
      to 1.  The Session-Reflector MUST try to process the next TLV in
      the extended STAMP packet;

      if a TLV is malformed, the processing of extension TLVs MUST be
      stopped.  The Session-Reflector MUST copy the remainder of the
      received extended STAMP packet into the reflected STAMP packet.
      The Session-Reflector MUST set the L flag to 1.

   Detected error events MUST be logged.  Note that rate of logging MUST
   be controlled.

Please note, that IANA is also requested to create a STAMP TLV Flags
sub-registry.
We hope this is an acceptable solution. Always welcome your questions,
comments, and suggestions.


> --Charlie
>