Re: [MEXT] Comments on draft-ietf-mext-binding-revocation-02

To: "Ahmad Muhanna" <amuhanna at nortel.com>
Subject: Re: [MEXT] Comments on draft-ietf-mext-binding-revocation-02
From: "Stupar, Patrick" <pstupar at qualcomm.com>
Date: Fri, 16 Jan 2009 17:17:31 -0000
Cc: mext at ietf.org
Delivered-to: ietfarch-mip6-web-archive at core3.amsl.com
Delivered-to: mext at core3.amsl.com
Dkim-signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=pstupar at qualcomm.com; q=dns/txt; s=qcdkim; t=1232126326; x=1263662326; h=x-mimeole:content-class:mime-version:content-type: content-transfer-encoding:subject:date:message-id: in-reply-to:x-ms-has-attach:x-ms-tnef-correlator: thread-topic:thread-index:references:from:to:cc: x-originalarrivaltime:x-ironport-av; z=X-MimeOLE:=20Produced=20By=20Microsoft=20Exchange=20V6.5 |Content-class:=20urn:content-classes:message |MIME-Version:=201.0|Content-Type:=20text/plain=3B=0D=0A =09charset=3D"us-ascii"|Content-Transfer-Encoding:=20quot ed-printable|Subject:=20RE:=20Comments=20on=20draft-ietf- mext-binding-revocation-02|Date:=20Fri,=2016=20Jan=202009 =2017:17:31=20-0000|Message-ID:=20<A39C75E50DED4C43A4B0EA 9B51B0B6B34DE379 at EUEX02.eu.qualcomm.com>|In-Reply-To:=20< C5A96676FCD00745B64AE42D5FCC9B6E1C7307B3 at zrc2hxm0.corp.no rtel.com>|X-MS-Has-Attach:=20|X-MS-TNEF-Correlator:=20 |Thread-Topic:=20Comments=20on=20draft-ietf-mext-binding- revocation-02|Thread-Index:=20AclbLn3taqHuU6TUSgeN3dxQhl2 ykQArrD7gALKdDZAEWRBysAGXgEdQ|References:=20<A39C75E50DED 4C43A4B0EA9B51B0B6B340478F at EUEX02.eu.qualcomm.com>=20<C5A 96676FCD00745B64AE42D5FCC9B6E1C2CF213 at zrc2hxm0.corp.norte l.com>=20<A39C75E50DED4C43A4B0EA9B51B0B6B3404AC6 at EUEX02.e u.qualcomm.com>=20<C5A96676FCD00745B64AE42D5FCC9B6E1C7307 B3 at zrc2hxm0.corp.nortel.com>|From:=20"Stupar,=20Patrick" =20<pstupar at qualcomm.com>|To:=20"Ahmad=20Muhanna"=20<amuh anna at nortel.com>|Cc:=20<mext at ietf.org> |X-OriginalArrivalTime:=2016=20Jan=202009=2017:18:44.0805 =20(UTC)=20FILETIME=3D[7C540750:01C977FE]|X-IronPort-AV: =20E=3DMcAfee=3Bi=3D"5100,188,5497"=3B=20a=3D"14701916"; bh=MXGKfQt7+vZmkWwWcUWnbea0ih33vXTx5XqOeBrShWk=; b=NG8FaJ/Z4pPQziXRaHGov2UGj+PTpXfkRvhS4mtYYKuzvfGXUApK5wwN hSY6gj9oP8wbOzhp62jEa6zi/x6oAL1ZBad6J7Z/drsvlIejCCEZr31JL zVdh+IcHyc9As/0RKFN2VEF+9JID/yhhtsraQCYLnXWJNGfdNH4SiLC7T 4=;
In-reply-to: <C5A96676FCD00745B64AE42D5FCC9B6E1C7307B3 at zrc2hxm0.corp.nortel.com>
List-archive: <http://www.ietf.org/pipermail/mext>
List-help: <mailto:mext-request@ietf.org?subject=help>
List-id: Mobile IPv6 EXTensions WG <mext.ietf.org>
List-post: <mailto:mext@ietf.org>
List-subscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=subscribe>
List-unsubscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=unsubscribe>
References: <A39C75E50DED4C43A4B0EA9B51B0B6B340478F at EUEX02.eu.qualcomm.com> <C5A96676FCD00745B64AE42D5FCC9B6E1C2CF213 at zrc2hxm0.corp.nortel.com> <A39C75E50DED4C43A4B0EA9B51B0B6B3404AC6 at EUEX02.eu.qualcomm.com> <C5A96676FCD00745B64AE42D5FCC9B6E1C7307B3 at zrc2hxm0.corp.nortel.com>
Sender: mext-bounces at ietf.org
Thread-index: AclbLn3taqHuU6TUSgeN3dxQhl2ykQArrD7gALKdDZAEWRBysAGXgEdQ
Thread-topic: Comments on draft-ietf-mext-binding-revocation-02

