Fair enough, but then what do you do against fake BYE messages? If you do not authenticate them somehow, anybody could sniff the INV message (and OK/ACK), take the needed fields, and tear down the session. Of course, even if you protect against fake BYEs, there is still CANCEL messages, which according to the RFC cannot be challenged at all ... so maybe just drop them all?

I am just thinking outloud on how to harden a sip system ...

Cesc

...

...

Juha Heinanen jh@tutpro.com 05/03/05 04:07PM >>>

Cesc Santasusana writes:

For example, Kphone can resend an INV if challenged which contains the auth-data. On the other hand, if a kphone is the receiver of the INV, and it hangs up, kphone generates a BYE message which does NOT contain auth-data. Thus, ser will challlenge the kphone back, kphone will reply with a CANCEL and resend the BYE without (again) the auth-data, entering an endless loop. Ain't it funny?

bye is not initial request, but in-dialog request. it doesn't make sense to authenticate them, because you may not even know if the sender of bye is your local user or not.

for initial requests you always know this and thus can authenticate them.

-- juha Unclassified