Re: [secdir] Secdir review of draft-ietf-savi-send-10

Alberto García <> Thu, 09 January 2014 10:24 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id BA0AD1AE1AE; Thu, 9 Jan 2014 02:24:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.772
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IrrcWIPalz0v; Thu, 9 Jan 2014 02:24:15 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 71BA71AE1F7; Thu, 9 Jan 2014 02:24:10 -0800 (PST)
Received: from (localhost []) by (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 []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id 8579111BF902; Thu, 9 Jan 2014 11:24:00 +0100 (CET)
From: =?iso-8859-1?Q?Alberto_Garc=EDa?= <>
To: "'Vincent Roca'" <>, "'IESG'" <>, <>, <>
References: <>
In-Reply-To: <>
Date: Thu, 9 Jan 2014 11:24:00 +0100
Message-ID: <01ae01cf0d24$e9d492c0$bd7db840$>
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-
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-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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 [] 
Enviado el: martes, 07 de enero de 2014 8:59
Para: IESG;;
CC: Vincent Roca
Asunto: Secdir review of draft-ietf-savi-send-10



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


   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



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

attached to this switch, or several virtual machines), this value of 4 may

be sufficient. I agree that having per-port buffers is fine, but specifying

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


   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.
       | +---+   +---+  |
       | |VM1|   |VM2|  |
       | +---+   +---+  |
       |   |     |      |
       | +-1-----2--+   |
       | |   VS1    |   |
       | +--3-------+   |
       |    |           |
         |   SEND-   |
         |   SAVI1   |
            |   |
   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


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

   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,

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. That’s
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.



   "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

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



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

except [if there's a good reason for that]". And later that "information

the majority of hosts that never spoof SHOULD NOT be logged."


The intention is fine, but if I understand correctly, SAVI requires to

a host's legitimate IP source addresses (RFC 7039). It means that this

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.





** 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/



Thanks again for your comments