Re: [secdir] Secdir review of draft-ietf-savi-send-10
Alberto García <alberto@it.uc3m.es> Thu, 09 January 2014 10:24 UTC
Return-Path: <alberto@it.uc3m.es>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA0AD1AE1AE; Thu, 9 Jan 2014 02:24:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.772
X-Spam-Level:
X-Spam-Status: No, score=-3.772 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, SPF_SOFTFAIL=0.665] autolearn=ham
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 IrrcWIPalz0v; Thu, 9 Jan 2014 02:24:15 -0800 (PST)
Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by ietfa.amsl.com (Postfix) with ESMTP id 71BA71AE1F7; Thu, 9 Jan 2014 02:24:10 -0800 (PST)
Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id AD9A011BF590; Thu, 9 Jan 2014 11:24:00 +0100 (CET)
X-uc3m-safe: yes
X-uc3m-safe: yes
Received: from BOMBO (unknown [163.117.139.50]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: alberto@smtp03.uc3m.es) by smtp03.uc3m.es (Postfix) with ESMTPSA id 8579111BF902; Thu, 9 Jan 2014 11:24:00 +0100 (CET)
From: Alberto García <alberto@it.uc3m.es>
To: 'Vincent Roca' <vincent.roca@inria.fr>, 'IESG' <iesg@ietf.org>, draft-ietf-savi-send@tools.ietf.org, secdir@ietf.org
References: <206CF360-2CE2-4472-9252-707E0CB0888A@inria.fr>
In-Reply-To: <206CF360-2CE2-4472-9252-707E0CB0888A@inria.fr>
Date: Thu, 09 Jan 2014 11:24:00 +0100
Message-ID: <01ae01cf0d24$e9d492c0$bd7db840$@it.uc3m.es>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_01AF_01CF0D2D.4BA0C2F0"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQHaNKwdfSYJOwgcxKKswh9HGthMUZpkXnQg
Content-Language: es
X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.0.0.1014-20418.005
X-TM-AS-Result: No--44.993-7.0-31-1
X-imss-scan-details: No--44.993-7.0-31-1
X-Mailman-Approved-At: Thu, 09 Jan 2014 02:44:05 -0800
Subject: Re: [secdir] Secdir review of draft-ietf-savi-send-10
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Thu, 09 Jan 2014 10:24:22 -0000
Hi Vincent, Thank you for your comments. Responses are inline, colored in blue. De: Vincent Roca [mailto:vincent.roca@inria.fr] Enviado el: martes, 07 de enero de 2014 8:59 Para: IESG; draft-ietf-savi-send@tools.ietf.org; secdir@ietf.org CC: Vincent Roca Asunto: Secdir review of draft-ietf-savi-send-10 Hello, 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. IMHO, the document is Almost ready. This i-d contains a detailed Security Consideration sections which is great. However I have a few questions and comments. 1/ Section 5 says: "The interaction in a mixed scenario comprising SEND and non-SEND devices should be addressed in other document." What happens if an attacker behaves as a non-SEND host? Is it sufficient to escape SEND SAVI and launch an attack? This is not said. Yes, this is not said and it should. I have modified the first paragraph to say: SEND SAVI operates only with validated SEND messages. Note that IPv6 packets generated by non-SEND nodes will be discarded by the first SEND SAVI device receiving it. Therefore, attackers cannot obtain any benefit by not using SEND. In order to perform address validation in a mixed scenario comprising SEND and non-SEND devices, a different solution is required, which should be addressed in other document. 2/ Section 5.2 says: "The recommended minimum is the memory needed to store 4 bindings associated to the port." If there are several hosts behind this port (e.g., several hosts behind a hub attached to this switch, or several virtual machines), this value of 4 may not be sufficient. I agree that having per-port buffers is fine, but specifying a value is risky. This text is also included in RFC 6620 (FCFS SAVI) Note that the value specified is a *minimum*, which means that - Implementors of SEND SAVI devices could raise this number, of course, probably depending on the memory they have. - This is the minimum in case malicious nodes are connected to other ports trying to exhaust memory; i.e., there will always be at least 4 bindings, which should be a minimum number of addresses for one basic host (link local address + global unicast address ). Even if this is the minimum being set, when an attack is not occurring more than 4 bindings could be available to certain ports, assuming that the device can store more bindings than 4*number_of_ports. In order to stress the first idea, I have rephrased the paragraph as follows: The recommended minimum is the memory needed to store four bindings associated to the port, although it should be raised if the ratio between the maximum number of bindings allowed in the device and the number of ports is high. By the way, you raise an interesting issue that has not been considered in the previous versions of the document: the virtual machine case. In order to address this, at least cursorily, I have included the following text in section 2.4 Special Cases: Virtual switches: A hypervisor or a host Operating System may perform bridging functions between virtual hosts running on the same machine. The hypervisor or host OS may in turn connect to a SEND SAVI system. This scenario is depicted in the next figure, with two virtual machines VM1 and VM2 connected through a virtual switch VS1 to SEND SAVI device SEND-SAVI1. The attachment points of VS1 to VM1 and VM2 are configured as Validating. Host1 +----------------+ | +---+ +---+ | | |VM1| |VM2| | | +---+ +---+ | | | | | | +-1-----2--+ | | | VS1 | | | +--3-------+ | | | | +----|-----------+ | | +--1-----2--+ | SEND- | | SAVI1 | +--3---4----+ | | In order to provide proper security against replay attacks, it is recommended to perform SEND SAVI filtering as close to untrusted hosts as possible (see Section 3.4 and Section 5.1). In this scenario, this objective can be achieved by enabling SEND SAVI validation in VS1. Ideally, VS1 could be integrated into the SEND SAVI protection perimeter, if the hypervisor or host OS at Host1 can be trusted (even though VM1 and VM2 could not be trusted). To do so, both the attachment to SEND-SAVI1 at VS1, and port 1 at SEND-SAVI1, are configured as Trusted. If the administrator of the network does not trust on VS1, port 1 of SEND-SAVI1 is configured as Validating, so that every address being used at Host1 is validated at SEND-SAVI1 by SEND SAVI. The attachment point to the physical network at VS1 should be configured as Trusted, if the host administrator knows that it is connected to a SEND SAVI device; in this case, VS1 relies on the infrastructure comprised by the physical SEND SAVI devices, but not the other way. Packets egressing from VM1 are validated twice, first at VS1, and then at SEND-SAVI1; packets going in the reverse direction (from an external host to VM1) are validated once, when they first reach a SEND SAVI device. If the administrator of VS1 does not trust on the physical switch to which it attaches, it can configure the attachment to SEND-SAVI1 as Validating. In the figure above, this means that a packet going from another host to VM1 would be validated twice, once when entering the SEND SAVI perimeter formed by the physical devices, and the other when entering at VS1. 3/ Section 5.2 is a bit confusing and I'm wondering if it could not be simplified. Just to provide some background about this section: it is almost the same text as section 4.1 of RFC 6620, since the DoS problems are mostly the same (except for the last paragraph of the section, which insists in the extra cost of cryptographic operations due to the use of SEND. This being said, I do not pretend that RFC6620 text could not be improved. Basically, it says: - in case of memory shortage, it is RECOMMENDED to "delete the entries with a higher Creation time". BTW, what do you mean by "higher creation time"? The oldest entries el? No, the newer ones, as the next sentence clarifies: This implies that older entries are preserved and newer entries overwrite each other. - it is RECOMMENDED to reserve some memory for each port in order to isolate the effects to the attacker's port; - one MUST limit the maximum amount of memory used to store data packets in order to keep memory for other tasks; - one SHOULD rate limit packets which may trigger SEND SAVI events, since it requires costly crypto operations. BTW, why do you say "which may trigger" instead of "which trigger"? I remove may. Your summary is correct. Third paragraph is strange. According to your comments, I have changed the text to (I explain later the changes): The SEND SAVI device may store data packets while the address is being verified, for example, when a DAD_NSOL was lost before arriving to the SEND SAVI device to which the host attaches, and the host sends data packets, these data packets may be stored until the SEND SAVI device verifies the binding by means of a NUD packet exchange. In this case, the memory for data packet storage may also be a target of DoS attacks. A SEND SAVI device MUST limit the amount of memory used to store data packets, allowing the other functions (such as being able to store new bindings) to have available memory even in the case of an attacks such those described above. I read: "As the SEND SAVI device may store data packets while the address is being verified..." If the incoming packet rate is higher than the packet verification rate, sure there will be problems. Is it what the authors mean? I don't see any good solution except rate limiting the incoming packet flow. I think it was not clear enough the case to which we were referring. Thats why I changed the first sentence. What I want to note is that this is a particular case, but not normal operation of the SAVI device, because in most cases (well-behaved hosts), DAD_NSOL is going to be issued first, and the host will not send packets until the address is valid (and so the state at the SEND SAVI devices). However, we do not want malicious nodes to exploit the fact that memory (especially for other more relevant uses, such as storing bindings) could be exhausted in this way. Later: "The effects of such attacks may be limited to the lack of capacity to store new data packets." Does it mean that setting an upper limit to the amount of memory devoted to store data packets is a way to mitigate the attack (last sentence), or does it mean that the attack will lead packets to be dropped (following sentence)? I agree that the two sentences starting by the one you copy here were hard to understand. As you see in the new version of the text (above), I have removed them. What I think is the most relevant problem is that using memory for this could drain resources for other functions, and this is stated in the last sentence. And when it is said that: "A SEND SAVI device MUST limit the amount of memory used to store data packets, allowing the other functions to have available memory even in the case of an attacks..." What do you mean by "other functions"? SEND SAVI functions? Others? I have clarified this in the text 5/ Section 5.4 says that "a SEND SAVI MUST NOT log binding anchor information except [if there's a good reason for that]". And later that "information about the majority of hosts that never spoof SHOULD NOT be logged." The intention is fine, but if I understand correctly, SAVI requires to identify a host's legitimate IP source addresses (RFC 7039). It means that this information will be logged any away as SAVI needs it (if I understand correctly). Or may be by "logging" you mean "long term logging" but in that case this is not clear. Or is there something else I've missed? You are right. I have changed this to A SEND SAVI device MUST delete binding anchor information as soon as possible (i.e., as soon as the state for a given address is back to NO_BIND), except where there is an identified reason why that information is likely to be involved in detection, prevention or tracing of actual source address spoofing. Information about the majority of hosts that never spoof SHOULD NOT be logged. Typos: ** s/reply/replay in: "There are two different cases to analyze when considering SEND SAVI reply attacks:" ** s/In this two cases/In these two cases/ ** s/messages which does not result in changes/messages which do not result in changes/ ** s/in the case of an attacks such those described above/in the case of an attack like the one described above/ Corrected! Thanks again for your comments Alberto
- [secdir] Secdir review of draft-ietf-savi-send-10 Vincent Roca
- Re: [secdir] Secdir review of draft-ietf-savi-sen… Alberto García
- Re: [secdir] Secdir review of draft-ietf-savi-sen… Vincent Roca
- Re: [secdir] Secdir review of draft-ietf-savi-sen… Alberto García
- Re: [secdir] Secdir review of draft-ietf-savi-sen… Vincent Roca