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

Alberto García <alberto@it.uc3m.es> Mon, 12 April 2010 09:45 UTC

Return-Path: <alberto@it.uc3m.es>
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 A3A3E3A68B6 for <cga-ext@core3.amsl.com>; Mon, 12 Apr 2010 02:45:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.44
X-Spam-Level:
X-Spam-Status: No, score=-4.44 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
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 t9BMoGSocXQ3 for <cga-ext@core3.amsl.com>; Mon, 12 Apr 2010 02:45:35 -0700 (PDT)
Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 720A83A6885 for <CGA-EXT@ietf.org>; Mon, 12 Apr 2010 02:45:35 -0700 (PDT)
X-uc3m-safe: yes
Received: from bombo (bombo.it.uc3m.es [163.117.139.125]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by smtp03.uc3m.es (Postfix) with ESMTP id BA3B37F7109; Mon, 12 Apr 2010 11:45:27 +0200 (CEST)
From: =?ISO-8859-15?Q?Alberto_Garc=EDa?= <alberto@it.uc3m.es>
To: "'Laganier, Julien'" <julienl@qualcomm.com>, "'Tony Cheneau'" <tony.cheneau@it-sudparis.eu>, <draft-ietf-csi-proxy-send@tools.ietf.org>
References: <alpine.LNX.2.00.1004091544180.9490@whitebox> <BF345F63074F8040B58C00A186FCA57F1C6AB47DA4@NALASEXMB04.na.qualcomm.com>
Date: Mon, 12 Apr 2010 11:45:28 +0200
Message-ID: <0C39EF7014494124B7C78166C798CC58@bombo>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-15"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <BF345F63074F8040B58C00A186FCA57F1C6AB47DA4@NALASEXMB04.na.qualcomm.com>
Thread-Index: AcrX8aQGya+YtVDLQo2KS5wPuemKpwAQ8PiAAHokygA=
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17162.002
Cc: CGA-EXT@ietf.org
Subject: Re: [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: Mon, 12 Apr 2010 09:45:36 -0000

Hi

|  -----Mensaje original-----
|  De: Laganier, Julien [mailto:julienl@qualcomm.com]
|  Enviado el: sábado, 10 de abril de 2010 0:51
|  Para: Tony Cheneau; draft-ietf-csi-proxy-send@tools.ietf.org
|  CC: CGA-EXT@ietf.org
|  Asunto: RE: [CGA-EXT] Comments on draft-ietf-csi-proxy-send-03
|  
|  Tony,
|  
|  Thanks for reviewing the draft. I'm following up on the timestamp issues
you're
|  pointing at below.
|  
|  Tony Cheneau wrote:
|  >
|  > [...]
|  >
|  > 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 ?
|  
|  PMIPv6 relies to a large extent on the use of Timestamps in Proxy Binding
|  Updates. AFAIK there are no potential use of PMIPv6 that relies on
sequence
|  numbers for PBU re-ordering. When PMIPv6 use timestamps, the clocks on
the
|  MAGs have to be synchronized.
|  
|  In addition, I am also unsure that there is a practical problem. The
timestamp is
|  only used for verifications of unsolicited messages. Since unsolicited
router
|  advertisements are only send periodically, it seems to me that they will
not be
|  sent often enough for the issue you describe to occur.

Yes, although in any case I think it is still a good approach to state that
timestamps are only meaningful when coming from the same source, as stated
before. 
Secure Proxy ND could be used for other scenarios in which problems may
arise.

Regards,
Alberto

|  
|  ( and even my phone runs NTP today :)
|  
|  --julien