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

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 26 Feb 2003 17:29:23 -0600

Hi Steve,
Please see my comments inline.
Sorry for the late response. It is the ICE storm!!

Regards,
Ahmad

> 
> 
> On Monday, February 24, 2003, at 03:03  PM, Ahmad Muhanna wrote:
> 
> > 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.
> 
> > 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).  

[A.M.]
If that is the understanding, why we need a MUST to force the sending agent
to
enforce this rule while the protocol does not give it a mechanism to verify
it.

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

[A.M.]
I believe that if we are proposing a new protocol for MIP revocation, 
this piece can not be left to implementation. You are correct if there are
more than mechanism which can be used. However, I do not see any mechanism
which
would satisfy the statement in section 3.5, I quoted above.

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

[A.M.]
In the version 04 of the draft there was 64 bits in the revocation message
ID.
As I remember the low-32 bits is extended to uniquely identify the entry
which
is revoked. Then, I agree we had a mechanism against malicious reflectors.
However, in version 05 of the draft, we do not have that uniqueness.

In other words, in the case that the sending and receiving agents have their
clocks
in SYNC "very possible", then the homeaddress and the ID timestamp is NOT
enough to
identify the sending agent.

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

[A.M.]
If the agents' clocks are in sync which is very possible, the above
statement is NOT
TRUE. It could be a real revocation message sent at the same time from the
other 
agent.

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

[A.M.]
My whole point here is that If we specify a requirement which is a MUST, we
Must provide
a mechanism to enable that requirement. Let us look at the following:

1. The sending agent sends a Revocation message REV1 with ID=T1.
2. Before the sending agent receive an acknowledgement, it receives
a revocation message DUPREV1 (reflection) with the same homeaddress and
ID=T1.
3. Off course if the agents are NOT in SYNC "Which is the greater
possibility",
the sending agent MAY know that this revocation is a reflection.
4. However, if it happened that both clocks of the sending and receiving
agents are
is SYNC, then there is no way for the sending agent to know if this
revocation message 
is a reflection or a real revocation message coming from the other agent.

The problem is: If the sending agent accepts DUPREV1 and also cancel
the timer for retransmitting "because it does not make sense to retransmit
at this point"
AND at the same TIME, the REV1 NEVER made it to the other agent (very
possible), we here 
are proposing a hole and a possibility that the other agent NEVER Revokes
the specified
(entry/entries).

>                                Cheers,
>                                    Steve

---

From: Mike Borella <[email-masked]>
Date: Thu, 27 Feb 2003 05:11:40 -0800 (PST)

Perhaps it is a little late in the game for this, but
wouldn't the whole reflection attack go away if there
were two half-duplex FA-HA keys instead of just one?

Mike

> other agent NEVER Revokes

__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/

---

From: "Steven M. Glass" <[email-masked]>
Date: Fri, 28 Feb 2003 22:06:13 -0500

I have no time to respond until just now, and I don't even really 
have the time still, so sorry if this is brief, though I hope it's 
sufficient...

On Wednesday, February 26, 2003, at 06:29  PM, Ahmad Muhanna wrote:

> If that is the understanding, why we need a MUST to force the sending 
> agent to
> enforce this rule while the protocol does not give it a mechanism to 
> verify it.

     I don't understand what you're saying here - are you saying we need 
a MUST to indicate reflection detection?  The document says the 
receiving agent MUST check auth and reflection.  When a binding is 
revoked by an agent, that agent sends the revocation notice to the 
peer.  If it's reflected, the agent should ignore it, at least it would 
be in the best interest of the implementation to not process it.  The 
point I was making above is that if the reflection was processed 
anyway, it couldn't result in the destruction of valid bindings, so 
reflection detection is required only to save on processing overhead 
for the agent.

> more than mechanism which can be used. However, I do not see any 
> mechanism which
> In the version 04 of the draft there was 64 bits in the revocation 
> message ID.
> As I remember the low-32 bits is extended to uniquely identify the 
> entry which
> In other words, in the case that the sending and receiving agents have 
> their clocks
> in SYNC "very possible", then the homeaddress and the ID timestamp is 
> NOT enough to
> TRUE. It could be a real revocation message sent at the same time from 
> the other
> agent.

     If both agents revoke the same [set of] binding[s] at the 'same' 
time, then the bindings exist on neither agent, so what's the problem?

> My whole point here is that If we specify a requirement which is a 
> MUST, we Must provide
> a revocation message DUPREV1 (reflection) with the same homeaddress 
> and ID=T1.
> 4. However, if it happened that both clocks of the sending and 
> receiving agents are
> the timer for retransmitting "because it does not make sense to 
> retransmit at this point"

     Receiving a revocation which is suspected of being a reflection 
does NOT negate the need to receive an ACK for that revocation (nor 
should it prompt the generation of an ACK, which is far worse than 
ignoring it).

> are proposing a hole and a possibility that the other agent NEVER 
> Revokes the specified
> (entry/entries).

     ...and in this way the agent retransmits the revocation message.

                                Cheers,
                                    Steve

---

From: "Steven M. Glass" <[email-masked]>
Date: Fri, 28 Feb 2003 22:07:18 -0500

On Thursday, February 27, 2003, at 08:11  AM, Mike Borella wrote:

> Mike,

    One of the strong authentication mechanisms we mention in the draft 
is IPSec in which you can have this sort of asymmetry.

                            Cheers,
                                Steve