Subject: [mobile-ip] error codes in registration revocation

From: Kuntal Chowdhury <[email-masked]>
Date: Wed, 15 Jan 2003 15:28:28 -0600

Hi folks,
 From a recent discussion on the need for the A-bit, I understood that 
we have agreed to set the A-bit to 1 in all revoke messages or include 
some text to require mandatory acknowledgment for these messages.
To extend this chain of thought, I think we need to define a few error 
codes in the ack message, to report whether the receiving agent was able 
to process the revoke-request.
An example error code may be "unsupported  revocation mask". I 
understand that, to make sense for this error codes the sending mobility 
agent needs to wait for the ack from the receiving mobility agent before 
deleting the binding. OTOH, if we don't have a way to report back 
successful/unsuccessful processing of a revoke-requests, then one of the 
primary purpose of this draft i.e. "resource release" remains unaddressed.

Regards,
Kuntal

---

From: "Madhavi W. Chandra" <[email-masked]>
Date: Thu, 16 Jan 2003 14:17:25 -0500

HI Kuntal,

> some text to require mandatory acknowledgment for these messages.

Actually, we just removed the 'A-bit' altogether.  The ACK mechanism
is mandatory.

> to process the revoke-request.

I don't believe error codes are warranted for revocation messages.
Any error code returned by the receiving agent has no consequence to
the revoking agent.  The revoking agent has already revoked the
binding, and is earnestly informing the other agent via the handshaked
revocation mechansim.  

Since this draft is on a tight-timeline, we had a conference call with
the WG chairs to discuss open issues and how to progress the draft
toward the editor's queue.  It was felt that error codes should not be
incorporated at this time, if at all...which is in agreement with some
off-line comments we've received as well. 

Regards,
Madhavi

---

From: Kuntal Chowdhury <[email-masked]>
Date: Fri, 17 Jan 2003 00:20:07 -0600

Hello Madhavi,

Please see my comments inline...

 > Actually, we just removed the 'A-bit' altogether.  The ACK mechanism

Thanks for the clarification.

 > binding, and is earnestly informing the other agent via the handshaked
If the revoking agent has no consequence for any error code or result
code then what is the purpose of returning an acknowledgment? I guess
the ack is coming back to the revoking agent and the revoking agent is
simply discarding it, with the assumption that the processing of the
request was successful!

 > off-line comments we've received as well.
I completely understand the timing issue here since I am aware of the
dependencies of this draft with other standard. However, I strongly feel
that the "FYI" nature of the revocation  messages do not satisfy the
primary requirement of resource release that is desired by the intended
users of this draft. If for some reason the receiving mobility agent
cannot process the revoke message (e.g. unknown/unsupported revocation
mask), there should be a way for it to let the other mobility agent know
about the error.
If adding a few error codes is not agreeable to you, then I suggest we
make the draft simpler and remove all the revocation masks except 0x01.

Regards,
Kuntal

---

From: Mike Borella <[email-masked]>
Date: Fri, 17 Jan 2003 05:53:26 -0800 (PST)

> simply discarding it, with the assumption that the

The purpose of the ack is to inform the revoking agent
that the revocation got through and it does not need
to retransmit any more, if it had intended on doing
so.

Mike

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

---

From: "Madhavi W. Chandra" <[email-masked]>
Date: Fri, 17 Jan 2003 09:32:43 -0500

Hi Kuntal,

> simply discarding it, with the assumption that the processing of the

As Mike replied, the ACK mechanism is to facilitate an earnest attempt
at notifying the other agent of revocation...so, if no ACK is received,
the revoking agent will retransmit.  Actually, the ACK mechanism came
about to ensure that the receiving agent is reliably notified so that
it can release resources.

> mask), there should be a way for it to let the other mobility agent know

I guess we have a difference in opinion.  I don't see what the revoking agent
would do with this knowledge...it has already revoked the binding.  
It will not keep state simply because the receiving agent could not
process the revocation message.  

> make the draft simpler and remove all the revocation masks except 0x01.

This would require WG consensus.

Regards,
Madhavi

---

From: Kuntal Chowdhury <[email-masked]>
Date: Sat, 18 Jan 2003 02:41:27 -0600

Hello Madhavi,

