[CGA-EXT] Comments on draft-ietf-csi-proxy-send-03

Tony Cheneau <tony.cheneau@it-sudparis.eu> Fri, 09 April 2010 14:33 UTC

Return-Path: <tony.cheneau@it-sudparis.eu>
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 471AE3A68CB for <cga-ext@core3.amsl.com>; Fri, 9 Apr 2010 07:33:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.76
X-Spam-Level:
X-Spam-Status: No, score=-0.76 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HELO_EQ_FR=0.35]
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 kCJoMXwXmrND for <cga-ext@core3.amsl.com>; Fri, 9 Apr 2010 07:33:33 -0700 (PDT)
Received: from smtp4.int-evry.fr (smtp4.int-evry.fr [157.159.10.71]) by core3.amsl.com (Postfix) with ESMTP id 3A1503A6358 for <cga-ext@ietf.org>; Fri, 9 Apr 2010 07:33:33 -0700 (PDT)
Received: from smtp2.int-evry.fr (smtp2.int-evry.fr [157.159.10.45]) by smtp4.int-evry.fr (Postfix) with ESMTP id B2B01FE40FC; Fri, 9 Apr 2010 16:33:28 +0200 (CEST)
Received: from smtp-ext.int-evry.fr (smtp-ext.int-evry.fr [157.159.11.17]) by smtp2.int-evry.fr (Postfix) with ESMTP id 2A5B2404FA7; Fri, 9 Apr 2010 16:33:22 +0200 (CEST)
Received: from [157.159.100.213] (unknown [157.159.100.213]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp-ext.int-evry.fr (Postfix) with ESMTP id 15041900DC; Fri, 9 Apr 2010 16:33:22 +0200 (CEST)
Date: Fri, 09 Apr 2010 16:33:21 +0200
From: Tony Cheneau <tony.cheneau@it-sudparis.eu>
X-X-Sender: shad@whitebox
To: draft-ietf-csi-proxy-send@tools.ietf.org
Message-ID: <alpine.LNX.2.00.1004091544180.9490@whitebox>
User-Agent: Alpine 2.00 (LNX 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format="flowed"; charset="US-ASCII"
X-INT-MailScanner-Information: Please contact the ISP for more information
X-INT-MailScanner-ID: 2A5B2404FA7.A6A70
X-INT-MailScanner: Found to be clean
X-INT-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (not cached, score=-4.399, requis 6.01, autolearn=not spam, ALL_TRUSTED -1.80, BAYES_00 -2.60)
X-INT-MailScanner-From: tony.cheneau@it-sudparis.eu
Cc: CGA-EXT@ietf.org
Subject: [CGA-EXT] Comments on draft-ietf-csi-proxy-send-03
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: Fri, 09 Apr 2010 14:33:34 -0000

Hello,

I read your draft and some comments.

I will start with the "editorial" ones:
- I often read "PSO option", which expends to "Proxy Signature Option
   option". IMHO, "PS option" would be better.
- Section 6.2: "acccording to" => "according to"
- Section 7.2: "these node interpret" => "these nodeS interpret"


One technical comment/question:
- Section 6.2
"  When a MAG replies to a RS with a RA, the source address MUST be
    equal to the MAG link-local address associated to the MN in this
    PMIPv6 domain and its own link layer address as Source link-layer
    address.  Then a timestamp (generated by the proxy) and nonce (if
    appropriate, acccording to [RFC3971]), MUST be included.  Finally, a
    PSO option signing the message MUST be included as the last option of
    the message.  This procedure is followed for any other ND message
    that could be generated by the MAG to a MN. "
I understand from PMIP that the node that moves through the domain sees
only one Link-Local address for all the MAGs. From your SNDP proposal,
the node relies on the RFC 3971 rules to process the timestamp. I mean,
the node could implement the mechanism proposed as a SHOULD in Section
5.3.4.2 of RFC 3971. Here, my concern is that the node will most likely
consider the NDP messages of all the other MAG (after the first one it
met) as replayed packets.

A small example, two MAGs, MAG_A and MAG_B. MAG_B's clock has minus one
minute difference with MAG_A.  MAG_A sends a RA message secured with a
PSO. The nodes verifies it and record a RDlast and TSlast value (as per
RFC 3971). The node moves and MAG_B sends a RA message.  The node read
the Timestamp option and compares it with its RDlast and TSlast value.
The message is rejected as it looks like a replayed message.

Or maybe I missed the part that says the clocks are implicitly
synchronised (or something else) ? Either way, could you clarify the
situation for me and maybe add some text in the draft about this ?

Apart from the minor points I noted, the overall document is in a very good
shape.

(Also, sorry for my late reply to this WGLC)

Hope it helps.

Regards,
 	Tony