Subject: [Rucus] Meeting Minutes from F2F at IETF#73

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Mon, 17 Nov 2008 20:59:22 +0200

Meeting Minutes
===============

Participants:

- Hannes Tschofenig
- Mary Barnes 
- David Schwartz
- Roger Marshall
- Kai Fischer 
- Jan Seedorf
- Keith Drage
- Juergen Quitteck
- Thomas Froment
- Hendrik Scholz
- Jiri Kuthan
- Victor Pascual
- Salvatore Loreto
- Raphael Coeffic

Meeting Minutes: Hannes Tschofenig 

Hannes gives a short introduction of the history of the RUCUS EG. 

Dan: Proposal for forming an EG took longer and requires folks to write
short documents. 

Are we heading along the right path? Why didn't we got something done? 

Juergen: We have written drafts already. I have problems understandign
the intention of the IESG. 
I don't see on the path they are willing to set us. 

Keith: Why do you want to know? 
Media CTRL did not exist as a WG for a long time and the group met at
every IETF meeting. 

Juergen: What is the policy applied here? 

Dan: Step back to IETF#71 there was a lot of discussion and a lot of
push-back on providing differnet solutions. 

Keith: You still don't know which direction you would like to go. 

Mary: They are not going to give us directions. This group should put
together some building blocks together. 

Dan: The way forward was to create smaller, more generic building blocks

David: What is a success or a failure of an EG? 

Keith: You still need someone to chair the group. 

Dan: Who is writing the drafts? 

David: There are drafts already. 
We should be re-using what is already out there. 

Dan: Look at the proposed charter and what it wants from the small
drafts. 
The existing drafts don't discuss the 4 points. 

David: Individual building blocks work in isolation. 

Dan: Should we go back to the ADs and ask them for a different approach?

David: Where does the problem come in? Which part of the end-to-end
chain do we need to investigate? 
One problem at the edge, one problem at the interworking points, etc. 

Keith: The EG does not help you solving the scope problems. 

David: The problem is only at the edge, Hadriel says. 
I don't think that this is correct. 
SMS is a fascinating use case. 
Going to the spam score: where is it used? 

Dan: RFC 5149 provided potential solutions. It gives you the overall
problem statement but what are the specific solutions that have to be
put into an architecture.

David: We need to bring the solutions down to earth. 
RFC 5149 should be used heavily but it misses the architecture. It
misses the context. 

Thomas: The charter does not provide the architecture. Every document
needs to capture it. 

David: The use cases are so different: IMS, VoIP, SMS
We are not scoping it.

Dan: How do we move the discussion forward? 
I hear that we need a framework or a scope. 

Hendrik: Summarizes the SPIT attack in Germany.
Nobody knows what SPIT is going to look like. We would like to get some
feedback messages for the users towards the operator. 

David: You are describing solutions for unwanted calls.
Without looking at where the problems came from is quite easy. 

Raphael: The problem is always moving as adversaries use different
attack mechanisms. You need a lot of building blocks for different
categories. 

Jan: The phones were directly attack. 

David: This is very good input. We need these "problem vectors". 

Dan: We could look at them as one action items. 

Jan: Well. The solution on how to provide feedback would have helped. 

Dan: We shouldn't discuss these solutions. 
What actions should we take? 

David: It would be helpful to document about what is happening on email
spam. 

Dan: David is going to write a document about email spam. Hannes should
write something about XMPP spam. 
David can you write something about the XConnect experience. 

Juergen: We are maintaing an incident list since years. We can write up
a few of them. 
We could put the list into a draft and ask folks to write up the
details. 
Many of the cases are "mixed cases". 

Jan: We need to be careful to scope it too much on the current Spam
attacks. An attacker would change

David: Spam is about economics and it takes some time to change the
economics. 

Dan: Your point is taken. Right now we don't have a lot of input and we
should put them on paper. 
Do folks be willing to look at other communities? David, can you work
with the email folks? Hannes, can you work on XMPP spam? 

Hannes: Yes, I will talk with Peter. 

David: Yes. 

Dan: Spam is a perception issue. Spam for you might not be spam for me. 

Dan Wing: Email has evolved from open relays to DKIM and with SIP we are
still at the early days of email. 
The email community has figured out ways to overcome the problems of
SBCs and to get identity to work. 

David: The fear of SBCs has slowed things down. 

Dan Wing: True. And as a chair of BEHAVE I recognize this in the NAT
area. 