Hi Ahmad

I think most of the discussion we had is solved. Please find one last
comment below.

Best Regards,

Patrick 

> -----Original Message-----
> From: Ahmad Muhanna [mailto:amuhanna at nortel.com]
> Sent: Tuesday, January 06, 2009 4:23 PM
> To: Stupar, Patrick
> Cc: mext at ietf.org
> Subject: RE: Comments on draft-ietf-mext-binding-revocation-02
> 
> Hi Patrick,
> It seems that I never responded to your responses.
> Please see responses inline.
> 
> Regards,
> Ahmad
> 
> > >
> > > > -----Original Message-----
> > > > From: Stupar, Patrick [mailto:pstupar at qualcomm.com]
> > > > Sent: Wednesday, December 10, 2008 7:19 PM
> > > > To: Muhanna, Ahmad (RICH1:2H10)
> > > > Cc: mext at ietf.org
> > > > Subject: Comments on draft-ietf-mext-binding-revocation-02
> > > >
> > > > Hi Ahmad,
> > > >
> > > > I have reviewed binding revocation draft and have the following
> > > > comments/questions.
> > > >
> > > > - In MIPv6, Binding Update and Binding Ack have two different MH
> > > > type values. Why isn't the same approach taken for BRI
> > and BRA and
> > > > only one value is used?
> > >
> > > [Ahmad]
> > > This was discussed on the mailing list for a long time and
> > agreed that
> > > using one MH type will help in preserving the MH type
> > space. I believe
> > > the "Heartbeat Mechanism for PMIPv6" is a wg doc in Netlmm
> > and use one
> > > MH type for the Request and Response. On the other hand, do see an
> > > issue or problem in having a single MH type for both messages?
> >
> > [Patrick] If the WG is worried about MH type space then I am
> > fine with the proposed message format.
> >
> > >
> > > >
> > > > - BRI has a revocation trigger field which is used for two main
> > > > usages.
> > > > One is the provisioning of the reason why the revocation was
sent
> > > > (e.g.
> > > > inter-MAG handoff) and the other is related to specific binding
> > > > revocation procedures (e.g. IPV4 HoA Binding only,
> > Per-Peer Policy).
> > > > I think it would be cleaner if the two concepts remain
> > separated in
> > > > the messages, for instance defining additional flags for
Per-peer
> > > > policy or
> > > > IPv4 HoA Binding only.
> > >
> > > [Ahmad]
> > > I see what you are saying. However, as you said, the Revocation
> > Trigger
> > > field is defined to give the reason which caused the
> > revoking node to
> > > send the BRI message. Thus far, I believe all of the defined
values
> > are
> > > inline with that definition or reasoning. For example: When the
LMA
> > > sets the R. Trigger value to "IPv4 HoA Binding Only" it
> > means that the
> > > reason behind sending this BRI message is to revoke the IPv4 HoA
> > > address in the case that the MN is assigned two proxy
> > HoA(v4 & v6) for
> > > the same pCoA.
> > > I
> > > do not see this as a policy decision, because it is no
> > difference from
> > > the MAG sending a BRI with R. Trigger value is set to for example,
> > > "Access Network Session Termination"
> > >
> > > As for the R. Trigger value of "Per-Peer Policy", This is only
> > > restricted to Global Revocation when the (G) bit is set. I still
> > > believe that "Per-Peer policy" also indicate the reason
> > that allowed
> > > the LMA
> > to
> > > send this Global BRI. Do you have a different name for this
> > R. Trigger
> > > value that would fit better?
> > >
> >
> > [Patrick]IMHO "IPv4 HoA Binding Only" is not the reason that
> > triggered the BRI, it's the action that the MN is requested
> > to perform. Anyhow, my concerns were not related to the list
> > of reasons in the revocation trigger, but to the fact that
> > some values of the field imply some actions and other values
> > don't. My suggestion is that the actions are taken by MN and
> > HA based on flags (e.g. Global Revocation) and not on the
> > revocation trigger. Only the case of "IPv4 HoA Binding Only"
> > lacks of a proper flag.
> 
> [Ahmad]
> After pondering on this, it seems to me that makes sense. Will
> introduce
> a flag for "IPv4 HoA Revocation Only" and update the draft
accordingly.
> This will cause some text changes to capture all cases which relates
to
> Client MIP6 and PMIPv6; will take care of it in the new revision,
> hopefully in the next week.
> 
> >
> >
> > > >
> > > > - In the draft you refer to MAG identity, where is this term
> > > > defined? I wasn't able to find it in RFC 5213.
> > >
> > > [Ahmad]
> > > Actually, under section 4.1. "Peer Authorization Database (PAD)
> > Example
> > > Entries", you can find the MAG-ID is defined there as
> > mag_identity_1.
> > > It
> > > is the same concept here. However, I agree that we do not have a
> > > mobility option which is specific for carrying MAG-ID but
> > the draft is
> > > using the MN-ID in a very specific scenario. How the LMA would
> check
> > if
> > > this MAG is authorized for Global revocation is out of scope.
> > >
> >
> > [Patrick] what I meant here is that in section 2 of RFC5213
> > there is the definition of MN identity and that I would
> > expect something similar for the MAG in BRI draft. For MN
> > identity, RFC5213 claims that MAC address or NAI can be used.
> > Are there similar guidelines for MAG identity?
> 
> [Ahmad]
> I see what you are saying. I assumed that this is in the form of NAI.
> we
> can add some text to clarify that, would that address your concern or
> you have in mind a possible different format?

