Subject: RE: [Sip] GRUU and Anonymity

From: Jeroen Van Bemmel <[email-masked]>
Date: Tue, 12 Sep 2006 18:41:11 +0200

Paul (and others),

The reason that the TRUU draft proposes explicit invalidation 
(which implies state at the registrar/proxy), is that I assumed a requirement that the UA would not even receive requests sent to an expired TRUU. The idea behind that is that it would prevent SPAM from consuming (wireless) resources; the UA could "step away" from an attack.

If this feature is not desired, then I agree a stateless approach is better (at least not state linear in the number of clients). The UA could mint its own TRUUs, along the lines that Dale sketched 

Regards,
Jeroen

--Oorspronkelijk bericht -----
Van: "Paul Kyzivat" <[email-masked]>
Aan: "Jeroen Van Bemmel" <[email-masked]>
CC: "Andrew Allen" <[email-masked]>; "Jonathan Rosenberg" <[email-masked]>; "IETF SIP List" <[email-masked]>
Verzonden: 12-9-06 14:59
Onderwerp: Re: [Sip] GRUU and Anonymity

The need to deallocate temporary gruus could be a problem. If you put 
the responsibility on the UAC to do it, what incentive does it have? Its 
easier to just not bother. And the registrar doesn't in general know 
when the old temp gruu is no longer needed. You could try to couple it, 
so that you can't get a new one without giving up your old one, but that 
isn't necessarily workable. (Wanting a new gruu for a new call doesn't 
mean that you are done with the earlier call.)

Its *way* better if the gruus are arranged so that there is no state 
retained that must be deallocated.

	Paul

Jeroen Van Bemmel wrote:
> Andrew,
> 
> Minor remark: de-allocation of a temporary GRUU would happen after call tear down, and not as part of call setup. Moreover, it could be optional.
> 
> Regards,
> 
> Jeroen
> 
> -----Oorspronkelijk bericht -----
> Van: "Andrew Allen" <[email-masked]>
> Aan: "Jonathan Rosenberg" <[email-masked]>; "IETF SIP List" <[email-masked]>
> Verzonden: 12-9-06 02:46

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: [email-masked]
Date: Tue, 12 Sep 2006 15:28:20 -0400

From: Jeroen Van Bemmel <[email-masked]>

   The reason that the TRUU draft proposes explicit invalidation
   (which implies state at the registrar/proxy), is that I assumed a
   requirement that the UA would not even receive requests sent to an
   expired TRUU. The idea behind that is that it would prevent SPAM
   from consuming (wireless) resources; the UA could "step away" from
   an attack.

Perhaps a merged implementation is feasible -- With every registration
refresh, the UA provides the proxy with the minimum TRUU sequence
number that is now valid.  This requires no more messages, but it
allows the proxy to block any SPIT that uses a TRUU that is
significantly out of date.

Dale

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 12 Sep 2006 16:10:07 -0400

Jeroen Van Bemmel wrote:

> Paul (and others),
> 
> The reason that the TRUU draft proposes explicit invalidation (which
> implies state at the registrar/proxy), is that I assumed a
> expired TRUU. The idea behind that is that it would prevent SPAM from
> consuming (wireless) resources; the UA could "step away" from an
> attack.

Thats an optimization, and its preventing something else entirely. 
Namely, it has nothing to do with anonymity at all. It has to do with 
DoS prevention or malicious attack prevention. Indeed it is better 
characterized as an anti-spam measure than anything else. Note that:

http://www.jdrosen.net/papers/draft-ietf-sipping-spam-02.txt

actually discusses Limited Use Addresses as an anti-spam vehicle.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Tue, 12 Sep 2006 23:11:49 +0200

> Thats an optimization, and its preventing something else entirely. Namely, 
> it has nothing to do with anonymity at all. It has to do with DoS 
> prevention or malicious attack prevention. Indeed it is better 

Truu, I only wanted to mention it to indicate there could be other 
considerations. I did add that reference to my working copy of the draft 
some time ago.

I believe it is possible to provide several "flavours" of GRUUs

1) minted by the domain, possibly with instance id, as currently defined
2) with limited lifetime
3) with explicit invalidation, ie blocked by the proxy (eg as anti-DoS/spam 
mechanism)
4) using encrypted pseudonyms generated by the UAC (to protect against 
correlation)

Although I see a need for these features, I also feel that the current GRUU 
draft provides sufficient value in itself. Moreover, the draft does not 
appear to prohibit adding these features at a later point in time. My 
proposal would be to finish the GRUU draft as-is, and define a WG work item 
for these additional features. Ultimately, an UA could then request and use 
the type of GRUU that is appropriate for its context (subject to domain 
policy).

Regards,

Jeroen

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Tue, 12 Sep 2006 23:11:49 +0200

Regards,

Jeroen