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

From: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 15 Aug 2003 17:19:37 -0500

Hi Pete,
Please see comments inline.

Regards,
Ahmad
 
> 
> Hi, Ahmad,
> 
> A couple of questions on your proposal, and then a comment:
> 
> Ahmad Muhanna writes:
>  > 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 sendsRRQ(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:
>    ^^^^^^^^ I assume this is a typo, below is new text
[AM]
YES. 

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

>                         ^^^^^
> 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?
>

[AM]
To be exactly handled the same way a retransmit is currently done. i.e. it
depends on the state of the call at the FA.

>  >    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. 
> 
> So the MN should increment the Challenge field with each 
> retransmission?  Is that what you mean?  

[AM]
Yes.

> Does this mean the FA must be prepared to accept any of the currently
valid 
> challenges plus some window N?

[AM]
YES.
We may call it a tolerance window. Similar to what the HA has for the MN
with timesatmp replay protection.
> 
>  > Regards,
>  > 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.

[AM]
I agree.
> 
> 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.  
> 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.

[AM]
You are highlighting two issues here.
1. The channel is totally blocked (???) and all RRPs will be dropped in the
way to the MN. This scenario no one has a solution for and we should not
worry about fixing it.

2. The second issue is the one I am trying to solve. The incidental case
when the channel is congested and the RRP taking more time than expected to
arrive at the MN or the channel is congested that some of the RRP is dropped
BUT NOT every RRP is dropped.

My solution to this problem is to prevent Stale-Challenge DOS by allowing
the MN to indicate to the FA that it is a retransmit and the FA will accept
the RRQ and relay it to the HA. By NOT blocking the retransmit RRQ at the FA
due to STALE_CHALLENGE, a successful RRP with code (00) is always sent to
the MN. This gives the MN a chance to receive one successful RRP message
before MN hits its retry timer (retransmit timer).

i.e. In the example I outlined earlier, MN will receive RRP (ID4)
"successful" while it is tracking ID4. This makes the MN happy and
Re-Registration will complete successfully. 

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

[AM]
I think the process you just highlighted is to provide the MN with a dynamic
mechanism to detect the state of the link. I believe it is very difficult to
statically predict the sate of the link that the MN is attached to,
especially with inter-technology handoff, etc...

> 
> 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.
>
[AM]
Unfortunately, RFC3012bis broke the mechanism outlined above in section
3.6.3 (RFC3344) by the stale-challenge mechanism.
This solution is needed to enable the MN to make use of the above mechanism.

> -Pete

---

From: Pete McCann <[email-masked]>
Date: Mon, 18 Aug 2003 03:55:25 -0500

Hi, Ahmad,

 > depends on the state of the call at the FA.

So, you are saying that whether or not the FA has received a response
to the original RRQ from the HA, it forwards the new registration
request to the HA, not a copy of the old one, right?

You used the words "forwards the Registration Request to the Home
Agent again" but you didn't specify what you mean by "the Registration
Request".  The new one is not identical to the old one, as it differs
in both the Challenge and Identification fields.

 > with timesatmp replay protection.

So we have to be careful here - we are (slightly) weakening the
strength of the Challenge mechanism if we allow a whole range of
consecutive challenges to be valid at the FA instead of just one.  How
do we choose the proper window size?  Is it possible to characterize
the resulting strength/weakness of the challenge mechanism?

 > Re-Registration will complete successfully. 

But, what if the RRP (ID4) is delayed until the MN retransmits again?
Really, the root cause of this problem is that the MN didn't wait long
enough for the first response.

 > especially with inter-technology handoff, etc...

Well, I think you have to have some estimate of the RTT of the link
when choosing this parameter.  If you are running over a cdma2000 link
you probably should not set the initial retransmit interval smaller
than 4 seconds.

 > This solution is needed to enable the MN to make use of the above mechanism.

I don't think the retransmit mechanism is broken, you just need to
choose the right interval for the type of link you are on.

You have also pointed out that receipt of a STALE_CHALLENGE is really
at best an ambiguous indicator to the MN of whether or not it is
registered.  In the situation you outlined, the FA has a valid
registration renewal for the MN but the MN doesn't know it.  Perhaps
we should state that the MN should not disconnect itself merely
because its old Lifetime expired, when it receives one or more
STALE_CHALLENGE results from its attempts to register in the
meantime.  That is, if the MN can continue to send and receive packets
on the link, it is possible to keep going even though the MN's local
estimate of the Lifetime has expired.

-Pete

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