Subject: [Mip4] New Issue: 3102bis Stale Challenge may cause a DOS

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 13 Aug 2003 11:03:05 -0500

Hello,

During an interoperability testing activity the Root Cause of the following
problem is caused by RFC3012bis not offering a clear retransmission
mechanism between the MN and the FA. The scenario goes as follows:

1. MN successfully Registers with the FA and receives a RRP (ID1) with a new
challenge (FAC1) 
2. MN starts downloading a large file which takes a long time. 
3. MN sends a RRQ (Re-Registration, ID2) with challenge (FAC1) and starts a
timer of (x seconds) before retrying. 
4. FA process the RRQ and forward to HA and relay to MN a successful RRP
(ID2) with challenge (FAC2). 
5. Since the MN is busy downloading a large file, MN does not receive RRP on
time.
6. MN retry timer expires and retransmits RRQ (ID3)using Challenge(FAC1) and
increase the retry timer to 2x seconds (RFC3344).
7. FA rejects RRQ and sends RRP (ID3) with "Stale Challenge" and Challenge
value (FAC2) 
8. For the same reason in step 5, MN retransmits RRQ (ID4) message with
challenge (FAC1) and increase timer to (4x seconds). 
9. FA rejects RRQ and sends RRP (ID4) with "Stale Challenge" and Challenge
value (FAC2)

10. MN receives RRP (ID2) before retry timer expires but ignores it because
it tracks ID4. 
11. MN receives RRP (ID3) before retry timer expires but ignores it because
it tracks ID4. 
12. MN receives RRP (ID4) before retry timer expires and act upon it, "Stale
Challenge"

13. MN uses challenge received in RRP(ID4) and sends RRQ(ID5). This RRQ is
not a retransmit, retry timer = x seconds.
14. The scenario continues as in steps 4-13.

15. This continue in infinite loop denying the MN Re-Registration and
eventually the MN loose its connection due to lifetime expiry. This causes a
DOS and prevents MN from downloading a large file.

The above scenario is basically caused by the fact that RFC3012bis
introduced the MN-FA challenge for replay protection without offering a real
retransmit mechanism between MN and FA to prevent such SERIOUS problem from
happening. For this problem I would like to offer the following solution:

1.)
OLD TEXT:
3.1. Mobile Node Processing for Registration Requests 
Retransmission behavior for Registration Requests is identical to that
specified in Mobile IP specification [7]. A retransmitted Registration
Request MAY use the same Challenge value as given in the original
Registration Request. 

PROPOSED TEXT:
Retransmission behavior for Registration Requests is identical to that
specified in Mobile IP specification [7]. A retransmitted Registration
Request MAY use the same Challenge value as given in the original
Registration Request or a Retransmit Challenge (see section 1.1).

2.)
OLD TEXT:
3.2. Foreign Agent Processing for Registration Requests
   If a mobile node retransmits a Registration Request with the same
   Challenge extension, and the Foreign Agent still has a pending
   Registration Request record in effect for the mobile node, then
   the Foreign Agent forwards the Registration Request to the Home
   Agent again. ...

   The Foreign Agent MUST NOT accept any Challenge in the Registration
   Request unless it was offered in last Registration Reply issued
   to the Mobile Node, or else advertised as one of the last
   CHALLENGE_WINDOW (see section 9) Challenge values inserted into the
   immediately preceding Agent advertisements. ...

PROPOSED TEXT:
OLD TEXT:
3.2. Foreign Agent Processing for Registration Requests
   If a mobile node retransmits a Registration Request with the same
   Challenge extension or a Retransmit Challenge, and the Foreign Agent 
   still has a pending Registration Request record in effect for the 
   mobile node, then the Foreign Agent forwards the Registration Request 
   to the Home Agent again. ...

   The Foreign Agent MUST NOT accept any Challenge in the Registration
   Request unless it was a Retransmit Challenge, offered in last
Registration 
   Reply issued to the Mobile Node, or else advertised as one of the last
   CHALLENGE_WINDOW (see section 9) Challenge values inserted into the
   immediately preceding Agent advertisements.  ...

1.1. Terminology
ADD the following definition:

Retransmit Challenge:
A challenge used by the MN to indicate to the Foreign Agent that it is
retransmitting its Registration Request. The value of the Retransmit
Challenge MUST equal the challenge value used in the MN latest Registration
Request plus 1. 

Regards,
Ahmad

---

From: Pete McCann <[email-masked]>
Date: Fri, 15 Aug 2003 12:29:16 -0500

Hi, Ahmad,

A couple of questions on your proposal, and then a comment:

 >    immediately preceding Agent advertisements. ...
   ^^^^^^^^ I assume this is a typo, below is new text
 >    to the Home Agent again. ...
                        ^^^^^
If the MN uses a "Retransmit Challenge", then which registration
request should be forwarded to the HA here - the old one or the new
one?

 > Challenge MUST equal the challenge value used in the MN latest Registration

So the MN should increment the Challenge field with each
retransmission?  Is that what you mean?  Does this mean the FA must be
prepared to accept any of the currently valid challenges plus some
window N?

 > Ahmad

I agree with you that Challenge values become STALE_CHALLENGE only
after the FA receives the RRP from the HA, which is a bit strange,
because it means that you can retransmit a request (and it will be
accepted and forwarded by the FA) only up to the point where the FA
receives the response from the HA.  After that, if you lose/delay the
RRP on its way to the MN, new retransmissions received by the FA will
be interpreted as STALE_CHALLENGE.  I think the assumption was that
eventually, the MN will get a clean request/response end-to-end, and
registration will complete.

If, as you point out, the forward channel towards the MN is congested,
and it is impossible to guarantee timely delivery of the RRP, the MN
may not receive the RRP before it increments the ID field (note that
only the Timestamp based replay protection causes the ID field to
increment on a retransmission) and retransmits the request.  If the
channel is still congested, it may never receive a valid response to
its most recently transmitted registration request.

However, I fail to see how your changes fix this problem.  It seems
like even if we had a way to indicate the presence of a retransmission
to the FA, the circumstances that you outline could still take place.
In fact, RRPs may be dropped entirely on the reverse link due to
congestion, not just arrive late.  It is true that the challenge
response mechanism introduces a new failure case (STALE_CHALLENGE),
but this seems incidental to me.

Rather, I think we can only fall back on this text which is in RFC 3344:

   The maximum time until a new Registration Request is sent SHOULD be
   no greater than the requested Lifetime of the Registration Request.
   The minimum value SHOULD be large enough to account for the size of
   the messages, twice the round trip time for transmission to the home
   agent, and at least an additional 100 milliseconds to allow for
   processing the messages before responding.  The round trip time for
   transmission to the home agent will be at least as large as the time
   required to transmit the messages at the link speed of the mobile
   node's current point of attachment.  Some circuits add another 200
   milliseconds of satellite delay in the total round trip time to the
   home agent.  The minimum time between Registration Requests MUST NOT
   be less than 1 second.  Each successive retransmission timeout period
   SHOULD be at least twice the previous period, as long as that is less
   than the maximum as specified above.

So, if you know you are on a link with a lot of buffering, you should
increase the minimum interval between retransmissions to take into
account the worst-case round trip time.  This will ensure that, if
there is any response to your request in the queue, you will
get it prior to retransmitting.

The basic Mobile IP message flow requires a complete round-trip
between MN & HA, where no link along the path drops the message.
Retransmission is performed end-to-end.  I don't see how or why we
should change this.

-Pete

_______________________________________________
Mip4 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mip4