Subject: RE: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails

From: "Kent Leung \(kleung\)" <[email-masked]>
Date: Sat, 24 Jun 2006 09:58:48 -0700

Hi Kuntal.

> > 
> > I think mucking with the MN-HA AE is not good.  This can create the 
> > situation when MN sends a valid RRQ, and MITM can send a RRP with
> error
> > code 131 and invalid MN-HA AE to the MN immediately.  When 
> the RRP is 
> > received, the MN will stop retrying.  It's possible that 
> the RRQ was 
> > lost in transit to the HA.  And even if the valid RRP arrives later,
> MN
> > may not be able to associate with the any pending RRQ, which could
> have
> > been possibly removed since an associated RRP had been received
> already.
> > 
> [KC>] If the HA does not send RRP back to the MN, as you 
> initially suggested, the MN will keep retrying. That is not 
> good either.
> 

Let's not mix two issues:

1) When processing the RRP, MN discards the message if authentication
fails
   as clearly stated in RFC.  This message is _not_ processed.

2) The security exception is logged by the MN when this happens as
clearly
   stated in RFC.  There is no mention that registration retransmission
stops.
   I believe there's good reason for the omission because such message
is
   indeed _not_ authenticated and should not be trusted.

So I believe even sending bogus authenticator in MHAE will not work well
in accordance to the RFC.

> Look at other protocols. For example EAP, if auth fails, the 
> authenticator MUST send back a failure packet to the peer. 
> Same case for other protocols over UNI. So, I am wondering 
> why the paranoids are not concerned about MiTM and DoS 
> attacks in general!
> 
> Regarding your comment "mucking with the MN-HA AE is not 
> good", if MN-HA AE is not absolutely necessary in the RRP 
> messages, I will be more than happy to propose that when code 
> 131 is included, the RRP contains no MN-HA AE. However, MN-HA 
> AE is a MUST in RRP. So, unless you have a better suggestion 
> that does not break current implementations, and does not 
> produce a new mip4 protocol, I don't think we have a choice here.
> 
> 

My view is that the MN/HA needs the mobility security association to
calculate the authenticator value used in the MHAE to be appended to the
RRQ and RRP.  So without any SA, the MHAE cannot be appended and
therefore, RRQ/RRP cannot be sent.  If there is an SA, then from MN/HA's
view, that is the SA to use to protect the RRP.  It's up to the
administrator to decide which side has the incorrect key, not MN/HA's
judgement.

The security exception event is logged on both MN and HA.  The SNMP trap
can inform the admin to fix the problem.

As for the bandwidth issue, a good backoff registration mechanism should
not consume much at all before the problem is dealt with.  BTW, there is
no service when registration fails so it's very obvious to the end user.
But logging in the network should have caught it right away.

3.6.3. Registration Retransmission 

   "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 there is a misconfiguration of SA on either MN or HA, both sides
will log a security exception.  If HA doesn't have an SA, then only HA
log the security exception.  The registration backoff mechanism on MN
reduces link consumption.  I think we can work in accordance to RFC by
setting up an default SA between MN and HA for authentication failure
case.  At least, then MN know it's a legit RRP.  Else, stick with the
rules specified by RFC 3344 today.

Kent

-- 
Mip4 mailing list: [email-masked]
    Web interface: https://www1.ietf.org/mailman/listinfo/mip4
     Charter page: http://www.ietf.org/html.charters/mip4-charter.html
Supplemental site: http://www.mip4.org/

---

From: Henrik Levkowetz <[email-masked]>
Date: Sat, 24 Jun 2006 19:40:40 +0200

Hi Kent,

  I agree to your points below, but think that this is to some extent
missing the issue:

on 2006-06-24 18:58 Kent Leung (kleung) said the following:
>> > situation when MN sends a valid RRQ, and MITM can send a RRP with error
>> > code 131 and invalid MN-HA AE to the MN immediately.  When  the RRP is 
>> > received, the MN will stop retrying.  It's possible that  the RRQ was 
>> > lost in transit to the HA.  And even if the valid RRP arrives later, MN
>> > may not be able to associate with the any pending RRQ, which could have
>> > been possibly removed since an associated RRP had been received already.
>> > 

Agreed.

>    stated in RFC.  There is no mention that registration retransmission stops.
>    I believe there's good reason for the omission because such message is

Agreed.

What these two point don't cover is the behaviour of the HA.  If the HA
simply doesn't send back a reject, because it can't create a valid MN-HA AE,
this cannot be logged by the MN, and the MN has less information than it
could have.  I think we can do better, which is what we should focus on.

	Henrik