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

From: "Glenn Morrow" <[email-masked]>
Date: Fri, 25 Apr 2003 15:45:00 -0500

Forwarding Original correspondence

-----Original Message-----
From: Morrow, Glenn [RICH2:2Q00:EXCH] 
Sent: Thursday, April 24, 2003 3:57 PM
To: 'Steven M. Glass'; Bharatia, Jayshree [RICH1:2H13:EXCH]
Cc: Chowdhury, Kuntal [RICH1:2H18:EXCH]; madhavi Chandra
Subject: RE: Potential issues with Registration Revocation draft

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.

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.

  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. 

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.

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

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

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

     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.

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

> 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?
2) What are the interactions between the X-bit and the R-bit and home
policy?
3) What are the interactions between X-bit and preference level?
4) What are the interactions between X-bit and other FA selection methods?
5) Could a malicious mobile actually use the x-bit to deplete 
resources of agents?
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.
 
[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. 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. 

[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.
 
[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 hope this clears things up for you.  If you have any questions 
about any of this, feel free to either write back, or try to stop me in 
the hall!

                               Cheers,
                                   Steve

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

[GM]Please let us know if you need any help whatsoever in getting the draft
progressed to RFC status as soon as possible.

Respectfully,

Glenn 
Glenn Morrow
[email-masked]
972-684-1734

---

From: "Glenn Morrow" <[email-masked]>
Date: Fri, 25 Apr 2003 15:44:52 -0500

Forwarding original correspondence

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

     Jayshree,

> indicate whether it was initiated by the HA or the FA.

    This is not needed.  Since an agent can be an HA to some MNs, and an 
FA to others.  This means the agent has to determine, based on Home 
Address, how it's serving the MN.  At that time, it can either check 
the bit, or check the time-stamp in the replay ID.  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.  In that case, the bit won't help, and only the 
time-stamp in the ID field will.  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.

     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.

registration from FA2 all seems well; remember my comments on scope.  

     The X-bit is used for an FA to advertise it's support of 
registration revocation.  From section 3.1:

    3.1  Advertising Registration Revocation Support

Mobility agents can advertise their support of registration revocation with
a modification to the Mobility Agent Advertisement extension described in
[1].  An 'X' bit is introduced to indicate an agent's support for
Registration Revocation.

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Type      |    Length     |        Sequence Number        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    Registration Lifetime      |R|B|H|F|M|G|r|T|X|  reserved   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                  zero or more Care-of Addresses               |
    |                              ...                              |

	X   The mobility agent supports Registration Revocation

A foreign agent that sets the 'X' bit in an agent advertisement extension
MUST support registration revocation messages on that link, specifically the
Revocation Support Extension (section 3.2), Revocation message (section
3.3), and Revocation Acknowledgment (section 3.4).  It is not required that
all agents advertising on the same link support registration revocation, nor
is it required that an agent advertise this support on all of its links.

Note that using this information, a mobile node can select a foreign agent
that supports registration revocation, e.g., should it be required by home
domain policy.  Should a mobile node not understand this bit, it simply
ignores the bit as per [1].

As a bit in the agent advertisement, use of the 'X' bit has no impact on
other messages, such as e.g. Challenge-Response [9].  Security issues, such
as those deployers should be aware of with agent advertisements, are covered
in Section 7 of this document, and [5].

<fin>

                               Cheers,
                                   Steve

---

From: [email-masked]
Date: Mon, 28 Apr 2003 17:53:45 -0500

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

> 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]
> 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).
> 
> 
> > Cc: Chowdhury, Kuntal [RICH1:2H18:EXCH]; Morrow, Glenn 
> > [RICH2:2Q00:EXCH]; madhavi Chandra
> > [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.
> 
> > [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.
> >
> > 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.
> >
> > 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.
> 
> 
> > [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:
> > >
> > > and advocated in the draft; namely, the revocation 
> mechanism is an 
> > FYI
> > [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 
> > [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:
> > >
> > 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
>      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.
> 
> 
> > [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.
> >
> >  
> > > and sends a revocation message to the HA. Meanwhile the 
> MN sends a 
> > RRQ
> > [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
> > [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:
> > >
> > [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:
>      "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.
> 
> 
>      A MN chooses the agent of the highest preference level for the 
> feature set it needs.  Sounds orthogonal to me.
> 
> 
>      See #3.
>      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:
>      I'll look at it when I have some more time.
> 
> 
> > 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.
> >
> > 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
> 
>