Re: [netext] Stephen Farrell's Discuss on draft-ietf-netext-update-notifications-08: (with DISCUSS and COMMENT)

Jouni Korhonen <jouni.nospam@gmail.com> Tue, 24 September 2013 13:38 UTC

Return-Path: <jouni.nospam@gmail.com>
X-Original-To: netext@ietfa.amsl.com
Delivered-To: netext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9F7811E8120; Tue, 24 Sep 2013 06:38:48 -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=[AWL=-0.000, 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 xedvbm-4rQNp; Tue, 24 Sep 2013 06:38:45 -0700 (PDT)
Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) by ietfa.amsl.com (Postfix) with ESMTP id 5793511E8137; Tue, 24 Sep 2013 06:38:40 -0700 (PDT)
Received: by mail-lb0-f177.google.com with SMTP id w7so3754920lbi.36 for <multiple recipients>; Tue, 24 Sep 2013 06:38:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=3LzN6pTKv6uUaQL1FZ9N1V3RKboRhWhpMOE3Y5fXVTw=; b=L/Ib1Z66YhUiwHuRtSsfwDJZGGocEPAZmyV8giAPVtuccdx54p16LFySXbMlOD07Q+ KFxEqGIoh0oSPBUNj0Fy33SJo0ANrQ390kxTQmF/OdQ3Q09QoPKP0gxRFs6rSyY/XVpC 95qSiFk6XvqAW8TtCHP7ZxDH9yBNJVTY4IPJ3N1gPRKpY971QN7wMMTTY3EVzBZs3JXw eEvuq4r648R+gfORBOzOwxNsz2pyKJf5dTBwtJMlXjWLqHu2e85zZyBKlCGwGV89aLve KPodHXFToRilvgRDg+TwXVbc2Kt8rzAcTZ/dreViHeMfxMxJoXiCmECWIxRec0Uogrdr M5cw==
X-Received: by 10.112.156.166 with SMTP id wf6mr24329204lbb.13.1380029919158; Tue, 24 Sep 2013 06:38:39 -0700 (PDT)
Received: from [192.168.43.158] (84-230-145-25.elisa-mobile.fi. [84.230.145.25]) by mx.google.com with ESMTPSA id ua4sm15385904lbb.17.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 24 Sep 2013 06:38:38 -0700 (PDT)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Jouni Korhonen <jouni.nospam@gmail.com>
In-Reply-To: <52418BFB.4050108@cs.tcd.ie>
Date: Tue, 24 Sep 2013 16:38:17 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <3FF53F50-B0B1-4979-91ED-06748BBC430B@gmail.com>
References: <24C0F3E22276D9438D6F366EB89FAEA81172A0AA@xmb-aln-x03.cisco.com> <52418BFB.4050108@cs.tcd.ie>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
X-Mailer: Apple Mail (2.1510)
Cc: "netext@ietf.org" <netext@ietf.org>, "draft-ietf-netext-update-notifications@tools.ietf.org" <draft-ietf-netext-update-notifications@tools.ietf.org>, The IESG <iesg@ietf.org>, "netext-chairs@tools.ietf.org" <netext-chairs@tools.ietf.org>
Subject: Re: [netext] Stephen Farrell's Discuss on draft-ietf-netext-update-notifications-08: (with DISCUSS and COMMENT)
X-BeenThere: netext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netext>
List-Post: <mailto:netext@ietf.org>
List-Help: <mailto:netext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 24 Sep 2013 13:38:49 -0000

Stephen,

On Sep 24, 2013, at 3:56 PM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:

> 
> Hiya,
> 
> On 09/24/2013 01:53 PM, Sri Gundavelli (sgundave) wrote:
>> Hi Stephen,
>> 
>> Thanks for the reviews.
>> 
>> 
>>> 5.2: What happens if the IPsec SA is re-negotiated
>> 
>> Renegotiation of IPSec SA should result in updated SPD and PAD entries at
>> both the peers. Wondering, if MAG/LMA entities need to be aware of this,
>> or assume IKEv2/IPsec layer is handling that. SA Renegotiation could
>> potentially occur in the base protocol without this extension as well. I'm
>> thinking, as long as the SPD entries cover the new MH type, the
>> handling/validation is happening at the correct layers and no new checks
>> are needed. 
> 
> Perhaps those checks are already needed. What is currently done
> in implementations?

PMIP and IPsec layers are separate. And rekeying the SA does not
affect the operation nor the PMIP layer knows about it. The operation
does not differ from normal IPsec behavior.

- Jouni

> But is the current text about "same SA" correct? I don't recall
> such text in the base spec, but maybe its there. And presumably
> re-negotiation is more likely when pushing notifications.
> 
> S.
> 
>> 
>> 
>> 
>> 
>>> - 4.1: What does "ANI-PARAMS-REQUESTED" mean? Probably all these reasons
>>> need an explanation and/or (forward) reference.
>> 
>> 
>> This is a request for updated Access Network Identifier parameters.
>> Section 6.1 has some text for each of the NR codes.
>> 
>> *  If the Notification Reason is set to a value of (4) "ANI-
>>         PARAMS-REQUESTED", then the mobile access gateway MUST send a
>>         Proxy Binding Update message to the local mobility anchor with
>>         the Access Network Identifier Option [RFC6757
>> <http://tools.ietf.org/html/rfc6757>].  The Access
>>         Network Identifier option MUST reflect the current access
>>         network parameters for that mobility session as known to the
>>         mobile access gateway at the time of sending the Proxy Binding
>>         Update message.
>> 
>> 
>> 
>> 
>> 
>> Regards
>> Sri
>> 
>> 
>> 
>> On 9/24/13 3:38 AM, "Stephen Farrell" <stephen.farrell@cs.tcd.ie> wrote:
>> 
>>> Stephen Farrell has entered the following ballot position for
>>> draft-ietf-netext-update-notifications-08: Discuss
>>> 
>>> When responding, please keep the subject line intact and reply to all
>>> email addresses included in the To and CC lines. (Feel free to cut this
>>> introductory paragraph, however.)
>>> 
>>> 
>>> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
>>> for more information about IESG DISCUSS and COMMENT positions.
>>> 
>>> 
>>> The document, along with other ballot positions, can be found here:
>>> http://datatracker.ietf.org/doc/draft-ietf-netext-update-notifications/
>>> 
>>> 
>>> 
>>> ----------------------------------------------------------------------
>>> DISCUSS:
>>> ----------------------------------------------------------------------
>>> 
>>> 
>>> 5.2: What happens if the IPsec SA is re-negotiated
>>> automatically? Isn't there a potential layering/sync problem
>>> so that these notifications couldn't ever be verified since a
>>> new SA would be in use? I think you just need to say the same
>>> or an automatically renegotiated SA (not sure what's the
>>> right terminology, sorry). I think 6.1 has the same issue and
>>> maybe other bits too. That kind of check also seems to
>>> imply that the interface between the MAG or LMA and the
>>> IPsec code needs to know that the right SA is being used
>>> which could be tricky. What's really done here?
>>> 
>>> 
>>> ----------------------------------------------------------------------
>>> COMMENT:
>>> ----------------------------------------------------------------------
>>> 
>>> 
>>> - 4.1: What does "ANI-PARAMS-REQUESTED" mean? Probably all
>>> these reasons need an explanation and/or (forward) reference.
>>> 
>>> 
>>