[ippm] Benjamin Kaduk's Discuss on draft-ietf-ippm-stamp-option-tlv-09: (with DISCUSS and COMMENT)
Benjamin Kaduk via Datatracker <noreply@ietf.org> Wed, 02 September 2020 03:55 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: ippm@ietf.org
Delivered-To: ippm@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6708F3A0AF9; Tue, 1 Sep 2020 20:55:11 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benjamin Kaduk via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-ippm-stamp-option-tlv@ietf.org, ippm-chairs@ietf.org, ippm@ietf.org, Yali Wang <wangyali11@huawei.com>, wangyali11@huawei.com
X-Test-IDTracker: no
X-IETF-IDTracker: 7.15.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Benjamin Kaduk <kaduk@mit.edu>
Message-ID: <159901891096.15973.17525194862666459811@ietfa.amsl.com>
Date: Tue, 01 Sep 2020 20:55:11 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/Q4w7AUNvj9tYeJnQIFcQPaKLPew>
Subject: [ippm] Benjamin Kaduk's Discuss on draft-ietf-ippm-stamp-option-tlv-09: (with DISCUSS and COMMENT)
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.29
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ippm>, <mailto:ippm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ippm/>
List-Post: <mailto:ippm@ietf.org>
List-Help: <mailto:ippm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 02 Sep 2020 03:55:11 -0000
Benjamin Kaduk has entered the following ballot position for draft-ietf-ippm-stamp-option-tlv-09: 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: ---------------------------------------------------------------------- Thanks for all the updates; we've made good progress. I think we're still not converged on the DSCP handling, though. I have a bit more exposition in the COMMENT section, but in short, my understanding is that we're setting up a session-reflector to incur unbounded levels of risk with hard protocol requirements. I think we need to provide a way to bound that risk, for example by allowing the Session-Reflector to selectively choose to treat the CoS TLV as unimplemented (set the U flag in its reflected packet) or some other mechanism for local policy to filter what DSCP codepoints are set in reflected packets (ideally, indicating that the policy made a change). Also, there's a bit of fallout from the flags reworking that's left to cleanup in Section 4: we now have the Session-Sender set the U flag to 1, so this text no longer makes sense: % 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: % % If the U flag is set, the STAMP system MUST skip the processing of % the TLV. I think it should just apply to the Session-Sender for this case -- the Session-Reflector doesn't need to check the received U flag, since the Session-Sender will not be generating TLVs it does not understand. (Whether or not to keep the behavior for the M and I flags as applying to both Session-Sender and Session-Reflector vs. just Session-Sender does not immediately seem to be of much consequence. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- My most significant remaining comments are on the Security Considerations (Section 6): The security of the HMAC mechanism is not complete, since it is susceptible to replay attack. As such, when HMAC is in use, it is important to check that the received sequence numbers are (at least mostly) monotonic and to detect replays. While replayed packets do not always indicate an attack (depending on the network technology) they are still a noteworthy condition, and we should say something about whether we expect to produce a response to each received instance or to suppress replies to replayed input. Monitoring and optional control of DSCP do not appear to introduce any additional security threat to hosts that communicate with STAMP as defined in [RFC8762]. As this specification defined the mechanism to test DSCP mapping, this document inherits all the security I'm afraid I still don't understand the reasoning here. In my understanding, the risk stems from the semantics of the DCSP field being (for at least some codepoints) site-local, there not being a guarantee that the session-sender and session-reflector are on the same network (and thus, using the same DSCP semantics), and the hard requirement for the Session-Reflector to set the DCSP value indicated by the Session-Sender. A mechanism for a remote entity to induce generation of local packets with unspecified semantics is a risk that cannot be qualified at protocol-design time, since the possible outcomes are inherently unspecified. This is analogous to the situation with undefined behavior in programming languages like C -- the programmer is flat-out required to avoid it, because literally anything could go wrong if undefined behavior is triggered. This is especially risky when there is the possibility for the Session-Reflector to act on packets that do not have any form of authentication (i.e., could be spoofed from off-path). But we do not mention this risk at all, let alone give guidance on its mitigation. (Discussion of the security considerations of unauthenticated operation would ideally be generalized to all actions/TLVs that have side effects, not just the specific case of setting the DSCP codepoint.) Section 4.2 I'd suggest saying that all fields that are not filled are transmitted with all bits set to zero. Section 4.2.1 o Source MAC Address sub-TLV - is a 12-octet-long sub-TLV. The Type value is TBA9. The value of the Length field MUST equal to 8. The Value field is a 12-octet-long MBZ field that MUST be zeroed on transmission and ignored on receipt. Value should be 8-octets-long, no? Section 4.2.2 A Session-Sender MAY include the Source MAC Address sub-TLV is the Location TLV. If the Session-Reflector receives the Location TLV nit: s/is/in/ Section 4.3 MUST NOT fill any information fields except for STAMP TLV Flags, Type, and Length. All other fields MUST be filled with zeroes The nit: missing full stop.
- [ippm] Benjamin Kaduk's Discuss on draft-ietf-ipp… Benjamin Kaduk via Datatracker
- Re: [ippm] Benjamin Kaduk's Discuss on draft-ietf… Greg Mirsky
- Re: [ippm] Benjamin Kaduk's Discuss on draft-ietf… Martin Duke
- Re: [ippm] Benjamin Kaduk's Discuss on draft-ietf… Benjamin Kaduk
- Re: [ippm] Benjamin Kaduk's Discuss on draft-ietf… Martin Duke
- Re: [ippm] Benjamin Kaduk's Discuss on draft-ietf… Greg Mirsky
- Re: [ippm] Benjamin Kaduk's Discuss on draft-ietf… Martin Duke
- Re: [ippm] Benjamin Kaduk's Discuss on draft-ietf… Benjamin Kaduk
- Re: [ippm] Benjamin Kaduk's Discuss on draft-ietf… Greg Mirsky
- Re: [ippm] Benjamin Kaduk's Discuss on draft-ietf… Benjamin Kaduk
- Re: [ippm] Benjamin Kaduk's Discuss on draft-ietf… Greg Mirsky