Dan: It would be useful to have a document.  

Hannes, Jan, Dan York, Dan Wing: Discussion about the differences
between DKIM and SIP Identity. 

David: You have been silent, Jiri. 

Jiri: SIP Identity has a too strong identity signature mechanism. 
We do re-write the SDP to deal with NATs but we have a classical SIP
Proxy deployment. 

Dan: Jan, can you write a document about the differences between DKIM
and SIP Identity? 

Jan: Would do it when some folks in this room help me with it. 

Dan Wing: What is the target audience? 

Dan: The folks in the RUCUS group. 

_______________________________________________
Rucus mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rucus

---

From: "David Schwartz" <[email-masked]>
Date: Mon, 17 Nov 2008 19:06:44 -0000

Small correction.

RFC is 5039 not 5149

:)

-----Original Message-----
From: [email-masked] on behalf of Tschofenig, Hannes (NSN - FI/Espoo)
Sent: Mon 11/17/2008 6:59 PM
To: [email-masked]
Subject: [Rucus] Meeting Minutes from F2F at IETF#73
 
Meeting Minutes
===============

Participants:

- Hannes Tschofenig
- Mary Barnes 
- David Schwartz
- Roger Marshall
- Kai Fischer 
- Jan Seedorf
- Keith Drage
- Juergen Quitteck
- Thomas Froment
- Hendrik Scholz
- Jiri Kuthan
- Victor Pascual
- Salvatore Loreto
- Raphael Coeffic

David: Yes. 

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

---

From: Dan York <[email-masked]>
Date: Mon, 17 Nov 2008 13:30:44 -0600

Hannes,

Thanks for taking the minutes.... only one minor detail-  the list of  
participants does not include either Dan Wing or myself.

Unless I imagined it...

Dan

-- 
Dan York, CISSP, Director of Emerging Communication Technology
Office of the CTO    Voxeo Corporation     [email-masked]
Phone: +1-407-455-5859  Skype: danyork  http://www.voxeo.com
Blogs: http://blogs.voxeo.com  http://www.disruptivetelephony.com

Build voice applications based on open standards.
Find out how at http://www.voxeo.com/free

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Mon, 17 Nov 2008 21:36:52 +0200

Sorry. Tiny mistake 

>From: ext Dan York [mailto:[email-masked]] 
>Sent: 17 November, 2008 21:31
>To: Tschofenig, Hannes (NSN - FI/Espoo)
>Cc: [email-masked]
>Subject: Re: [Rucus] Meeting Minutes from F2F at IETF#73
>
>Hannes,
>
>Thanks for taking the minutes.... only one minor detail-  the 
>list of participants does not include either Dan Wing or myself.
>
>Unless I imagined it...
>
>Dan
>
>> Dan: Proposal for forming an EG took longer and requires folks to 
>> write short documents.
>>
>> David: The use cases are so different: IMS, VoIP, SMS We are not 
>> scoping it.
>>
>> Nobody knows what SPIT is going to look like. We would like to get 
>> some feedback messages for the users towards the operator.
>>
>> David: It would be helpful to document about what is happening on 
>> email spam.
>>
>> Dan: David is going to write a document about email spam. Hannes 
>> should write something about XMPP spam.
>> Juergen: We are maintaing an incident list since years. We can write 
>> up a few of them.
>> Dan: Your point is taken. Right now we don't have a lot of input and 
>> we should put them on paper.
>> Dan Wing: Email has evolved from open relays to DKIM and with SIP we 
>> are still at the early days of email.

---

From: Dan York <[email-masked]>
Date: Tue, 25 Nov 2008 17:19:43 -0500

RUCUS list members,

FYI, I've just edited Hannes' minutes to reflect the correct RFC  
number and the presence of Dan Wing and I.  I'm re-sending these to  
the list with the corrections because I want to link to them from  
another upcoming message.

Thanks to everyone who attended,
Dan

Begin forwarded message:

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: November 17, 2008 1:59:22 PM EST
To: <[email-masked]>
Subject: [Rucus] Meeting Minutes from F2F at IETF#73

Meeting Minutes
===============

Participants:

- Hannes Tschofenig
- Mary Barnes
- David Schwartz
- Roger Marshall
- Kai Fischer
- Jan Seedorf
- Keith Drage
- Juergen Quitteck
- Thomas Froment
- Hendrik Scholz
- Jiri Kuthan
- Victor Pascual
- Salvatore Loreto
- Raphael Coeffic
- Dan Wing
- Dan York

