[secdir] Secdir review of draft-ietf-mboned-ssmping-08

Vincent Roca <vincent.roca@inrialpes.fr> Tue, 12 July 2011 08:07 UTC

Return-Path: <vincent.roca@inrialpes.fr>
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 1A23121F8EA4; Tue, 12 Jul 2011 01:07:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.027
X-Spam-Level:
X-Spam-Status: No, score=-10.027 tagged_above=-999 required=5 tests=[AWL=0.222, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MA0+VZLXxdOu; Tue, 12 Jul 2011 01:07:10 -0700 (PDT)
Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by ietfa.amsl.com (Postfix) with ESMTP id 9274821F8E8B; Tue, 12 Jul 2011 01:07:09 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.65,520,1304287200"; d="scan'208";a="98392961"
Received: from geve.inrialpes.fr ([194.199.24.116]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/AES128-SHA; 12 Jul 2011 10:07:07 +0200
From: Vincent Roca <vincent.roca@inrialpes.fr>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Tue, 12 Jul 2011 10:07:07 +0200
Message-Id: <F9C370DA-36BD-408D-8B03-918612DE5BD5@inrialpes.fr>
To: IESG <iesg@ietf.org>, secdir@ietf.org, draft-ietf-mboned-ssmping.all@tools.ietf.org
Mime-Version: 1.0 (Apple Message framework v1084)
X-Mailer: Apple Mail (2.1084)
Subject: [secdir] Secdir review of draft-ietf-mboned-ssmping-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
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: Tue, 12 Jul 2011 08:07:11 -0000

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.


After having read the security section and several parts of the
document, I have noticed several small, easy to fix, incoherencies.
More precisely:

** Section 9 says:
        "The worst case is if the host receiving the unicast Echo Replies also
         happens to be joined to the multicast group used."
   Yes in case of an ASM session, no in case of an SSM session
   (unless the server is also the SSM source, of course). This should
   be clarified.

** Section 9 says:
        "...responding to at most one Echo Request per second."
   It should be clarified that this is one response per second per client.
   BTW, I'm also wondering if there should not be a global rate limitation,
   in addition to the per-client rate limitation.

** Section 9 says:
        "The server SHOULD then only respond to Echo
         Request messages that have a valid Session ID associated with the
         source IP address of the Echo Request."
   How should the server behave if the Session ID is not valid?
   This is not clarified whereas this is a critical aspect.

** Section 9 says:
   Rather than saying "how spoofing can be prevented", I'd rather
   say "how spoofing can be mitigated" since spoofing is NOT
   prevented with this approach.

   Note also that an attacker that is on the path between a client
   and a server may eavesdrop the traffic, learn a valid Session ID,
   and if he can use spoofing, he can also continue generating Echo
   Requests until the Session ID validity period times out... A note
   may be added to clarify that this is by no means a definite security
   mechanism.

** Section 9, 2nd paragraph:
   It's clear that group management is critical with ASM, and that
   the multicast IP address range used for multicast ping SHOULD be
   disjoint from those used for data sessions. There is no clear
   recommendation though. I suggest to add some text here.

** Section 9 says:
        "The main concern is bandwidth."
   Is it really "the main concern"? I'm not sure. Disturbing an ASM
   data session with Echo Response traffic (when feasible) is a serious
   concern, since Echo Response traffic may be misinterpreted by the
   receivers.

** Section 3.3:
   When describing the format of the "Server Response, type 83", there
   should be a note that a Session ID option SHOULD be included, since
   this is the only way for a server to communicate this option.

** Section 4, "Client behaviour": must -> MUST in:
        "If the Server Response contained a Session ID, then it
         must also include that, with the exact same value, in the Echo
         Requests."

** Section 5, "Server Behaviour", says:
        "When the server receives an Echo Request message, it may first check
         that the group address and Session ID (if provided) are valid."
   This is a "MUST"!!! If the Session ID is used, the server has no
   choice but checking it during the first processing stages.

** Section 5: should -> SHOULD in:
        "The server should additionally include a Session ID."

** Section 3.2 "Defined options"
   I didn't find any information for the Session ID format.
   Is there any recommendation? Is a 16-bit or 32-bit field
   format recommended? Why?

** Section 5 says:
        "Note that the server may receive Echo Request messages with no prior
         Init message.  This may happen when the server restarts or if a
         client sends an Echo Request with no prior Init message.  The server
         may go ahead and respond if it is okay with the group used.  If the
         group is not okay, the server sends back a Server Response."

   This "may go ahead and respond" is in total contradiction with 
   the security recommendations. Using a Session ID is a "SHOULD", and
   it is allowed to ignore this recommendation only in rare circumstances.
   A few ping requests may fail if the server is restarted, sure, but
   this will only be a transitory problem, so it's not a big deal. 

   I'm also wondering if the "sends back a Server Response" strategy is
   appropriate. With this "Response", an attacker that spoofs the IP address
   of a target has a way to oblige a server to send back a UDP packet to
   the target. It's questionable.


Regards,

  Vincent