IETF Logo Mail Archive

[CGA-EXT] Question about RS/RA protection w/ SEND

arno@natisbad.org (Arnaud Ebalard) Mon, 10 August 2009 13:12 UTC

Return-Path: <arno@natisbad.org>
X-Original-To: cga-ext@core3.amsl.com
Delivered-To: cga-ext@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78A2A3A68B2 for <cga-ext@core3.amsl.com>; Mon, 10 Aug 2009 06:12:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.564
X-Spam-Level:
X-Spam-Status: No, score=-3.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kx78shXi4b15 for <cga-ext@core3.amsl.com>; Mon, 10 Aug 2009 06:12:25 -0700 (PDT)
Received: from copper.chdir.org (copper.chdir.org [88.191.97.87]) by core3.amsl.com (Postfix) with ESMTP id 48F6C3A6C1E for <cga-ext@ietf.org>; Mon, 10 Aug 2009 06:12:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=natisbad.org; s=mail; h=From:To:Cc:Subject:Date:Message-ID: MIME-Version:Content-Type; bh=wAFoE+03mzveYJETBOeVOVRk6z98A+I8E7 5OwazZ6pQ=; b=JfWMZZFbgLxWV6qtYKCaXapqeTcRz+idOwjyY10pAc4HFIfqff zGzNJIu17jmTwCOYQ30yHL3CKD/iJMuURAzqvSSQRiFaP4jMF7jCS5JuIewH2/Ld CxEMqq1UpmdnLGO0hE06kKwYvSyHy0YuBxoO12ra/GfU8NFgl4mNCjiWg=
Received: from [2001:7a8:78df:2:20d:93ff:fe55:8f79] (helo=small.ssi.corp) by copper.chdir.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <arno@natisbad.org>) id 1MaUfp-0006jp-LI; Mon, 10 Aug 2009 15:12:25 +0200
X-Hashcash: 1:20:090810:elevyabe-fyb4gu1cfyuavxtiumwx3w@public.gmane.org::O7VaTwRj2qUJDtim:00000000000000jO9
X-Hashcash: 1:20:090810:cga-ext@ietf.org::Z2GXXUt3wNOLsFMQ:00ixT
From: arno@natisbad.org
To: Eric Levy-Abegnoli <elevyabe-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org>
X-PGP-Key-URL: http://natisbad.org/arno@natisbad.org.asc
X-Fingerprint: 47EB 85FE B99A AB85 FD09 46F3 0255 957C 047A 5026
Date: Mon, 10 Aug 2009 15:13:04 +0200
Message-ID: <8763cv95i7.fsf@small.ssi.corp>
User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/23.0.92 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Cc: cga-ext@ietf.org
Subject: [CGA-EXT] Question about RS/RA protection w/ SEND
X-BeenThere: cga-ext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: CGA and SeND Extensions <cga-ext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/cga-ext>, <mailto:cga-ext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/cga-ext>
List-Post: <mailto:cga-ext@ietf.org>
List-Help: <mailto:cga-ext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cga-ext>, <mailto:cga-ext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 10 Aug 2009 13:12:26 -0000

Hi Eric,

I'd be interested by your (implementor) thoughts on the following if you 
have some time.

I thought SEND specification (RFC 3971) would support the following
scenario but in the end, it is unclear (I would say the spec is
contradictory on that aspect):

  A MIPv6 MN with partial support for SEND: it supports only the
  certificate-based part of the spec and knows nothing about CGA. It is
  configured with trust anchors and supports sending RS with Timestamp
  and Nonce option. It would allow it to verify RA messages sent by
  SEND-enabled routers. One possible interest of such a mode is for
  securing the MIPv6 home link detection mechanism (see [1] for
  rationale).

In the specification, we have the following:

  Section 5.3.3:

  "If the node has been configured to use SEND, all advertisements sent
  in reply to a solicitation MUST include a Nonce, copied from the
  received solicitation. Note that routers may decide to send a
  multicast advertisement to all nodes instead of a response to a
  specific host.  In such a case, the router MAY still include the nonce
  value for the host that triggered the multicast
  advertisement. (Omitting the nonce value may cause the host to ignore
  the router's advertisement, unless the clocks in these nodes are  
  sufficiently synchronized so that timestamps function properly.)"


  Section 8:

   o  Unsolicited advertisements sent by a SEND node MUST be secured.

   o  A SEND node MUST send a secured advertisement in response to a
      secured solicitation.  Advertisements sent in response to an
      unsecured solicitation MUST be secured as well, but MUST NOT
      contain the Nonce option.

I may have missed something in the specification but it seems both
sections are contradictory on that aspect.

So, what is a SEND router expected to do when receiving a unsecured RS
with a Timestamp and a Nonce option?

Cheers,

a+

[1]: http://tools.ietf.org/html/draft-ebalard-mext-hld-security-00

v2.23.0 | Report a Bug | By Email