Re: [issue30] How to handle bad MN's authorization Token?

Rajeev Koodli <[email protected]> Mon, 15 Dec 2003 14:20:51 -0800
Newsgroups gmane.ietf.seamoby
Organization Nokia Research Center
Message-ID <[email protected]>
Nakhjiri Madjid-MNAKHJI1 wrote:

> Hi Rajeev,
>
> If you want the pAR to do something for every failed authentication
> token, then you are setting yourself for trouble (DoS attacks), especially
> since CT has to happen so quickly. Does the nAR has to keep any state?
>

each malicious MN can send one such bogus token. I think a DoS attack would
probably need a bigger incentive. FYI: in Fast Handovers, a MN is allowed to
send an FBU with a request to send an Ack. In Mobile IPv6, the 'A' bit
in BU requests the HA to send a Binding Ack. I don't see this as a loophole
to launch an attack. Am I missing something ?

The CT Request from nAR to pAR is in response to CTAR which includes the
MN's authorization token. The nAR has to match that with what pAR supplies.
The size of the token is 4 bytes. If a malicious MN is wants launch a DoS attack
on nAR's buffers, nAR can essentially stop being a router for that MN after the
token verification fails (after couple of tens of milliseconds).

I think the downside of not including the token opens up the possibility
to steal some other MN's contexts, which we must avoid.

-Rajeev


>
> Madjid
>
> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]]On Behalf Of Rajeev Koodli
> Sent: Friday, December 12, 2003 6:02 PM
> To: Nakhjiri Madjid-MNAKHJI1
> Cc: Seamoby CTP Issues; [email protected]
> Subject: Re: [Seamoby] [issue30] How to handle bad MN's authorization
> Token?
>
> Hi,
>
> is your concern message tampering between pAR and nAR ?
> If so, that should apply to all contexts. I think we address that
> by saying the routers SHOULD have SAs.
>
> Regards,
>
> -Rajeev
>
> Nakhjiri Madjid-MNAKHJI1 wrote:
>
> > Rajeev,
> >
> > I don't recall whether there was a message authentication procedure between
> > the pAR and nAR, if there is none, and the pAR can't verify the authorization
> > token, then we may open the door to DoS attacks on the pAR. So responding to
> > nAR may have bad consequences...
> > If there is no message authentication between nAR and pAR, while you are expecting
> > the MN to authenticate itself to pAR (to me this is half way solution), then the
> > pAR should ignore the request.
> >
> > Madjid
> >
> > -----Original Message-----
> > From: [email protected] [mailto:[email protected]]On Behalf Of
> > Rajeev Koodli
> > Sent: Monday, December 08, 2003 1:14 PM
> > To: Seamoby CTP Issues
> > Cc: [email protected]
> > Subject: Re: [Seamoby] [issue30] How to handle bad MN's authorization
> > Token?
> >
> > John Loughney SEAMOBY-Issues wrote:
> >
> > > New submission from John Loughney <[email protected]>:
> > >
> > > In case nAR requests the transfer by a CTR message, the pAR must verify
> > > the MN's authorization token. If this token is unvalid, what do we do ?
> > >
> > > Possible solutions:
> > >
> > >  - nothing ? the pAR does not answer to nAR.
> > >  - pAR indicates the error to nAR:
> > >         * In the CTD message.
> > >         * In a error message which could carry error information.
> > >
> >
> > pAR MUST respond to nAR with an appropriate error.
> > nAR SHOULD convey the result to the MN.
> >
> > -Rajeev
> >
> > >
> > > others ?
> > >
> > > ----------
> > > category: Editorial
> > > document: draft-ietf-seamoby-ctp-05.txt
> > > messages: 39
> > > nosy: jloughney
> > > priority: Should Fix
> > > status: No Discussion
> > > title: How to handle bad MN's authorization Token?
> > > _____________________________________________________________
> > > Seamoby CTP Issues <[email protected]>
> > > <http://danforsberg.info:8080/draft-ietf-seamoby-ctp/issue30>
> > > _____________________________________________________________
> > >
> > > _______________________________________________
> > > Seamoby mailing list
> > > [email protected]
> > > https://www1.ietf.org/mailman/listinfo/seamoby
> >
> > _______________________________________________
> > Seamoby mailing list
> > [email protected]
> > https://www1.ietf.org/mailman/listinfo/seamoby