I think this would be good. Either a definition in section 2.2 or a
clarification in the text would be fine with me.


> 
> >
> >
> > > >
> > > >
> > > > Some other comments related to specific sections:
> > > >
> > > > - page 21: in the first section after the bullet list,
> > there is the
> > > > following sentence:
> > > > "As described in Section 7.3, the LMA SHOULD retransmit
> > this BRI to
> > > >    the MAG before deleting the mobile node IP tunnel to the
> mobile
> > > >    access gateway until it receives a matching Binding
Revocation
> > > >    Acknowledgement or the BRIMaxRetransmitNumber is reached. "
> > > > But this doesn't always apply, e.g. in case of inter-mag
> > handoffs.
> > > > What am I missing?
> > >
> > > [Ahmad]
> > > Yes, I see what you are saying here. It seems that the text
> > needs some
> > > tweaking.
> > > Do you have any suggestion?
> > [Patrick] How about referring to the BCE?
> > Proposed text:
> > "As described in Section 7.3, the LMA SHOULD retransmit this
> > BRI to the MAG before deleting BCE until it receives a
> > matching Binding Revocation Acknowledgement or the
> > BRIMaxRetransmitNumber is reached. "
> > Though I am not sure this text is helpful as it is already
> > captured later in the draft.
> 
> [Ahmad]
> When talking about deleting the BCE, it may conflict with the case of
> inter-MAG handoff. I believe leaving the term deleting the tunnel is
> more generic. In other words, LMA may delete the IP tunnel but NOT the
> BCE in some cases. However, in other cases which does not involve
> inter-MAG handoff, when deleting the IP tunnel, consequently, the BCE
> will be deleted.

Fine with me.

> 
> >
> >
> > >
> > > >
> > > > - why is the A bit setting mandatory in case of IPv4 HoA binding
> > > > only revocation?
> > >
> > > [Ahmad]
> > > May be if you tell me why not, we could change it?
> >
> > [Patrick] I have nothing against it. But that "MUST" implies
> > that a BRI with the "IPv4 HoA Binding Only" value in the
> > revocation trigger field and A bit not set is not properly
> > formatted. What does the MAG do in this case?
> 
> [Ahmad]
> I believe that "MUST" is needed because revoking the IPv4 HoA address
> only does not mean deleting the BCE, In other words, the MAG should
> maintain the IPv6 HoA Binding and a PBA is needed to confirm to the
LMA
> that the MAG will continue maintaining the IPv6 binding. However, the
> case you mentioned is an error scenario and we may have two ways to do
> it:
> 
> 1. The MAG to ignore the BRI
> 2. The MAG MUST treat this as if the 'A' bit is set and MUST send a
> PBA.
> 
> After introducing the "IPv4 HoA Revocation Only" flag, I believe the
> proper behavior is No. 2 above.
>

Behavior 2 implies that PBA is mandatory, not the setting of the ACK,
but I can live with that :-)
 
