2010/3/22 WORLEY, DALE R (DALE) :
> A.2. Temporary GRUU
>
> This specification requires a registrar to create a new temporary
> GRUU on each registration refresh. If a registration is very long
> lived, this can quickly result in hundreds or even thousands of
> temporary GRUUs being crea
From: sip-implementors-boun...@lists.cs.columbia.edu
[sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Paul Kyzivat
[pkyzi...@cisco.com]
I thought this was discussed in the RFC. (But I'm too lazy to check
right now.)
__
Iñaki Baz Castillo wrote:
> But if the algorithm for constructing temp gruus would be known then
> it would become a vulnerability :(
Security by obscurity is never a great choice.
Crypto techniques can largely avoid the vulnerability.
I thought this was discussed in the RFC. (But I'm too laz
2010/3/21 Paul Kyzivat :
> Iñaki,
>
> This is probably far from obvious.
>
> The reason for creating new ones was because for anonymization purposes you
> probably don't want to keep using the same one. It would have been better to
> have an explicit mechanism to request when you want a new one, bu
Iñaki,
This is probably far from obvious.
The reason for creating new ones was because for anonymization purposes
you probably don't want to keep using the same one. It would have been
better to have an explicit mechanism to request when you want a new one,
but that didn't fit into the model w
2010/3/21 Iñaki Baz Castillo :
> Hi, after reading the RFC 5627 I don't understand why the registrar
> can create a new temp-gruu URI for each registration refresh.
> If it does so, the registrar would end with a database full of temp-gruu
> URI's.
>
> From the point of view of a registrar impleme
Hi, after reading the RFC 5627 I don't understand why the registrar
can create a new temp-gruu URI for each registration refresh.
If it does so, the registrar would end with a database full of temp-gruu URI's.
From the point of view of a registrar implementing GRUU, is it posible
to mantain an uni
