Subject: Re: [mobile-ip] RE: Potential issues with Registration Revocation draft

From: Parviz Yegani <[email-masked]>
Date: Wed, 30 Apr 2003 00:05:36 -0700

At 05:53 PM 4/28/2003 -0500, [email-masked] wrote:
>The IETF process for WG last call and IETF last call produced
>comments that have been addressed by the authors. We cannot
>keep on revisiting the draft at every turn or at the convenience
>of folks who may have missed the opportunity to comment. That
>said I agree with Steve that the draft is now at a stage wherein
>we really do not want to make changes other than the ones that
>have been agreed to as a result of WG and IETF last call and
>feedback from AD review and IESG comments. So while the offer
>to help make the changes is welcome, it is way too late in the
>process.
>
>-Basavaraj

Agreed. It's way too late for the authors to take any new comments.
As far as 3GPP2 is concerned we don't see any problem with the
draft. We would like to see the draft to be approved for RFC as soon
as possible. As a active member of 3GPP2 I would like to thank
the authors and the IETF leadership for their continued efforts to
move the work forward and to promote the draft to an RFC status.

Parviz Yegani
Chair, TIA TR45.6 Subcommittee

> > -----Original Message-----
> > From: ext Steven M. Glass [mailto:[email-masked]]
> > Sent: 25 April, 2003 12:43 PM
> > To: Glenn Morrow
> > Cc: Jayshree Bharatia; Kuntal Chowdhury; madhavi Chandra; Patil
> > Basavaraj (NET/Dallas); [email-masked]; [email-masked]; Tom Hiller;
> > [email-masked]
> > Subject: Re: Potential issues with Registration Revocation draft
> >
> >
> >
> > On Thursday, April 24, 2003, at 04:53  PM, Glenn Morrow wrote:
> >
> > > Steve,
> > >
> > > It may be too late for these comments but perhaps they will
> > be useful
> > > to progress the ID in time for 3GPP2. It took us some time to
> > > determine how to respond to your initial reply.
> > >
> > > If you need help on the ID due to your other
> > responsibilities, one of
> > > us or perhaps some folks from other companies can help
> > editing etc..
> > > to get the ID done in time. We are in the same boat as far
> > as having
> > > day jobs.
> > >
> > > Please let us know if we can help in any way. Please keep
> > in mind that
> > > our comments are intended to be constructive and get the ID
> > in shape
> > > to be approved for RFC status as soon as possible.
> >
> >      Glenn,
> >
> >      To be honest, since we've already been delayed a couple costing
> > Madhavi and I *months* of time due to a significant lack of
> > communication from some 3GPP2 folks (some of whom are on this
> > thread),
> > I've become somewhat apathetic to your schedule needs.  That said, we
> > are making every effort to get this thing published despite
> > the delays,
> > but I'm absolutely done taking comments that don't go through
> > the IETF
> > working group.  If you'd like to relay whatever your
> > proprietary group
> > decides it would like to see, at whatever time you get your
> > discussions
> > done, you should do so via the correct channels.  As a result, I've
> > cc:ed the working group (and the WG chairs since these delays
> > continue).
> >
> >
> > > Comments below are labeled [GM].
> >
> > > -----Original Message-----
> > > From: Steven M. Glass [mailto:[email-masked]]
> > > Sent: Thursday, March 20, 2003 11:02 PM
> > > To: Bharatia, Jayshree [RICH1:2H13:EXCH]
> > > Cc: Chowdhury, Kuntal [RICH1:2H18:EXCH]; Morrow, Glenn
> > > [RICH2:2Q00:EXCH]; madhavi Chandra
> > > Subject: Re: Potential issues with Registration Revocation draft
> > >
> > >
> > >
> > >      Jayshree,
> > >
> > >      Sorry for the delay.  I've cc:ed Madhavi, my co-author
> > so she can
> > > be aware of the questions we're getting.
> > >
> > >
> > > On Tuesday, March 18, 2003, at 11:50  AM, Jayshree Bharatia wrote:
> > >
> > > > ------
> > > > Issue 1:
> > > >
> > > > There is no indication in the revocation message whether
> > the sending
> > > > entity is HA or FA. This will allow a malicious reflector to send
> > > back
> > > > the same revocation message to the initiator of it. Upon receiving
> > > > such a reflection the initiator has will have to send an
> > ACK even w/o
> > > > knowing that this is a refection attack. The authentication of the
> > > > reflected message will pass if the there wasn't any newer
> > > registration
> > > > request/reply exchange between the FA and the HA to update the
> > > > timestamps maintained for each peer.
> > > >
> > > > Possible solution: Introduce a bit in the revocation message to
> > > > indicate whether it was initiated by the HA or the FA.
> > >
> > >     This is not needed.
> > > [GM] It is fairly obvious that it IS NEEDED to make the protocol
> > > secure when shared symmetric keys are used.
> >
> >      I know it sounds funny, but capital letters by themselves don't
> > have much influence in convincing me.  One way to show it's
> > NOT needed
> > is through our replay mechanism which ignores revocation messages
> > received with IDs identical to those sent (you don't even have to
> > compute the authenticator to know to throw it away, good
> > implementations check the easy things first, then spend the resources
> > to check the harder things).  Symmetric keys or not, this packet will
> > be dropped.  If, however, your argument is a 'direction' bit can make
> > reflected packets quicker to detect (one bit [and a pair of
> > address] vs
> > 4 bytes [an ad pair of addresses]), then I'd say you may have a
> > technical argument for a direction bit.
> >
> > >   Since an agent can be an HA to some MNs, and an
> > > FA to others.
> > > [GM] Yes, this statement is true.
> > >
> > >   This means the agent has to determine, based on Home
> > > Address, how it's serving the MN.
> > > [GM] The home address alone can not, in itself, nor in conjunction
> > > with a timestamp determine how to multiplex received
> > messages to the
> > > correct agent handlers inside the box.
> > > At that time, it can either check the bit, or check the
> > time-stamp in
> > > the replay ID.
> > > [GM] The bit is used as a cryptographic input - not to
> > determine how
> > > to multiplex the packet. It just so happens that it being
> > FA/HA will
> > > do the job and fits in nicely with the semantics of the protocol
> > > agents involved.
> > >
> > > True, the single bit is faster, but note that in the cases of e.g.
> > > overlapping private addresses it's possible for there to be two MNs
> > > with identical addresses bound to this agent, one obtaining HA
> > > services, and the other obtaining FA services.
> > >
> > > [GM] Steve, from my understand implementations would never
> > rely solely
> > > on either the the HA/FA bit nor the timestamp to distinguish which
> > > address space and therefore which instance of an agent a signaling
> > > packet belongs to. If you implementation does then lets
> > talk some more
> > > about why this is a bad idea.
> > >
> > > In that case, the bit won't help, and only the
> > > time-stamp in the ID field will.
> > > [GM] I don't think either field choice will work to
> > distinguish which
> > > address space the packet belongs to and thus instance of agent.
> > > Distinguishing address space was never intended to be a use for MIP.
> > >
> > > I'm not entirely adversed to adding the bit, but at this
> > late time it
> > > seems like it might be perceived a too much of a change.
> > >
> > > [GM] I suspect you would find that the implementors and vendors who
> > > actually have product in the field and customers wanting this
> > > functionality would welcome the change, especially if the ID
> > > progressed to an RFC by the 3GPP2 requested date.
> >
> >      Based on the first date I heard we're already at least 2 months
> > late.  Is there another date maybe you guys should have relayed to us.
> >
> >
> > > Note also that the presumption the packet will pass authentication
> > > isn't necessarily true.  If e.g. a shared secret is used then the
> > > authenticator should check, but any asymmetrical protocol
> > will generate
> > > a failed authenticator.
> > > [GM] Steve, we need to make the protocol as secure as possible for
> > > both of the cases. Right now as the ID stands without the
> > bit, it is
> > > not secure for the symmetric case. The bit needs to be
> > added to make
> > > it secure for the symmetric key case.
> > >
> > > [GM] Steve, please add the bit the make the protocol secure when
> > > symmetric keying is used. I'm not sure the ID will pass a security
> > > review by the IESG  without the bit to handle the symmetric keying
> > > case. If it does pass then the IESG probably does not have
> > time to do
> > > the proper due diligence.
> >
> >    If you'd like to suggest text for all appropriate
> > sections, Madhavi
> > and I will review it (this includes the appendix on private address
> > support).
> >
> >
> > > > Issue 2:
> > > >
> > > > While setting I=1 in the revocation message, the FA has
> > to wait for
> > > > the HA to ACK with I=1/0. Meanwhile the FA has to maintain the
> > > binding
> > > > and associated connections with the MN just incase the HA
> > sets I=1 in
> > > > the ACK to notify the MN. When the HA issues revocation, it won't
> > > have
> > > > to wait for an ACK from the FA for clearing the binding, it can do
> > > > that autonomously. This type of asymmetric behavior for
> > the FA and HA
> > > > does not fit into the philosophy of the revocation
> > mechanism proposed
> > > > and advocated in the draft; namely, the revocation
> > mechanism is an
> > > FYI
> > > > scheme. Moreover, it is not clear from the current draft, what
> > > happens
> > > > when the FA does not get a response from the HA after
> > > retransmissions?
> > >
> > >      I don't think it fails to fit into the philosophy of
> > the draft.
> > > The amount of state that an FA has to keep is very small;
> > it's nothing
> > > more than the home address in a 'to-be-notified' list.  If HA(i=1)
> > > {notify}; remove(homeAddress).  If the answer doesn't come
> > back, then
> > > the HA resorts to whatever it's default is, which the draft
> > says SHOULD
> > > be to notify.
> > >
> > > [GM] Steve, the whole idea of this ID is to reduce the
> > period of time
> > > state is needed to be kept by the agents. By adding the
> > semantics of
> > > one agent waiting on the other agent for approval of some sort
> > > actually increases the state that the agents need to keep
> > as well as
> > > the time they need to keep the state.
> >
> >      The 'I' bit was added due to 3GPP2 request.  If, as deployers of
> > the technology, you don't like waiting for the response,
> > don't.  Simply
> > never set the 'I' bit in the revocation support extension to anything
> > but '0' and the FA can just do whatever it likes, or
> > negotiate the 'I'
> > bit in case the HA revokes the binding, but whenever the FA
> > does simply
> > set the 'I' bit in the revocation message to '0'.  This is why we've
> > designed it to be flexible in functionality (and not required).
> >
> >      So where would you stand on the idea that revocations are to be
> > negotiated?  (<-rhetorical)
> >
> >
> > >  I feel that part of our job as Internet engineers is to make the
> > > protocols as stateless as possible. I think this is what we
> > meant by
> > > "philosophy of the ID" per-se.
> > >
> > > [GM] The draft does not explain why such semantics are needed and I
> > > suspect that someone in the IESG or mail list will eventually point
> > > this out at some point if they have enough time for due diligence.
> > > I.e. why or in what particular cases would an FA want to
> > wait for an
> > > HA to approve its removal of state?
> >
> >     (Thank you for backing up my statements as to why revocations are
> > not requested, but are FYI notifications).
> >
> >
> > > > Issue 3:
> > > >
> > > > The MN incurs a handoff from FA1 to FA2. The FA1 will
> > detect that the
> > > > MN incurred or is going to incur handoff. The FA1 will get this
> > > > information from a the radio access network such as cdma2000 RAN
> > > (MSC)
> > > > or from the AAA with a RADIUS disconnect message (required to
> > > > reconcile users account before authorizing the user to
> > get service at
> > > > FA2). The FA1 will send a registration revocation message
> > to the HA.
> > > > Meanwhile the MN will send a RRQ with the FA2-CoA to the
> > HA with the
> > > > same Home IP address (Lifetime > 0). The revocation
> > message reaches
> > > > the HA before the RRQ with FA2-CoA. The HA revokes the
> > user's binding
> > > > and deallocates the Home IP address:
> > > >
> > > > Outcome: the user loses it's network connectivity across handoff,
> > > that
> > > > defeats the purpose of Mobile IP!! ouch.
> > >
> > >      If the revocation from FA1 arrives at the HA first, I
> > agree the HA
> > > will revoke the binding, but why would it deallocate the
> > Home Address?
> > > Even in my DHCP proxy draft I don't indicate this is done.  After a
> > > while, when the RRQ arrives from FA2, the HA will establish this
> > > binding at FA2, and all is well.
> > >
> > > GM] In what case would you de-allocate the address i.e. how
> > > would you know to deallocate the address or not i.e. how
> > > would you know the mobile was about to handoff or not? Also
> > > ask yourself if the HA would have to keep some sort of state
> > > waiting to release the address? It really ends up being the
> > > same issue irrespective of how the address was allocated.
> >
> >      I think this is a problem in the way your applying the
> > draft, not
> > in the specification itself.  If the FA is being this pro-active,
> > there's no mechanism that would tell the HA the MN is about
> > to register
> > elsewhere, the HA simply has to be 'smart' enough to let the address
> > remain.
> >
> >
> > > Even in the case where the revocation from FA1 arrives after the
> > > registration from FA2 all seems well; remember my comments on scope.
> > > [GM] Please ellaborate on scope. I was apparently not privy to this
> > > comment. I am talking about the scope of this ID only - not
> > DHCP proxy
> > > or any other address assignment/allocation/configuration
> > mechanism for
> > > that matter which should be out of scope for this ID. We are not
> > > worried about this case anyway.
> > >
> > >
> > > If the registration for FA2 arrives at the HA before the revocation
> > > from FA1, the HA MUST understand the revocation for FA1 is for a
> > > binding which does not currently exist, and more
> > importantly that FA1
> > > can't revoke the bindings of FA2, and therefore NOT revoke
> > the binding
> > > with FA2.
> > > [GM] We are not worried about this case either.
> > >
> > >
> > > > Issue 4:
> > > >
> > > > The MN incurs a handoff from FA1 to FA2. The FA1 detects
> > the handoff
> > > > and sends a revocation message to the HA. Meanwhile the
> > MN sends a
> > > RRQ
> > > > to the HA with S=1. However by the time the RRQ with S=1
> > arrives at
> > > > the HA, the previous binding with FA1 is already revoked!! ouch.
> > >
> > >      I don't see the tragedy here.  Just because a binding goes away
> > > doesn't mean the connections are immediately torn-down.
> > >
> > > [GM] What connections are you talking about. We are talking
> > about IP
> > > and the only connections are end to end between the MN, FA, HA via
> > > bindings. The ID is essentially saying implementations
> > should destroy
> > > these connections.
> >
> >      Let's use the term 'binding' then, not connections which
> > sound more
> > like TCP connections.
> >
> >
> > >  Irrespective of of who/what allocated the home address, the agent
> > > must know about the address via storing it in a binding via the
> > > reference implementation. We aren't talking about L2
> > signaling methods
> > > here unless you mean that Radius constitutes L2 signaling?
> >
> >     No, I don't specify anything w.r.t. L2 other than to make
> > generally
> > sound decisions at IP that don't require special L2s, nor break
> > anything at L2.
> >
> >
> > >       Note that in the previous scenarios I imagined
> > revocation would
> > > be
> > > used differently, that is when the HA received the RRQ from FA2, it
> > > would send the revocation to FA1 to tell it the MN is no
> > longer there.
> > > I know there are L2 signaling methods which can be used, but this
> > > method works generically in all topologies.
> > > [GM] The method destroys the binding which conflicts with
> > the intent
> > > of MIP on a handoff i.e. to keep the mobile's home address and the
> > > binding during a handoff in order to reduce the affects of
> > handoff on
> > > applictions etc.. It also forces implementations to keep
> > state around
> > > longer than needed in many cases.
> >
> >      I don't see this.  Handoff of applications?  Just how
> > are you folks
> > using mobile ip.  The HA gets a registration from the same MN at a
> > different FA, so the HA tells the old FA it can stop
> > servicing the MN.
> > How does this lead to anything your saying it does?
> >
> >
> > > [GM] For issues 3 and 4 we thought that if a revocation
> > reason field
> > > were added then agents could indicate the reason for the
> > revocation to
> > > the other agent. This would allow the
> > "binding"/"address"/"state" to
> > > be kept for a period of time when needed or removed right away as
> > > indicated via the reason field.
> >
> >      I still don't see why any of that is needed.  These are
> > machines,
> > not people.
> >
> >
> > > > Issue 5:
> > > >
> > > > The X-bit in the AA is there for unknown reason. There is
> > no scenario
> > > > explained in the draft that illustrates why/how this X-bit is
> > > required
> > > > or used.
> > >
> > >      The X-bit is used for an FA to advertise it's support of
> > > registration revocation.
> > >
> > > [GM] Yes, we've read this but based upon the response, I think
> > > we should have been a bit more detailed on the
> > clarification, namely:
> > > 1) What are the interactions between the X-bit and the B-bit?
> >
> >      "I support revocation, but I'm busy now"  Sounds
> > orthogonal to me.
> >
> > > 2) What are the interactions between the X-bit and the R-bit
> > > and home policy?
> >
> >      "I support revocation, and you MUST register through me"
> >  The draft
> > actually talks about this.
> >
> >
> > > 3) What are the interactions between X-bit and preference level?
> >
> >      A MN chooses the agent of the highest preference level for the
> > feature set it needs.  Sounds orthogonal to me.
> >
> >
> > > 4) What are the interactions between X-bit and other FA selection
> > > methods?
> >
> >      See #3.
> >
> > > 5) Could a malicious mobile actually use the x-bit to deplete
> > > resources of agents?
> >
> >      I don't see how supporting the X bit opens an agent up
> > to this DoS
> > any more so than if it didn't.
> >
> >
> > > 6) It seems to me that the policy of the foreign domain i.e. the
> > > owners of the FAs would want not want to allow the policy
> > of a foreign
> > > home domain to control the distrubution of resources on
> > their network.
> >
> >      Yes, which is why policy trumps all else, and deployers
> > need to be
> > able to configure their boxes however they like.  This,
> > however, is up
> > to implementors, and is beyond specification in the draft.
> >
> >
> > > [GM] I guess what we are saying is that when we thought about
> > > all of these interactions we wondered if there really was added
> > > value in the complexity of the X-bit being there.
> >
> >
> >
> > >  These bits are a fairly rare commodity as well. It seems that it
> > > might conflict with load distribution mechanisms that are set forth
> > > already by the owners of the FAs and HAs.
> >
> >      You're thinking too hard.
> >
> > >  At a minimum please describe what the mobile behavior MUST be with
> > > respect to the interactions with these other bits and that will
> > > suffice. We would prefer if it were simply removed.
> >
> >      How is a MN to choose then?
> >
> >
> > > [GM]I.e. the added functional value of the bit vs. the
> > > complications/delay of the ID  doesn't seem to meet the
> > bang for buck
> > > requirement.
> >
> >      We were asked to remove our extension from the advertisement and
> > use a bit.  Would you rather the bandwidth were consumed by the
> > extension in every advertisement?
> >
> >
> > > [GM] One last question we might pose ourselves with this draft
> > > are the interactions with the handoff draft:
> > > http://www.ietf.org/internet-drafts/draft-ietf-mobileip-lowlat
> > > ency-handoffs-v4-04.txt
> >
> >      I'll look at it when I have some more time.
> >
> >
> > > [GM] I hope this clears some things up for you and I hope
> > we have been
> > > clearer in describing what the exact issues were. Again I apologize
> > > for us not getting back sooner. It honestly took us some
> > time to make
> > > sense of some of the points that had been raised and we have many
> > > other responsibilities as well. I volunteered to respond.
> > >
> > > [GM] SUMMARY: The revoke reason field would be an
> > improvement in state
> > > reduction and communication semantics between agents for
> > the purpose
> > > of reducing the time that state is needed. It also will provide an
> > > extensible means for future enhancements.
> >
> >      I still propose it leads to confusion and poor implementation; I
> > have yet to see an 'error' that makes sense.
> >
> >
> > >  The x-bit should be removed due to complications and the H/F bit
> > > added to fix the security hole with symmetric keys.
> > Unfortunately we
> > > can't leave a hole in the protocol to encourage  folks to use
> > > asymmetric keying technologies.
> >
> >      I don't see your 'hole in the protocol'.
> >
> >
> > > [GM]Please let us know if you need any help whatsoever in
> > getting the
> > > draft progressed to RFC status as soon as possible.
> >
> >      Suggest text for the 'direction' bit, it doesn't appear in the
> > revocation extension, call it the 'A'gent bit, set to '1' if the
> > revoking agent is the HA (HAs seem to be less-busy, and I
> > would gather
> > are less likely to revoke).
> >
> >                                Cheers,
> >                                    Steve
> >
> >

---

From: Parviz Yegani <[email-masked]>
Date: Wed, 30 Apr 2003 15:15:27 -0700

At 10:14 AM 4/30/2003 -0500, Kuntal Chowdhury wrote:
>>><..>
>>draft.
>Parviz, with all due respect, I don't think your statement reflects the 
>most recent status of the discussion in 3GPP2. There are indeed quite a 
>few open issues in 3GPP2 (V&V comments) on this subject. Some of the 
>issues are: how to prevent the race condition with revocation by previous 
>FA during inter PDSN/FA handoff, how to utilize the I-bit from HA etc, 
>IPsec/FA-HA etc. Some of these issues are linked to what has been 
>communicated to the authors in previous email on this thread. Since you 
>didn't attend all the interim meetings (conference calls) in 3GPP2, it is 
>not fair on your part to make statements like the one you just made above.

Let's address these V&V comments in 3GPP2 mailing list. They don't belong 
in here.

>OTOH, I personally think, there was ample time for the authors to make 
>necessary changes to address the potential issues here. However, personal 
>opinions aside, it is important now to move on with this draft. We just 
>have one month to move this draft to RFC editor's queue.

Agreed.

-Parviz

>Thanks to the authors and Thomas Narten for their time and attention.
>
>-Kuntal
>