[ippm] Secdir early review of draft-ietf-ippm-capacity-protocol-01
Brian Weis via Datatracker <noreply@ietf.org> Thu, 23 June 2022 00:44 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 DC611C157B4F; Wed, 22 Jun 2022 17:44:57 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Brian Weis via Datatracker <noreply@ietf.org>
To: secdir@ietf.org
Cc: draft-ietf-ippm-capacity-protocol.all@ietf.org, ippm@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 8.4.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <165594509789.35936.13892356107964016466@ietfa.amsl.com>
Reply-To: Brian Weis <bew.stds@gmail.com>
Date: Wed, 22 Jun 2022 17:44:57 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/PbpnzZBomBUPx4ulsXHXgpm_LFQ>
Subject: [ippm] Secdir early review of draft-ietf-ippm-capacity-protocol-01
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.39
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: Thu, 23 Jun 2022 00:44:57 -0000
Reviewer: Brian Weis Review result: Not Ready 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. The summary of the review is Not ready. (However, as this is an early review, this should not be unexpected.) Here are some concerns, comments, and questions. (1) With the current network flows, there’s some doubt that flows will actually pass one or more firewalls between the client and server. Section 3 begins by saying “One end-point takes the role of server, awaiting connection requests on a well-known port from the other end-point, the client.” As I understand the above text, the client sends from a well-known port rather than the conventional method of a server opening a well-known port and listening on it. So a firewall in front of the client may open an inbound pinhole of “ephemeral port -> well-known port” (since the client sent a message from "well-known port -> ephemeral port"). This ought to be sufficient, from the client’s perspective. But Security Consideration also says this: “Firewalls protecting each host can both continue to do their job normally. This aspect is similar to many other test utilities available.” I don’t understand how any reasonable firewall policy would be defined on the server side, when a client is initiating a protocol to a server’s ephemeral port. That is, ephemeral ports are usually blocked unless the server sends an outgoing message from it. So how the firewall policy is intended to work needs to be described much more clearly. For example, if there is a co-dependancy that a firewall administrator be required to open all of the ephemeral ports that the server might use in advaance, that needs to be stated. (Having said that, such a policy might very well be unacceptable to the firewall administrator.) Or if the server is never expected to have a firewall in front of it this last quoted sentence needs to be changed to say that. (2) Can you describe the server’s behavior more clearly, as to how as a server it listens on an ephemeral port, a range of ephemeral ports, or whatever strategy you have in mind? This seems backwards from the usual flows of client using an ephemeral port to contact a server on a well-known port. The last quote above includes the sentence: "This aspect is similar to many other test utilities available.” and seems to indicate that there are existing examples of how this works. Do these “other test utilities” really have these same data flows? If so, then please describe how an existing firewall placed in front of the server works when the server is receiving packets on ephemeral ports. (3) The draft seems to define message authentication only for the Setup Request and Response messages. In this situation I assume the goal is to authenticate a peer with the goal of verifying peer authorization only. That is, when only these messages are authenticated then there is no real goal of knowing whether the measurements later sent are accurate since an attacker can theoretically modify messages in transit. The other messages seem to lack a authDigest field. But Security Considerations does state “Client-server authentication and integrity protection for feedback messages conveying measurements is RECOMMENDED. “ So is message authentication intended as an option for all messages but the PDUs in -01 just doesn’t show the authDigest field yet? If so, it would be good to explicitly add them. In any case, Security Considerations needs to state just what the security goals are when only some messages are authenticated, and defend why that is acceptable. For example, I understand that adding message authentication processing to feedback messages generated by a data plane can affect the quality of the measurements, and some people might accept that measurements are not necessarily correct if they have been tampered by an attacker. (4) Section 3 says “If the Setup Request must be rejected (due to any of the reasons in the Command response codes listed below), a Setup Response SHALL be sent back to the client with a corresponding command response value indicating the reason for the rejection.” I note that some reasons have to do with the server not being able to authenticate the client. Assuming the server has an open port or set of ports that any network device can target, this seems like an opportunity for an arbitrary network device spoofing a victim IP address to use the server as a DDoS “bounce” address targeting that victim. That is, the attacker would create a message with the victim's IP address as source address, and use a destination address of the measurement server, causing the measurement server to reply to the intended victim. A more secure policy would be to silently drop messages that cannot be authenticated, even though this makes diagnosing the failure harder. The idea of silently dropping message is mentioned on Page 9, including when “a directed attack has been detected”, but as these attacks can do a lot of damage before being detected it’s not really sufficient to just say that “Attack detection is beyond the scope of this specification”. Yes, that’s true, but causing a vulnerability in protocol design and assuming some other system will detect and block it is not sufficient. This is why it's important to silently drop messages that fail authentication. Otherwise, the remaining threat needs to be defended in Security Considerations. (5) Section 5.1 begins by saying “When the client receives the Setup response from the server it first checks the cmdResponse value.” Actually, checking the validity of the authDigest field in the Setup Response should be the first step. Otherwise, the cmdResponse value is not known to be trustable. (6) Section 6.1 does mention using the “Authentication mode, and Authentication time stamp” in the context of the Test Activation Request. Can you clarify how these data fields are used? Would it be reasonable to add these fields to the Test Activation Request and Response messages, since they seem to be control plane messages rather than data plane messages? (7) Section 7.2. There is a note that protection from bit errors could be desirable. I note that message authentication of these messsage would ensure that bit errors are detected. (8) Section 8 says “When the client receives a load or status PDU with the STOP1 indication, it SHALL finalize testing, ….” Stopping a test seems like an important message to verify that it actually came from the server rather than an attacker that doesn’t want the measurement to happen. (Maybe the measurement would result in discovery that the attcker is using some resources, or some such.) An authDigest field would resolve that threat. (9) Section 10 says “Cooperating source and destination hosts and agreements to test the path between the hosts are REQUIRED.” I assume this cooperation is determined by authorization through the use of the authDigest field and the known identity associated with the key used to create the authDigest field. If so this sentence should say this more explicitly. (10) The authDigest usage needs to be defined, i.e. what bytes are included in the digest, etc. Also the choices that can be configured for authMode should be stated. Also, there should be a registry of authentication methods for interoperabilty. (11) The use of authUnixTime is not stated anywhere. Why is time important, how does a receiver determine if the time is accuracy given latency in the network, and what threats does it resolve? Thanks, Brian
- [ippm] Secdir early review of draft-ietf-ippm-cap… Brian Weis via Datatracker
- Re: [ippm] Secdir early review of draft-ietf-ippm… MORTON JR., AL
- Re: [ippm] Secdir early review of draft-ietf-ippm… Brian Weis
- Re: [ippm] Secdir early review of draft-ietf-ippm… MORTON JR., AL