Re: [Sipping] Exploders drafts

[Cullen Jennings <[e-mail]>]

Few comments on these.

On draft-camarillo-sipping-exploders-03.txt section 1 - para 2.

This nicely points out the requirements for exploders - I like it. It does
seem like a reasonable compression scheme would solve this requirement
equally well. Other explained to me this does not work due to inadequacies
in sigcomp but might be worth pointing this out.

You might make an argument that a solution that took all the final exploded
messages and sent them over an appropriately compressed link uses no more
bandwidth on behalf of the sender than this and resulted in the same
bandwidth usage on the receivers part and therefore the scheme proposed here
was no worse a DOS attack problem than say compressed access links are.

I imagine recommending logging as a solution for SPAM with exploders is
going to, ah, raise some concerns about the desirability of this scheme.

In the section on saying users must agree to receive stuff from an exploder,
it would be nice to say that users must be able to easy revoke this. Having
an explicit SIP mechanism for a user to grant permission to receive
explosions, and more importantly, remove that permission grant, would make
this better. It's interesting, in many ways the exploders is similar to
publish but publish did not seem to have the same range of concerns about
amplification, DOS, and message relay. Might want to figure out how to make
it have the security properties more like publish.

On draft-garcia-sipping-message-exploder-00.txt

The embedded headers in the URI are nice but raise lots of issues. For
example, if I insert a P-Asserted-Identity header with a fake name, will it
be used? Or perhaps a Route header that caused the message to go to someone
that had not agreed to receive exploded messages.

The " The MESSAGE exploder MUST NOT copy any security body (such as an
      S/MIME signed body) addressed to the MESSAGE exploder to the
      outgoing MESSAGE request.  This includes, e.g., security bodies
      signed with the public key of the exploder."
This confuses me. If it was signed, it would be signed with the public key
of the UA sending the request to the exploder? I'm just not sure what you
are getting at with this. Is this the exploder must not relay any S/MIME
body? 

In the security section - last paragraph. Not sure what you are proposing
here. If I wanted to send an encrypted message to A and B, what would I do.
I assume encrypt the List A,B with the public key of the exploder then
provide a copy of the message that was encrypted with a content encryption
key (call it the CEK) then encrypt the CEK with the public key of A and
separately with B then bundle this all up somehow and send it.  You mention
integrity protection with S/MIME too - are you assuming that the exploder
knows the public key of the UA sending the request?

If the exploder has authenticated the sender, perhaps it should put the
identity of the sender in the From of the messages it sends. This raises
issues with trying to be Anonymous and user an exploder but perhaps this is
a feature not a bug.

I don't feel strongly about these drafts one way or another so I hope these
comments get somewhat discounted as casual passer by - I know others have
thought about it much more. Perhaps the amplification issue in this B2BUA
based solution can be justified as no worse than the alternative solution to
the problem using compression with a proxy.

Cullen 




On 5/14/04 5:46 AM, "Gonzalo Camarillo" <[e-mail]>
wrote:

> Folks,
> 
> I have just submitted the following draft. Until it appears in the
> archives, you can fetch it from:
> 
> http://standards.ericsson.net/gonzalo/papers/draft-camarillo-sipping-exploders
> -03.txt
> 
> It describes the exploders' requirements and a framework to meet them.
> The framework includes references to the following documents, which will
> be discussed in the interim as well:
> 
> http://www.ietf.org/internet-drafts/draft-camarillo-sipping-uri-list-02.txt
> http://www.ietf.org/internet-drafts/draft-camarillo-sipping-adhoc-conferencing
> -00.txt
> 
http://www.ietf.org/internet-drafts/draft-camarillo-sipping-adhoc-simple-00.tx>
t
> http://www.ietf.org/internet-drafts/draft-garcia-sipping-message-exploder-00.t
> xt
> 
> Best regards,
> 
> Gonzalo
> 
> 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [e-mail] for questions on current sip
> Use [e-mail] for new developments of core SIP
> 


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