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

Stephen Farrell <stephen.farrell@cs.tcd.ie> Tue, 24 September 2013 12:56 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
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 8218011E812A; Tue, 24 Sep 2013 05:56:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.799
X-Spam-Level:
X-Spam-Status: No, score=-102.799 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 JMhqpvBfqHNR; Tue, 24 Sep 2013 05:56:35 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id DF72B11E811F; Tue, 24 Sep 2013 05:56:28 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 8F5FFBE57; Tue, 24 Sep 2013 13:56:27 +0100 (IST)
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 89wV5ETn9V0L; Tue, 24 Sep 2013 13:56:27 +0100 (IST)
Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 6A836BE47; Tue, 24 Sep 2013 13:56:27 +0100 (IST)
Message-ID: <52418BFB.4050108@cs.tcd.ie>
Date: Tue, 24 Sep 2013 13:56:27 +0100
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0
MIME-Version: 1.0
To: "Sri Gundavelli (sgundave)" <sgundave@cisco.com>, The IESG <iesg@ietf.org>
References: <24C0F3E22276D9438D6F366EB89FAEA81172A0AA@xmb-aln-x03.cisco.com>
In-Reply-To: <24C0F3E22276D9438D6F366EB89FAEA81172A0AA@xmb-aln-x03.cisco.com>
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: "netext@ietf.org" <netext@ietf.org>, "draft-ietf-netext-update-notifications@tools.ietf.org" <draft-ietf-netext-update-notifications@tools.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 12:56:48 -0000

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?

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.
>>
>>
>