> it can release resources.
I think apart from the ACK, a NACK would be useful to return error codes 
to the revoking agent in case the receiving agent could not process the 
request. We can rename the revocation acknowledgment message to 
revocation response message with an ack/nack bit.

> process the revocation message.  
If the NACK mechanism is agreeable, then the revoking agent needs to 
keep the mobility binding until it receives an ACK from the receiving 
agent. Anyway, the current retransmission mechanism needs the revoking 
agent to keep some state (e.g. fields in the revoke-request, timer etc.) 
until it receives an ACK. Please note that the whole purpose of this 
revocation mechanism is to make sure that the unused resources are 
reliably released at BOTH (potentially the MN as well) the mobility 
agents. IMHO, the current mechanism where the revoking agent just 
unilaterally removes the binding without making sure that the associated 
resources are released at the other agent is not adequate.
I agree with you that, in the current mechanism the revoking agent 
cannot do much upon receiving an error code. However, I feel this issue 
needs to be fixed and it can be fixed fairly easily.

> This would require WG consensus.
OK, let's hear from other folks.

-Kuntal

---

From: "Steven M. Glass" <[email-masked]>
Date: Tue, 21 Jan 2003 00:07:08 -0500

Kuntal,

     The idea of a NACK mechanism here is really not relevant.  The 
revocation messages are used to inform the other agent serving the same 
registration that it can terminate said registration, and free 
resources.  It's an FYI.  If an agent decides to terminate a binding 
for security reasons, keeping the binding up until the other agent 
acknowledges the revocation is just wrong.  The agent receiving the 
revocation message has nothing to say about the state of the binding, 
it's gone.  If the receiving agent can't figure out what the revocation 
message is telling it, there's no way the sending agent could clarify, 
so acking, nacking, or just not responding to the revocation message 
result in the same outcome.

                               Cheers,
                                   Steve

On Saturday, January 18, 2003, at 03:41  AM, Kuntal Chowdhury wrote:

> I think apart from the ACK, a NACK would be useful to return error 
> codes to the revoking agent in case the receiving agent could not 
> process the request. We can rename the revocation acknowledgment 
> message to revocation response message with an ack/nack bit.
>
> agent to keep some state (e.g. fields in the revoke-request, timer 
> etc.) until it receives an ACK. Please note that the whole purpose of 
> this revocation mechanism is to make sure that the unused resources 
> are reliably released at BOTH (potentially the MN as well) the 
> mobility agents. IMHO, the current mechanism where the revoking agent 
> just unilaterally removes the binding without making sure that the 
> associated resources are released at the other agent is not adequate.
> cannot do much upon receiving an error code. However, I feel this 
> issue needs to be fixed and it can be fixed fairly easily.
>

---

From: Kuntal Chowdhury <[email-masked]>
Date: Tue, 21 Jan 2003 14:01:15 -0600

Hello Steve,
The current text in the draft implies that the intent of the revocation 
message is to release resources in BOTH FA and HA. Also the text implies 
that an acknowledgment message is sent when the receiving agent 
understands the revocation message:

"The registration revocation protocol is broken into two disjoint
pieces.  First, a signaling mechanism between home and foreign agents
is described which allows either the home or foreign domain to inform
the other it has torn down the current tunnel, allowing both to free
up the resources associated with the identified Mobile IP binding, and
to acknowledge this understanding."

This was OK when we had the A-bit to turn acknowledgment on/off. Now we 
made ACK mandatory. Therefore, the receiving agent has to acknowledge, 
even though it did not understand the message.
I believe sending an ACK in place of a NACK is not a good practice. 
Although the revoking agent may not be able to rectify the revocation 
message that caused the NACK, it will at least know what exactly happened.
If the revoking agent has not got rid of the binding yet, then it may 
rectify the revocation message based on the error code returned.

-Kuntal

Steven M. Glass wrote:
> resources.  It's an FYI.  If an agent decides to terminate a binding for 
> security reasons, keeping the binding up until the other agent

---

From: "Steven M. Glass" <[email-masked]>
Date: Tue, 21 Jan 2003 15:37:06 -0500

On Tuesday, January 21, 2003, at 03:01  PM, Kuntal Chowdhury wrote:

> Hello Steve,
> The current text in the draft implies that the intent of the 
> revocation message is to release resources in BOTH FA and HA.

     Correct.  They've been released in one, and the revocation message 
