RE: [Sipping] Pushing Policies towards the Sender's Domain
"Jeremy Barkan \(DigitalShtick\)" <jeremyb@digitalshtick.com> Wed, 27 June 2007 10:28 UTC
Return-path: <sipping-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3UlI-0001EP-5l; Wed, 27 Jun 2007 06:28:36 -0400
Received: from sipping by megatron.ietf.org with local (Exim 4.43) id 1I3UlG-00019S-DW for sipping-confirm+ok@megatron.ietf.org; Wed, 27 Jun 2007 06:28:34 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3Uk4-0007yM-Fi for sipping@ietf.org; Wed, 27 Jun 2007 06:27:20 -0400
Received: from pro22.abac.com ([66.226.64.23]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I3Ugb-0004wK-93 for sipping@ietf.org; Wed, 27 Jun 2007 06:23:45 -0400
Received: from Jeremyb2 (bzq-88-155-209-97.red.bezeqint.net [88.155.209.97]) (authenticated bits=0) by pro22.abac.com (8.13.8/8.13.8) with ESMTP id l5RAMvY5054367; Wed, 27 Jun 2007 03:22:59 -0700 (PDT) (envelope-from jeremyb@digitalshtick.com)
From: "Jeremy Barkan (DigitalShtick)" <jeremyb@digitalshtick.com>
To: "'Tschofenig, Hannes'" <hannes.tschofenig@nsn.com>, 'ext Saverio Niccolini' <Saverio.Niccolini@netlab.nec.de>, 'SIPPING LIST' <sipping@ietf.org>
Subject: RE: [Sipping] Pushing Policies towards the Sender's Domain
Date: Wed, 27 Jun 2007 13:22:55 +0300
Organization: DigitalShtick
Message-ID: <002b01c7b8a5$22ce2b80$6a00a8c0@Jeremyb2>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
In-reply-to: <0D22E3C1A7D7A843B12BF8C6F0A40758021EC4F1@MCHP7IDA.ww002.siemens.net>
Thread-Index: Ace1tz+aYLknVWzqSwqknhded+7BVwCL5pfQAADBJhAALlU5EA==
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 025f8c5000216988bfe31585db759250
Cc: 'Signaling TO Prevent SPIT' <spitstop@listserv.netlab.nec.de>
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "SIPPING Working Group \(applications of SIP\)" <sipping.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=subscribe>
Errors-To: sipping-bounces@ietf.org
Hi Hannes - Regarding domain crossing and policy - there would need to be some trust mechanism in order for the receiving domain [ either the terminating domain or some proxy/transit/provider domain in the downstream flow ] to apply the authorizations. If the authorization is end-to-end - the trust model is simplified [ such as SIP Identity ] and this is what I understood from the draft. If the authorization is distributed across the hops - it's more complicated, with all the fragility and complexity you mentioned of a chain of trust. In this case - we would need a framework [ SAML ] to express the relationships. Your thoughts ? Regards Jeremy -----Original Message----- From: Tschofenig, Hannes [mailto:hannes.tschofenig@nsn.com] Sent: Tuesday, June 26, 2007 3:26 PM To: ext Saverio Niccolini; SIPPING LIST Cc: Signaling TO Prevent SPIT Subject: AW: [Sipping] Pushing Policies towards the Sender's Domain Hi Saverio, > Hannes, > > > Hi Saverio, > > > > Saverio Niccolini wrote: > > > Hi Hannes, > > > > > > to add on what Juergen said, what we adressed in our SPITSTOP > > > draft was not meant to cover only the authorization policies > > > as you are saying, the authorization policies are just a > > special case > > > of the possible communications between domains, others are; > > > -- info related to SPIT estimations > > > > > > > Have you looked at the following document > > http://www.tschofenig.priv.at/drafts/draft-schwartz-sipping-spit-s > > aml-00.txt > > Is this close to the mechanisms you have in mind? > > (ignore the encoding in a SAML assertion for a moment) > > (Ignoring the SAML assertion for a moment) > I had a look at it some time ago (this draft expired in 2006), > I think the SPITSuspect security attribute is the most important > example of info to be exchanged, but also others are good examples, > anyway I think more can be added, maybe we can find time at next IETF > to discuss this. Sure, we can discuss this issue also at the IETF meeting. Re-writing the SAML SPIT draft I would probably separate the encoding from the security mechanisms. In any case, I believe you needs to be some sort of security, such as SAML, when you cross domain boundaries (unless you believe that the walled garden model with transitive trust is the right way to go). In the case where you are not crossing domain boundaries you might not need to integrity protect and authenticate the info. >From an encoding point of view there are essentially two ways: (a) You put the attributes into the SAML assertion That's even possible not to sign it if the info is just made available (for example, between your proxy and yourself). In this case you would just make the information available via an XML document. Since a proxy would add this info it would only attach a reference; if I, as an end host, do not care about the info then I just ignore it. (b) Alternatively, you could encode the info into a header (without using all the XML stuff). > > > > -- messages explaining to the sender domain why the message > > was blocked > > > > > If you are talking about ordinary SIP mechanisms then that is > > fine for > > me. This might help the sender > > Is this your intention or to share blacklists between the > two domains? > > This could be an example but also pushing back the SPITSuspect scores > or the reason why the callee's rejected a call could be othjer > examples (with the proper considerations to be applied) > I have seen proposals for individual calls and for bulk transfer of information. The use cases a somewhat different but the underlying mechanisms might be the same (i.e., the bulk transfer is just a concatenation of individual "spit" reports). The other question is also what you would like to report. > > > I clearly see these two points having priority over the > > authorization > > > polices when it comes to pushing info towards the sender domain. > > > > > In some sense this is quite similar to "authorization" > policies. The > > difference is, however, whether you do the interaction based on > > individual calls or on an aggregate > > I agree on this. Ciao Hannes > Cheers, > Saverio > > > > > Ciao > > Hannes > > > > > Cheers, > > > Saverio > > > > > > ============================================================ > > > Dr. Saverio Niccolini > > > Senior Research Staff Member > > > Network Laboratories, NEC Europe Ltd. > > > Kurfuerstenanlage 36, D-69115 Heidelberg > > > Tel. +49 (0)6221 4342-118 > > > Fax: +49 (0)6221 4342-155 > > > e-mail: saverio.niccolini@netlab.nec.de > > > ============================================================ > > > NEC Europe Limited Registered Office: NEC House, 1 Victoria > > > Road, London W3 6BL Registered in England 2832014 > > > > > > > > > > > > > > >> -----Original Message----- > > >> From: Juergen Quittek [mailto:quittek@netlab.nec.de] > > >> Sent: Sunday, June 17, 2007 2:30 PM > > >> To: Hannes Tschofenig; SIPPING LIST > > >> Subject: Re: [Sipping] Pushing Policies towards the > Sender's Domain > > >> > > >> Hi Hannes, > > >> > > >> I fully agree, that pushing policies between domains should > > >> get low priority at this point in time in the context of > > >> standards required for SPIT prevention. This is why we did > > >> not cover it in draft-niccolini-sipping-spitstop and just > > >> made the note that you cited below pointing to > > >> draft-froment-sipping-spit-authz-policies > > >> where it seemed that this was included. > > >> > > >> It is good that you replaced > > >> draft-froment-sipping-spit-authz-policies with > > >> draft-froment-sipping-spit-requirements that only focuses on > > >> requirements. > > >> > > >> Thanks, > > >> > > >> Juergen > > >> > > >> > > >> --On 16.06.07 16:03 +0200 Hannes Tschofenig wrote: > > >> > > >> > > >>> Hi all, > > >>> > > >>> when reading through the documents I came across the following > > >>> statement in <draft-niccolini-sipping-spitstop-00.txt>: > > >>> > > >>> " > > >>> Please note that the described reference scenario does > > >>> > > >> not addresses > > >> > > >>> management interfaces to entities involved in SPIT > > prevention. A > > >>> first approach to this issue has been made is described in > > >>> [I-D.froment-sipping-spit-authz-policies]. > > >>> " > > >>> > > >>> it seems that some parts of > > >>> <draft-froment-sipping-spit-authz-policies-02.txt> got > > >>> > > >> misunderstood. > > >> > > >>> There are some text paragraphs in > > >>> <draft-froment-sipping-spit-authz-policies-02.txt> that > > envisioned > > >>> that the authorization policies are distributed to other > > >>> > > >> domains, and > > >> > > >>> in particular towards the sender's domain. There is > obviously the > > >>> question what you would but in these policy documents, when to > > >>> distribute them and whether there are potential privacy > > >>> > > >> problems with that approach. > > >> > > >>> This is an interesting technical issue BUT I would put it on my > > >>> priority list for work that has to be done in the SPIT > prevention > > >>> space to the end of the queue. This lead us actually to > > >>> > > >> create a new > > >> > > >>> document (see > > >>> http://fon.gs/spit-requirements) that focuses purely on > > >>> > > >> requirements > > >> > > >>> for authorization policies that are not distributed > > between domains. > > >>> > > >>> I wonder what other people think about pushing policies > > towards the > > >>> sender's domain. > > >>> > > >>> Ciao > > >>> Hannes > > >>> > > >>> > > >>> _______________________________________________ > > >>> Sipping mailing list > > https://www1.ietf.org/mailman/listinfo/sipping > > >>> This list is for NEW development of the application of SIP Use > > >>> sip-implementors@cs.columbia.edu for questions on > current sip Use > > >>> sip@ietf.org for new developments of core SIP > > >>> > > >> > > >> -- > > >> Juergen Quittek quittek@netlab.nec.de Tel: +49 > > >> 6221 4342-115 > > >> NEC Europe Limited, Network Laboratories Fax: +49 > > >> 6221 4342-155 > > >> Kurfuersten-Anlage 36, 69115 Heidelberg, Germany > > >> http://www.netlab.nec.de > > >> Registered Office: NEC House, 1 Victoria Road, London W3 6BL, > > >> UK Registered in England 2832014 > > >> > > >> > > >> _______________________________________________ > > >> Sipping mailing list > > https://www1.ietf.org/mailman/listinfo/sipping > > >> This list is for NEW development of the application of SIP > > >> Use sip-implementors@cs.columbia.edu for questions on current > > >> sip Use sip@ietf.org for new developments of core SIP > > >> > > >> > > > > > > ============================================================ > Dr. Saverio Niccolini > Senior Research Staff Member > Network Laboratories, NEC Europe Ltd. > Kurfuerstenanlage 36, D-69115 Heidelberg > Tel. +49 (0)6221 4342-118 > Fax: +49 (0)6221 4342-155 > e-mail: saverio.niccolini@netlab.nec.de > ============================================================ > NEC Europe Limited Registered Office: NEC House, 1 Victoria > Road, London W3 6BL Registered in England 2832014 > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP
- [Sipping] Pushing Policies towards the Sender's D… Hannes Tschofenig
- Re: [Sipping] Pushing Policies towards the Sender… Juergen Quittek
- RE: [Sipping] Pushing Policies towards the Sender… Saverio Niccolini
- Re: [Sipping] Pushing Policies towards the Sender… Hannes Tschofenig
- RE: [Sipping] Pushing Policies towards the Sender… Saverio Niccolini
- AW: [Sipping] Pushing Policies towards the Sender… Tschofenig, Hannes
- RE: [Sipping] Pushing Policies towards the Sender… Jeremy Barkan (DigitalShtick)
- Re: [spitstop] [Sipping] Pushing Policies towards… Hannes Tschofenig