I don't think that's a good idea. First of all you are adding a new Header and your falling in trap of an attacker.
-----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of radhakrishna Sent: Wednesday, July 14, 2010 10:42 PM To: 'Pandurangan R S' Cc: [email protected] Subject: Re: [Sip-implementors] How sip stack can recover from the followingerror condition..... How about adding a new header something like "Remort-CSeq: 10000" in 500 response? UAC can understand that the he has to increase the CSeq value to more than 10000 and can recover easily? Regards, RadhaKrishna -----Original Message----- From: Pandurangan R S [mailto:[email protected]] Sent: Thursday, July 15, 2010 7:34 AM To: radhakrishna Cc: [email protected] Subject: Re: [Sip-implementors] How sip stack can recover from the followingerror condition..... If the attacker is able to sniff and inject messages into the channel, then there are wide variety of attacks possible, as Brett has already indicated. So it is recommended to secure the channel using TLS or anything as such. Another possible attack is attacker can inject responses once he sniffs the request and the responses cannot be authenticated. So securing the channel is a recommended way to thwart these kind of attacks. > We suggest that RFC should have a way to convey the CSEQ value stored by UAS > in 500 response message so that UAC can come out of the loop. Nothing prevents the attacker from using a CSEQ of 2^32-1 (maximum possible value) On Wed, Jul 14, 2010 at 2:01 PM, radhakrishna <[email protected]> wrote: > Dear All, > > > > I want to know if there is any way to come out of the following problem. > > > > UAC UAS > > ----------------------------INV (CSEQ: 1) ------------------------> > > <---------------------------200 OK---------------------------------- > > ----------------------------ACK ------------------------------------> > > > > Attacker > > ----------------Update (CSEQ: 10000) ----------> > > <------------------- 401/407 ------------------------------ > > > > -----------------------UPDATE (CSEQ: 2) ------------------> > > <----------------------- 500 -------------------------------------- > > > > Now since the actual UAC is not aware of the attacker, he will keep > incrementing the CSEQ every time and will try to send the request. The > request would be successful only after trying for some 9999 times. How do we > overcome this kind of situation? > > > > We suggest that RFC should have a way to convey the CSEQ value stored by UAS > in 500 response message so that UAC can come out of the loop. > > Can anyone please share your opinion on this issue? > > > > Regards, > > RadhaKrishna > > > > > > > > _______________________________________________ > Sip-implementors mailing list > [email protected] > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