> 
> >
> > >
> > > >
> > > > - section 10.1.1:
> > > > "BRI MUST be formatted as in Section 6.1 and if the (P)
> > bit is set,
> > > >       the mobile access gateway must validate that the impacted
> > > > binding
> > > >       have the proxy binding flag set."
> > > > MAG is not supposed to have any proxy binding flag or is it?
> > > > How can it validate this flag?
> > >
> > > [Ahmad]
> > > Good catch. There is another incident below it too.
> > > What about the following text for both bullets:
> > > "
> > >    o  BRI MUST be formatted as in Section 6.1 and the (P)
> > bit is set.
> > >
> > >    o  If the Global (G) bit is set and the Revocation
> > Trigger field is
> > >       set to "Per-Peer policy", the mobile access gateway
> > identify all
> > >       bindings that are registered at the LMA and hosted at the
> MAG.
> > >       This Binding Revocation Indication does not include any
other
> > >       mobility options. In this case, the MAG MUST send a
> > BRA with the
> > >       appropriate status code to the LMA.
> > > "
> > >
> >
> > [Patrick] fine with me, thanks
> >
> > > >
> > > >
> > > > -section 11.1
> > > > " If the Acknowledgement (A) bit is set in the Binding
Revocation
> > > >       Indication and the MN has the BCE in registered state, the
> > > > mobile
> > > >       node MUST send a Binding Revocation Acknowledgement."
> > > >
> > > > MN has no BCE, it has a binding update list.
> > > [Ahmad]
> > > Right. Thx. What about the following:
> > >
> > >    o  If the Acknowledgement (A) bit is set in the Binding
> > Revocation
> > >       Indication and the MN has a Binding Update List entry for
the
> > > source
> > >       of the BRI message, the mobile node MUST send a Binding
> > > Revocation
> > >
> > >       Acknowledgement. However, in all other cases when the
> > (A) bit is
> > > set
> > >       in the BRI, the mobile node SHOULD send a Binding Revocation
> > > Acknowledgement.
> > >       In all cases, the mobile node MUST follow Section
> > 11.2 when send
> > >       a BRA using the appropriate status code.
> > >
> > [Patrick] I would perform the check based on the HoA and CoA
> > contained in the BRI.
> > Proposed text:
> >
> >    o  If the Acknowledgement (A) bit is set in the Binding
Revocation
> >       Indication and the MN has a Binding Update List entry
> > for the Care of address and the Home Address
> >       Contained in the BRI message, the mobile node MUST send
> > a Binding Revocation
> >
> >       Acknowledgement. However, in all other cases when the
> > (A) bit is set
> >       in the BRI, the mobile node SHOULD send a Binding
> > Revocation Acknowledgement.
> >       In all cases, the mobile node MUST follow Section 11.2
> > when send
> >       a BRA using the appropriate status code.
> >
> 
> [Ahmad]
> Currently, neither the HoA nor the CoA is included in the BRI message.
> Are you suggesting that we add those options as valid ones in the BRI?

No I am not. What I meant here is that HoA is in the routing header of
the packet containing the BRI. Checking of HoA would be enough IMO. It
could be moved to the previous bullet of the list as in the following
proposed text:
OLD TEXT:
"
   o  The mobile node MUST verify that the IP address in the type 2
      routing header is its Home Address.

   o  If the Acknowledgement (A) bit is set in the Binding Revocation
      Indication and the MN has the BCE in registered state, the mobile
      node MUST send a Binding Revocation Acknowledgement.  However, in
      all other cases when the (A) bit is set in the BRI, the mobile
      node SHOULD send a Binding Revocation Acknowledgement.  In all
      cases, the mobile node MUST follow Section 11.2 when send a BRA
      using the appropriate status code.
"
NEW TEXT
"
   o  The mobile node MUST verify that the IP address in the type 2
      routing header is its Home Address and that its Binding Update 
	List contains an entry for that Home Address. If one of the
tests fails, 
	the mobile node SHOULD silently discard the received BRI
      message.

   o  If the Acknowledgement (A) bit is set in the Binding Revocation
      Indication, the mobile
      node MUST send a Binding Revocation Acknowledgement.  However, in
      all other cases when the (A) bit is set in the BRI, the mobile
      node SHOULD send a Binding Revocation Acknowledgement.  In all
      cases, the mobile node MUST follow Section 11.2 when send a BRA
      using the appropriate status code.
"

Please note that the proposed text overlaps with the last bullet listed
in section 11.2. I would remove that as in the following:

