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

[Stephen Farrell <[e-mail]>]

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