allows the other to as well.

>  Also the text implies that an acknowledgment message is sent when the 
> receiving agent understands the revocation message:

     I don't know how else it would know to send an ACK.

> to acknowledge this understanding."

     The above paragraph says "...allows either ... to inform the other 
it has torn down the current tunnel..." meaning the services are no 
longer being provided.

> This was OK when we had the A-bit to turn acknowledgment on/off. Now 
> we made ACK mandatory. Therefore, the receiving agent has to 
> acknowledge, even though it did not understand the message.

     If it doesn't understand revocation messages, how can it 
acknowledge?  This is the point of the revocation extension in the 
agent-portion of the registration messages; if the other side doesn't 
understand revocation messages, the revoking agent won't be sending 
them.

> message that caused the NACK, it will at least know what exactly 

     This is essentially identical to the situation where the agent 
receiving the revocation it doesn't understand simply doesn't send a 
response.  The revocation message will be retransmitted a few times, 
but the net result is identical - "revocation message not 
received/understood" (which is the implied error-code).

> rectify the revocation message based on the error code returned.

     Once the revocation message has been sent, if the revoking agent 
doesn't delete the affected binding(s), it is opening itself up for a 
reflection attack.  The revocation message can be reflected back to the 
sender, which is identical to the situation where the other agent 
coincidentally generated a revocation message for the same affected 
binding(s), resulting in the binding being freed on the revoking agent. 
  Note that this isn't a DOS attack, because the binding is already 
going away.

                               Cheers,
                                   Steve

---

From: Kuntal Chowdhury <[email-masked]>
Date: Tue, 21 Jan 2003 22:24:21 -0600

> allows the other to as well.

Not always, the message may not be parseable at the other agent. So,
the binding stays at the other agent in this case.

 >     I don't know how else it would know to send an ACK.

The point I tried to make was: the current text in the draft implies 
that the receiving agent sends ACK to convey to the sending agent that 
it understood the message. I think the term "understand" deserves some 
clarification. In my opinion, it means:
the receiving agent can parse the message + auth passed + bindings
specified in the message (with a specific revocation mask) is revocable. 
If one of these fails then the receiving agent does not understand the 
message, hence it should not send an ACK.

It is not clear what "understand" means in the draft. Is it simply 
receiving a message with a known message type or it is known message 
type + all the above checks?

 > it has torn down the current tunnel..." meaning the services are no

IMHO, allowing an agent to revoke a binding locally is not a big deal, 
we certainly don't need an RFC for allowing an agent to do that. It 
would be better to make sure that either the FA or the HA can release 
the associated binding(s) upon RECEIVING a revocation message from the 
other side. If adding NACK or error message is not agreeable to you, 
then at least we should clarify what the receiving agent should do when 
some error cases occur e.g.:

1. authentication fails -> no ACK
2. poorly formatted message -> ACK
3. unsupported revocation mask -> ACK
4. binding not revocable -> ACK
5. binding does not exist -> ACK
etc.
Note that in most of these error cases the the binding in the receiving 
agent will remain until it times out (natural death).

 > understand revocation messages, the revoking agent won't be sending them.
 >

IMO, understanding a revocation message has nothing to do with 
revocation-support extension. An agent may not be able to parse a poorly 
formatted revoke message although it supports registration revocation.

 > response.  The revocation message will be retransmitted a few times, but
 > the net result is identical - "revocation message not

The ACK is required to stop the revoking agent from retransmitting. 
Therefore, the receiving agent should ACK as soon as it receives and 
understands the revoke-message. That doesn't guarantee that the 
receiving agent will actually parse the message and release the binding 
successfully unless we know what the term "understand" exactly means in 
the draft. It seems according to you "understand" means recognizing a 
known message type, however that may not be enough to issue an ACK.

 >  Note that this isn't a DOS attack, because the binding is already going
 > away.
 >
 >

Well, we can be handle this situation with error codes. The revoking
agent will send NACK with error code = "revocation pending" to the
source, or we can say, the mobility agent will silently discard the
request when it is waiting for an ACK from the other mobility agent for
the same binding.
This will also cover the scenario when actually both the valid mobility
agents coincidentally try to revoke the same binding.

-Kuntal