Dan: RFC 5039 provided potential solutions. It gives you the overall
problem statement but what are the specific solutions that have to be
put into an architecture.

David: We need to bring the solutions down to earth.
RFC 5039 should be used heavily but it misses the architecture. It
misses the context.

David: Yes.

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 27 Nov 2008 09:03:13 -0500

Huh, sorry I missed the meeting - I hadn't looked in this email folder for a while.
One correction regarding your minutes: I never said the problem is only at the edge.  Quite the opposite, my problem is in the middle.

For most of my customer's, they control the subscribers (the "edge") pretty well.  They can stop any individual UA or PBX from sending more than X SIP INVITEs/MESSAGEs/foo in time period Y, with complete control over X and Y values (and often more settings/knobs than just that).  Basically every popular SBC I know of offers that level of control these days - some in hardware, some just in software.  When I think of SPAM, it seems to me only useful if one can generate lots of it, due to the low success rate.  So if my customers can stop UA's from sending their spam at any rate above normal phone call/SMS rates, I'm not worried about SPAM from them so much.

Botnets/zombies worry me, but for a different reason really - most SBCs have protection mechanisms to protect the core at all costs, including just knocking out mis-behaving UA's by dynamically blacklisting them in hardware ACLs for periods of time.  That was a huge selling feature for my company when we first released it 4 years ago.  We developed a small MS-Windows program that could spoof hundreds of thousands of UA's and flood the SIP proxy with SIP messages of any type at ~100,000 msgs/sec (~500Mbps) from a normal Windows laptop, and we gave the program away to customers for free to prove what zombies could do, or a registration avalanche, or even some script kiddie.  Since similar such attack tools are now available on the Internet, my assumption is operators who use other SBC-type boxes are figuring out how to handle it too.  What concerns me for it though is that the only recourse is to throttle or blacklist the zombies, so a coordinated zombie attack essentially knocks out service for infected users during an attack.  I don't think that's a RUCUS-type problem, and I think it's the only recourse, but it's worrisome for a public communications service.

Anyway... so for me (not everyone), my concern is not about SPAM from subscriber edge.  It's from SPAM through the peering interconnects, from *peers*.  Because at some point in the future, some provider in the interconnected islands of providers will connect NoControlProvider.com into the chain, and all hell could break loose.  Cats and Dogs living together... mass hysteria.  My customers are telling me not to worry about it; that it won't happen, and if it does they'll just cut off that link in the chain until they fix themselves.  But I think they could be wrong.  There are legal implications to shutting off voice traffic, and it takes time.  I'd rather plan for the worst-case.  And the problem is exacerbated by my own product category, ironically.  SBC's anonymize so much of the SIP signaling that there's very little to base identity decisions on by the time you've passed through a provider or two.  So I want to help fix it, by providing the necessary information to help stop it, so long as it doesn't compromise the goals of the "legitimate" providers.  And doing what SBC's currently do is basically not avoidable, because by definition it's what providers wish to do.

And this is only my opinion for my common customer types - I have no stance, opinion, or knowledge of what is important for other SIP deployment types.

-hadriel

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Tschofenig, Hannes (NSN - FI/Espoo)
> Sent: Monday, November 17, 2008 1:59 PM
> To: [email-masked]

---

From: "Charzinski, Joachim (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 27 Nov 2008 15:30:33 +0100

Hi Hadriel,

this is very much in line with the findings of our former 
anti-SPIT activity. The main technical problem is SPIT 
coming in through some peering link, especially if you 
need to accept calls from unreliable IDs. 

Conseqently, the main benefit of an anti-SPIT system is 
not automated blocking (a critical service availability 
issue) but rather OPEX savings through automated incident 
alarming and documentation, so in case of an incident
- you get an alarm with a hint what to block
- you have the necessary documentation filed in case 
  someone complains later 

Best regards

	Joachim.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Hadriel Kaplan
Sent: Thursday, November 27, 2008 3:03 PM
To: Tschofenig, Hannes (NSN - FI/Espoo); [email-masked]
Subject: Re: [Rucus] Meeting Minutes from F2F at IETF#73