Old text:
"11.2.  Sending Binding Revocation Acknowledgement

   When the mobile node receive a valid Binding Revocation Indication
   with the (A) bit is set from its home agent and while having this BCE
   in registered state, the mobile node MUST send a packet to its home
   agent containing a Binding Revocation Acknowledgement according to
   the procedure in Section 7.1 and the following:

   o  The mobile node MUST set the status field to successful to reflect
      that it has received the Binding Revocation Indication and
      acknowledge that its IP connectivity with its home agent has been
      revoked.

   o  The destination IP address of the IPv6 packet of the Binding
      Revocation Acknowledgement is set to the source IP address of the
      received IPv6 packet of the Binding Revocation Indication.  The
      Mobile Node MUST include its home address in the Home Address
      option in the Destination Option.

   o  If the mobile node receives a Binding Revocation Indication from a
      home agent which the mobile node does not have a registered
      binding with, the mobile node SHOULD silently discard the BRI
      message.  The mobile node should continue to use its assigned HoA
      to access its IP mobility service."

New text:
"11.2.  Sending Binding Revocation Acknowledgement

   When the mobile node receive a valid Binding Revocation Indication
   with the (A) bit is set from its home agent and while having this BCE
   in registered state, the mobile node MUST send a packet to its home
   agent containing a Binding Revocation Acknowledgement according to
   the procedure in Section 7.1 and the following:

   o  The mobile node MUST set the status field to successful to reflect
      that it has received the Binding Revocation Indication and
      acknowledge that its IP connectivity with its home agent has been
      revoked.

   o  The destination IP address of the IPv6 packet of the Binding
      Revocation Acknowledgement is set to the source IP address of the
      received IPv6 packet of the Binding Revocation Indication.  The
      Mobile Node MUST include its home address in the Home Address
      option in the Destination Option."
> 
> >
> > > >
> > > > -section 11.1
> > > > "If the Revocation Trigger field value is "Administrative
> Reason",
> > > >       the mobile node MUST NOT try to re-register with the home
> > agent
> > > >       before contacting its home operator."
> > > >
> > > > I don't think that BRI specs have to mandate the MN to
> > contact the
> > > > home operator, the text at the end of section
> > > > 11.1 is enough IMO.
> > > >
> > > [Ahmad]
> > > I see your point, It seems a very strong requirement and for a
well
> > > behaved MN implementation, it may not be a problem to
> > remove the whole
> > > bullet. However, for a non-well behaved MN, it may be necessary to
> > keep
> > > something. What about if we demote MUST NOT to SHOULD NOT.
> > Would that
> > > work?
> > >
> > >
> > [Patrick] I was not worried about the "MUST" or "SHOULD", but
> > by the fact that IMO the action to be taken after receiving a
> > BRI with that value in the trigger field is implementation
> > dependant as already described later in the draft
> 
> [Ahmad]
> Sure, we can remove this bullet.
> 
> Thanks for all of your comments and sorry for the late reply.
> 
> >
> > > NEW TEXT:
> > >    o  If the Revocation Trigger field value is "Administrative
> > Reason",
> > >       the mobile node SHOULD NOT try to re-register with the home
> > agent
> > >       before contacting its home operator.
> > >
> > > TEXT at end of 11.1 that Patrick is referring to:
> > >
> > >    The Revocation Trigger field value in the received Binding
> > > Revocation
> > >    Indication could be used by the mobile node to define
> > what action
> > > the
> > >    mobile node could do to be able to register again and receive
> its
> > IP
> > >    mobility service, e.g. contacting its home operator.
> > >
> > > > I have some typos and editorial corrections as well, I will send
> > > > them off-list.
> > >
> > > [Ahmad]
> > > Please send them. Thanks for your review and good comments!
> > >
> > > >
> > > > Regards,
> > > >
> > > > Patrick
> > > >
> >
_______________________________________________
MEXT mailing list
MEXT at ietf.org
https://www.ietf.org/mailman/listinfo/mext

Follow-Ups:
- Re: [MEXT] Comments on draft-ietf-mext-binding-revocation-02
  - From: Ahmad Muhanna

References:
- [MEXT] Comments on draft-ietf-mext-binding-revocation-02
  - From: Stupar, Patrick
- Re: [MEXT] Comments on draft-ietf-mext-binding-revocation-02
  - From: Ahmad Muhanna
- Re: [MEXT] Comments on draft-ietf-mext-binding-revocation-02
  - From: Stupar, Patrick
- Re: [MEXT] Comments on draft-ietf-mext-binding-revocation-02
  - From: Ahmad Muhanna

Prev by Date: Re: [MEXT] GRE support in DSMIPv6 - AD review
Next by Date: Re: [MEXT] GRE support in DSMIPv6 - AD review
Previous by thread: Re: [MEXT] Comments on draft-ietf-mext-binding-revocation-02
Next by thread: Re: [MEXT] Comments on draft-ietf-mext-binding-revocation-02
Index(es):
- Date
- Thread

Re: [MEXT] Comments on draft-ietf-mext-binding-revocation-02

Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.