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

From: "Stephen Farrell" <[email-masked]>
Date: Tue, 24 Sep 2013 03:38:19 -0700

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.

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Tue, 24 Sep 2013 12:53:06 +0000

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. 

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

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 24 Sep 2013 13:56:27 +0100

Hiya,

> handling/validation is happening at the correct layers and no new checks

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.

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Tue, 24 Sep 2013 13:27:43 +0000

Stephen,

>Perhaps those checks are already needed. What is currently done

Not beyond ensuring that the MH message that made it to the MIP layer had
IPSec protection. There are no special interactions between MIP and IPsec
layer, at least not in PMIP. For CMIP, there is lot of dance in 5555, for
supporting NAT traversalŠthere they both almost live together ...

>re-negotiation is more likely when pushing notifications.

Can rephrase this to suggest, "currently established Security Association
for protecting PBU/PBA Š"

Regards
Sri

---

From: Jouni Korhonen <[email-masked]>
Date: Tue, 24 Sep 2013 16:38:17 +0300

Stephen,

> Perhaps those checks are already needed. What is currently done

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