Botnets/zombies worry me, but for a different reason really - most SBCs have protection mechanisms to protect the core at all costs, including just knocking out mis-behaving UA's by dynamically blacklisting them in hardware ACLs for periods of time.  That was a huge selling feature for my company when we first released it 4 years ago.  We developed a small MS-Windows program that could spoof hundreds of thousands of UA's and flood the SIP proxy with SIP messages of any type at ~100,000 msgs/sec (~500Mbps) from a normal Windows laptop, and we gave the program away to customers for free to prove what zombies could do, or a registration avalanche, or even some script kiddie.  Since similar such attack tools are now available on the Internet, my assumption is operators who use other SBC-type boxes are figuring out how to handle it too.  What concerns me for it though is that the only recourse is to throttle or blacklist the zombies, so a coordinated zombie attack essentially knoc
 ks out service for infected users during an attack.  I don't think that's a RUCUS-type problem, and I think it's the only recourse, but it's worrisome for a public communications service.

Anyway... so for me (not everyone), my concern is not about SPAM from subscriber edge.  It's from SPAM through the peering interconnects, from *peers*.  Because at some point in the future, some provider in the interconnected islands of providers will connect NoControlProvider.com into the chain, and all hell could break loose.  Cats and Dogs living together... mass hysteria.  My customers are telling me not to worry about it; that it won't happen, and if it does they'll just cut off that link in the chain until they fix themselves.  But I think they could be wrong.  There are legal implications to shutting off voice traffic, and it takes time.  I'd rather plan for the worst-case.  And the problem is exacerbated by my own product category, ironically.  SBC's anonymize so much of the SIP signaling that there's very little to base identity decisions on by the time you've passed through a provider or two.  So I want to help fix it, by providing the necessary information to help 
 stop it, so long as it doesn't compromise the goals of the "legitimate" providers.  And doing what SBC's currently do is basically not avoidable, because by definition it's what providers wish to do.

-hadriel

----------------------------------------------------------
Joachim Charzinski

Nokia Siemens Networks
Research, Technology and Platforms 
Strategy & Vision / End-to-end Network Architecture Evolution
 
St.-Martin-Str. 53
Post box: D-80240 Muenchen
D-81541 Muenchen
Germany
Tel: +49 89 636 79902

[email-masked] 
http://www.nokiasiemensnetworks.com/global/

Think before you print

Nokia Siemens Networks GmbH & Co. KG
Sitz der Gesellschaft: München / Registered office: Munich
Registergericht: München / Commercial registry: Munich, HRA 88537
WEEE-Reg.-Nr.: DE 52984304

Persönlich haftende Gesellschafterin / General Partner: Nokia Siemens Networks Management GmbH
Geschäftsleitung / Board of Directors: Lydia Sommer, Olaf Horsthemke
Vorsitzender des Aufsichtsrats / Chairman of supervisory board: Lauri Kivinen
Sitz der Gesellschaft: München / Registered office: Munich
Registergericht: München / Commercial registry: Munich, HRB 163416
_______________________________________________
Rucus mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rucus

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 27 Nov 2008 10:28:50 -0500

Yes my opinion too - this is more about reaction after the fact than pro-active blocking.  And I figure there's so little information to go on right now, that there's little to go on to generate an alarm, and the ability to track it down is poor.  All kinds of devices create CDR's, but they'll only tell you which peer sent it in, so it takes a long time and multiple NOC personnel of different providers to find out how it got in.  And that's only after someone complains, because it's rather hard to alarm on anything other than unusual call rates or patterns from a given peer (and pattern checks are easily defeatable, IMO).

And if we define a mechanism, no matter what we do it has a deployment problem: providers take years to upgrade and some will never do it, and certainly it doesn't happen all at once.  That's what I liked about Dan's return-routability check or Jiri's Derive drafts: that they didn't need all domains to be upgraded to do them.  But I still think they've got other issues/down-sides.

So I submitted a draft several months ago for a P-Asserter header, which would identify the generating domain of a P-Asserted-Identity header, and sign it.  (see http://tools.ietf.org/html/draft-kaplan-sip-asserter-identity-00)  The purpose of that was to be able to (1) track these things down, (2) pull the more-likely-legitimate requests out of the weeds, and (3) provide data that can be used for verification or reputation, to NOT alarm on.  It doesn't need UA's to do anything - only the peering proxies/SBCs/whatever, so it's got that going for it; but it still requires originating domains to do it, for the mechanism to be of much use, which is its Achilles heel.

-hadriel

> From: Charzinski, Joachim (NSN - DE/Munich)
> [mailto:[email-masked]]
> Sent: Thursday, November 27, 2008 9:31 AM
>
> Hi Hadriel,
>