Subject: Re: [MOBILE-IP] RFC2002 bis

From: Sufatrio <[email-masked]>
Date: Mon, 13 Mar 2000 23:40:24 +0800

Hi Kent,

In a situation where:
no secret-key based security association exists between MN and FA,
or public-key based authentication is not in use,
there is no way for MN to directly verify the authenticity/integrity of
a rejected Request message from FA.

Since RFC2002 only mandates the existence of shared-key based
security association between MN and HA, I think I agree
with you that more detailed specification is required
should FA reject a Request (with regard to the genuineness of that Replay).

An alternative strategy is that either :
(I assume that FA and HA can authenticate each other)

(1)  FA still relays the Request message to HA (with the indicated error
code)
     just in order for MN to get an authenticated (Mobile-Home-AE) rejected
Reply.
     This might be useful for error codes such as:
        69 requested Lifetime too long,
        72 requested encapsulation unavailable,
        73 requested Van Jacobson compression unavailable,
     which FA still can expect MN to send a valid Request in its next
registration attempt.

(2)  FA sends an unauthenticated Replay for error codes that are considered
"fatal"
     or that option (1) above is not possible to be carried out, such as:
        70 poorly formed Request
        80 home network unreachable (ICMP error received)
        81 home agent host unreachable (ICMP error received)
        82 home agent port unreachable (ICMP error received)
     However, in this case MN must intelligently wait for some time, in
order to
     anticipate a case where a bad guy sends a rejected Reply that comes
earlier
     than its genuine successful Reply (which you mentioned in your email).

Cheers,
~rio

> ----------
> From:         Kent K. Leung[SMTP:[email-masked]]
> Reply To:     Kent K. Leung
> Sent:         08 March 2000 13:54
> To:   [email-masked]
> Subject:      Re: [MOBILE-IP] RFC2002 bis
>
> One area that's not covered by RFC2002bis is how Mobile Node
> as well as Foreign Agent should deal with Mobile-Home Authentication
> Extension (MHAE) when FA replies with error code.  There are 2 scenarios
> when FA rejects registration: 1) FA denies registration request
> (ie requested lifetime greater than advertised) and 2) FA sends
> rejection when HA reply is bad (ie Foreign-Home Authentication
> Extension check fails).  In either case, the authenticator in
> Mobile-Home Authentication Extension is invalid when received by
> MN.
>
> So when registration is rejected by FA, the MN will silently
> discard reply because authenticator is invalid.
>
> Seems like some MN implementation skips MHAE if the error code
> is from FA.  But then this can lead to bad guy sending rejections
> even when registration being accepted by HA, maybe a little later.
> One possible solution is that MN can believe rejection reply if
> MFAE exists or after it allows enough time for reply from HA to arrive.
>
> We need some more information in section 3.6.2.3 "Registration Request
> Denied" in how Mobile Node handle denials from FA, section 3.7.2.3
> "Denying Invalid Requests" and section 3.7.3 "Receiving Registration
> Replies" in how FA deal with MHAE when generating a rejection reply.
>
> -- Kent --
>
> >
> > It's important to turn this around quickly if we want it to replace 2002
> and
> > then move this from proposed standard to draft standard.  We discussed
> in
> > Washington about the amount of work that will be involved from moving to
> > proposed to draft and agreed that we should update 2002 while working on
> > getting enough implementations to move to draft standard.  Getting the
> > replacement done quickly would allow us to get to draft standard this
> year,
> > hopefully.
> >
> > Phil
>