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

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 27 Feb 2003 07:37:11 -0600

I think that will take care of it. 
However, the less the number of FA-HA keys to be maintained is the better.

What about if we include two bits in the revocation message, one for FA 
and the other for HA. Checking that bit will reduce even the overhead
processing.

e.g.

   The UDP header is followed by the Mobile IP fields shown below

    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      |     Mask      |I|F|H|         reserved        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Home Address                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Home Domain Address                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Foreign Domain Address                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Revocation Identifier                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Type    To be assigned by IANA.  (Registration Revocation)

        Mask    A set of flags indicating the applicability of the
                registration revocation.  See Section 3.2.1 for
                definitions.

        I       Inform bit.

                This bit MUST NOT be set to '1' unless 'I' bit support
                was negotiated in the revocation extension messages 
                passed in the registration process, otherwise the
                results can be unpredictable.

        F       Foreign Agent bit.

                This bit MUST be set to '1' if the sending agent is a
                Foreign Agent otherwise it MUST be set to '0'.

        H       Home Agent bit.

                This bit MUST be set to '1' if the sending agent is a
                Home Agent otherwise it MUST be set to '0'.

Regards,
Ahmad

> -----Original Message-----
> From: Mike Borella [mailto:[email-masked]] 
> Sent: Thursday, February 27, 2003 7:12 AM
> To: Muhanna, Ahmad [RICH2:2Q30:EXCH]; 'Steven M. Glass'
> Cc: [email-masked]; madhavi Chandra; 'Pete 
> McCann'; 'Kuntal Chowdhury'
> Subject: RE: [mobile-ip] Last Call: Registration Revocation 
> in Mobile IPv4 to Proposed Standard
> 
> 
> 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
> 
> --- Ahmad Muhanna <[email-masked]> wrote:
> > 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
> > 
> 
> 
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Tax Center - forms, calculators, tips, more 
http://taxes.yahoo.com/

---

From: Mike Borella <[email-masked]>
Date: Thu, 27 Feb 2003 07:15:16 -0800 (PST)

Or just one bit, 0 for messages sent by the FA, 1 for
messages sent by the HA?

Mike

--- Ahmad Muhanna <[email-masked]> wrote:
>     0                   1                   2       
>            3
>    |                          Home Address          
>               |
>    |                       Home Domain Address      
>               |
>    |                      Revocation Identifier     
>               |

---

From: "Bryan Wang" <[email-masked]>
Date: Thu, 27 Feb 2003 13:51:16 -0800

Hi,

Just found one interesting scenatrio when testing our implemenation of
MIPv6:

I have a  MN with two addresses configured, A1 & A2. It sends two BUs to an
CN, one with A1 as the home address, A2 as the alt care of addrews, the
second the other way round. CN sucessfully creats the two bindings ;-). Now
my CN trys to send a packet to A1, it immediately runs out of memory! There
is a never ending recursion trying to find the CoA address. In our
implementation, we optimiz it to route looking up and sending packet through
a virtual device, which requires dynamic memory allocation.

Talked to Ed and we realized this might be a real DOS attack issue that we
should bring to the attention of the miling list.

Apparantly the quick solution would be adding a hard requirement as follows
to prevent creating an reverse binding.

CN MUST NOT send an COT message to an MN's care of address if it is the home
address in an exising binding.

Thanks,
Bryan Wang
Elmic Systems USA

---

From: "Bryan Wang" <[email-masked]>
Date: Fri, 28 Feb 2003 09:08:57 -0800

Hi,

Realized that a smart attacker can wait until the two RRP succeeds before
sending any BUs. The sulotion provided in the previous Email doesn't solve
the problem. Instead, we need a requirement like:

"When processing a valid BU that requests a CN to cache a binding, if the
care of address in the BU is the same as the home address of an existing
binding, the CN MUST selently discard the BU without creating any new
binding"

What do you think?

Thanks,
Bryan Wang
Elmic Systems USA

---

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

> Or just one bit, 0 for messages sent by the FA, 1 for

     One of the versions of the draft had this in there (at least for a 
while).

     I wasn't convinced the edge case - where the clocks on two agents 
are tightly enough in-sync to the second, that they both send identical 
revocation messages, and do so within 1/2 RTT between the agents [when 
using symmetrical keys] - created enough risk since the failure mode is 
totally non-destructive.  There's no risk to any bindings, and in the 
worst case the agents retransmit their revocation messages a few times, 
but only if their retransmit timers are the same [and nothing about the 
topology of the network changes], and even then it's only a 50% chance 
it'll happen the second time since the same time-stamp 'to the second' 
means 50-50 to the 1/2 second, or there about.  If not, in the second 
round someone has a different time stamp, which clears up the issue.  
Then again, it's 'just a bit', so I'm willing to be convinced otherwise 
if the argument is there.  For the record, I'd be more in favor of 
requiring asymmetric security, even if only a different shared secret 
for FA->HA and HA->FA using our authenticator scheme, but that's not 
part of core mobile-ip.

                               Cheers,
                                   Steve