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

[Jouni Korhonen <[e-mail]>]

Stephen,

On Sep 24, 2013, at 3:56 PM, Stephen Farrell <[e-mail]> 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" <[e-mail]> 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.
>>> 
>>> 
>>