Subject: [mobile-ip] mipv6: reject BU without performing cryptographic operations

From: "Bryan Xiangqian Wang" <[email-masked]>
Date: Tue, 29 Oct 2002 16:24:06 -0800

Hi,

There seems to be hidden issue in draft-ietf-mobileip-ipv6-18++.txt section 14.4.4.

"... If a correspondent
   node finds that it is spending more resources on checking bogus
   Binding Updates than it is likely to save by accepting genuine
   Binding Updates, then it may reject some or all Binding Updates
   without performing any cryptographic operations."

To reject a BU, CN can't silently drop it since MN would interpret the dropping as accepting if BU comes with A bit reset, CN has to send a BA with an appropriate status code.

130(Insufficient resources) seems to be appropriate, however it requires that an authenticator MUST be included within the BA, which requires the cryptographic operations (section 9.4.4) and therefore goes against the original purpose of rejecting the BU. 

137(Invalid authenticator) requires that an authenticator MUST NOT be included in the BA, but it is not always the right code to use since some of the BUs rejected in this case might have valid authenticator.

Proposal: 
Split code 130(Insufficient resources) into: 
   130 (Insufficient storage space), requires authenticator, keep the usage as is. 
   141 (Insufficient computation power), doesn't require authenticator, use it when CN decides to reject BUs without performing any cryptographic operations.

Thanks,
Bryan Wang
Elmic Systems, USA
(909)787-8475

---

From: Jari Arkko <[email-masked]>
Date: Wed, 30 Oct 2002 03:15:58 +0200

Bryan Xiangqian Wang wrote:
> To reject a BU, CN can't silently drop it since MN would interpret the 
> dropping as accepting if BU comes with A bit reset, CN has to send a BA 
> with an appropriate status code.
>  
> 130(Insufficient resources) seems to be appropriate, however it requires 
> that an authenticator MUST be included within the BA, which requires the 
> cryptographic operations (section 9.4.4) and therefore goes against the 
> original purpose of rejecting the BU.
>  
> 137(Invalid authenticator) requires that an authenticator MUST NOT be 
> included in the BA, but it is not always the right code to use since 
> some of the BUs rejected in this case might have valid authenticator.
>  
> Proposal:
>    141 (Insufficient computation power), doesn't require authenticator, 
> use it when CN decides to reject BUs without performing any 
> cryptographic operations.

I see the problem, thanks for noticing this!

Perhaps there are more ways than the above one to solve this.
These are:

1) Clarify that its a silent discard. Note that MNs can't
    rely on getting problem acks with A=0 anyway. BUs could
    get dropped on the way. Luckily there are facilities
    to get us out of the problem, BE and all. Perhaps we
    should RECOMMEND setting the A bit.
2) Making 130 always unauthenticated
3) 130-141 split as proposed above

I'm inclined to think that under severe load, we will be getting
packets dropped or silent discards regardless of what we say in
the specification. So this appears to be the baseline that has
to work anyway. So I'd rather just use this approach than add
new status codes.

In 14.4.4, change

    reject => silently discard

To make a stronger recommendation for A=1, I'd change

    Binding Updates sent to correspondent nodes are not generally
    required to be acknowledged.  However, ...

    =>

    It is RECOMMENDED to acknowledge Binding Updates sent to correspondent nodes,
    even if this is not mandatory. ...

Jari

---

From: "Bryan Xiangqian Wang" <[email-masked]>
Date: Tue, 29 Oct 2002 18:58:18 -0800

Hi Jari,

Thanks, this solves the problem. However, in this particular case, If MN
sends a BU with A=1, it would have to retransmit MAX_BINDACK_TIMEOUT /
MAX_UPDATE_RATE = 256 times in vain in the unlucky case that the CN is
silently dropping all BUs within the whole period of MAX_BINDACK_TIMEOUT.
However again, as you said, severe load that causes the CN to drop BUs
should be considered rare case. Therefore, this might not be a problem
practically. I'm fine with this solution and also open to others.

You solution #2 actually looks equally good to me. Security level is
sacrificed a bit, but not that much since we already have 137-140
unauthenticated, malicious node can spoof BA with code>128 anyways. What we
loose is that MN can no longer verify that an real honest BA with 130 is
really honest. If we split 130 into 130 and 141, we recover half of the lost
;-)

Thanks,
Bryan

----- Original Message -----
From: "Jari Arkko" <[email-masked]>
To: "Bryan Xiangqian Wang" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, October 29, 2002 5:15 PM
Subject: Re: [mobile-ip] mipv6: reject BU without performing cryptographic
operations