Re: [Mip4] One implementation of RREQ/RREP time synchronization

"Charles E. Perkins" <charliep@computer.org> Thu, 21 March 2013 16:28 UTC

Return-Path: <charliep@computer.org>
X-Original-To: mip4@ietfa.amsl.com
Delivered-To: mip4@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B337721F8168 for <mip4@ietfa.amsl.com>; Thu, 21 Mar 2013 09:28:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I4+r7AzOCjsi for <mip4@ietfa.amsl.com>; Thu, 21 Mar 2013 09:28:58 -0700 (PDT)
Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by ietfa.amsl.com (Postfix) with ESMTP id 7751121F8DFA for <mip4@ietf.org>; Thu, 21 Mar 2013 09:28:54 -0700 (PDT)
Received: from [130.129.48.15] (helo=[172.16.1.120]) by elasmtp-junco.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from <charliep@computer.org>) id 1UIiMH-0000er-RZ; Thu, 21 Mar 2013 11:28:53 -0500
Message-ID: <514B4335.2040107@computer.org>
Date: Thu, 21 Mar 2013 10:28:21 -0700
From: "Charles E. Perkins" <charliep@computer.org>
Organization: Saratoga Blue Skies
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
To: Alexandru Petrescu <alexandru.petrescu@gmail.com>
References: <514B2C6E.5020803@gmail.com>
In-Reply-To: <514B2C6E.5020803@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad8667053d3e88eed8c45142e65f6c0e5214350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 130.129.48.15
Cc: Mobile IPv4 Mailing List <mip4@ietf.org>
Subject: Re: [Mip4] One implementation of RREQ/RREP time synchronization
X-BeenThere: mip4@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobility for IPv4 <mip4.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mip4>, <mailto:mip4-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mip4>
List-Post: <mailto:mip4@ietf.org>
List-Help: <mailto:mip4-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mip4>, <mailto:mip4-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Mar 2013 16:28:59 -0000

Hello Alexandru,

The existing specification does not require NTP.  I think that it's not
required for replay protection, and that your suggested method
should be fine.  I don't think there should be any additional
protocol mandates placed on MIPv4, especially after so much time,
and that it would cause many existing implementations to become
non-compliant.

Regards,
Charlie P.


On 3/21/2013 8:51 AM, Alexandru Petrescu wrote:
> The specification RFC 5944 "Mobile IPv4" has a textual description about
> an error Code 133 'Denied by home agent, registration Identification
> mismatch'.  This is sent by the HA to MR when the MR's time is way back
> (or ahead) in time, like after having lost power.
>
> However, the spec doesn't say that the MR SHOULD send a new RREQ to the
> HA, and not neither does it say what to put in that RREQ.
>
> We wrote an implementation of a method to realize this: MR receive Code
> 133, update its time, send a new RREQ; this method is based on the
> discussion in this email list MIP4.
>
>   This code is executed in MR:
>   t0 = time (); obtain time of this computer
>   ID1 = t0;
>   Send to HA RREQ containing ID1;
>   Receive RREP Code-133, and extract ID2=RREP.Identification;
>   t1 = time ();
>   set local time on MR to be time()+(ID2-ID1)-(t1-t0)/2;
>   send RREQ to HA containing updated time;
>   receive RREP with Code = 0 (successful).
>
> This interoperates ok with a Home Agent from manufacturer.
>
> Remark there is a speculation at the calculation of time (t1-t0)/2 which
> means half of the total RTT.  But never an RTT is precisely half-half.
>
> We are not sure it is a good thing to synchronize time this way (rather
> than say NTP), and we are not sure either whether it is secure enough.
>
> Alex
>


-- 
Regards,
Charlie P.