Subject: RE: [mobile-ip] Last Call: Registration Revocation in Mobile IPv4 to Proposed Standard

From: "Ahmad Muhanna" <[email-masked]>
Date: Mon, 24 Feb 2003 14:03:47 -0600

Hi Steve/Madhavi

The following text in version .05:

section 3.5:
"    Upon receipt of an authenticated revocation message, the
     receiving agent MUST check the value of the Revocation Identifier
     to make sure this revocation message is neither a replay of an
     old revocation message received from the same agent, nor a
     reflection of a revocation message it sent in relation to the
     identified bindings.
"

Could you please elaborate on the mechanism offered in the new version of
the draft
which enables the sending agent to verify that the revocation message is not
a reflection.

Thanks,
Ahmad

> -----Original Message-----
> From: The IESG [mailto:[email-masked]] 
> Sent: Friday, February 21, 2003 2:28 PM
> To: IETF-Announce
> Cc: [email-masked]
> Subject: [mobile-ip] Last Call: Registration Revocation in 
> Mobile IPv4 to Proposed Standard
> 
> 
> The IESG has received a request from the IP Routing for 
> Wireless/Mobile Hosts Working Group to consider Registration 
> Revocation in Mobile IPv4 
> <draft-ietf-mobileip-reg-revok-05.txt> as a Proposed Standard.
> 
> The IESG plans to make a decision in the next few weeks, and 
> solicits final comments on this action.  Please send any 
> comments to the [email-masked] or [email-masked] mailing lists 
> by 2003-3-7.
> 
> Files can be obtained via 
> http://www.ietf.org/internet-drafts/draft-ietf-mobileip-reg-re
vok-05.txt

---

From: "Steven M. Glass" <[email-masked]>
Date: Mon, 24 Feb 2003 17:08:35 -0500

On Monday, February 24, 2003, at 03:03  PM, Ahmad Muhanna wrote:

> Could you please elaborate on the mechanism offered in the new version 
> of the draft
> which enables the sending agent to verify that the revocation message 
> is not a reflection.

> Ahmad,

     Note, first, that reflected revocation messages aren't as damaging 
as one may suppose.  Even if a reflected revocation is processed, by 
definition there are no effected bindings (because an agent transmits a 
revocation message to communicate they're demise).  Of course, it is 
important to minimize the processing overhead in receiving reflected 
revocation messages, and though the specifics of such a mechanism are 
left to implementors, as outlined a bit more in section 7, the 
homeAddress and time-stamp fields are used for this purpose:

     - Upon _sending_ a revocation message, the agent MUST remember the 
homeAddress and timestamp of the revocation message.  This is used 
primarily when the agent _receives_ a revocation *acknowledgment* to 
compare the homeAddress and time-stamp in that ACK with that of 
outstanding revocation messages, thereby canceling the retransmit timer 
for this revocation message.

     - Upon _receiving_ a revocation *message*, the agent checks 
[minimally] the homeAddress and timestamp of the revocation message 
(which it had to store as indicated above), and compares it with those 
it has outstanding.  If a match is found, the packet can be deemed to 
be a replay.

     If you feel there needs to be some more specific clarification, a 
short paragraph can certainly be added.

                               Cheers,
                                   Steve