Subject: [Sipping] draft-ietf-sipping-rtcp-summary-01 (was RE: Few comments on draft-johnston-sipping-rtcp-summary-07.txt)

From: "Srivatsa Srinivasan" <[email-masked]>
Date: Mon, 5 Jun 2006 21:24:04 -0700

I suppose these comments are already too late (I see the document in the queue), if not, the revised Section numbers are below.

-----Original Message-----
From: Srivatsa Srinivasan
Sent: Mon 6/5/2006 7:49 PM
To: [email-masked]
Subject: Few comments on draft-johnston-sipping-rtcp-summary-07.txt
 
In Section 5.6, the ABNF syntax specifies extensibility elements in the syntax to enable UA's to specify metrics not defined within the document. It is inevitable that such a scheme requires Extensions to be understood by the Collector.  In environments with disparate clients implementing rtcp summary,  the Collector will have to somehow distinctly recognize the RTCP submitted by one vendor's UA from another. Text describing how these Extensions be declared and used is missing.

In Section 5.7.1, the example shows a metrics submission PUBLISH request after the BYE is received. As the Collector in F14 isn't really involved with the previous dialog, how would it determine that the dialog ID in the submission is a valid one (and not some made-up dialog ID)? The client being authenticated isn't necessarily a sufficient solution to the problem. The Collector using dialog-event package and other out-of-band options to ensure validity of the dialogs require state to be maintained elsewhere and are complicated solutions to the problem as well.  Text describing the issue (and perhaps a list of possible solutions), in Section 5.9, would be helpful. 

Srivatsa.

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

---

From: "Samir Srivastava" <[email-masked]>
Date: Tue, 6 Jun 2006 12:14:08 -0500

Hi,

  I submitted a draft on Loop Avoidance. URL for this is

http://www.ietf.org/internet-drafts/draft-srivastava-sipping-loop-avoida
nce-00.txt
	
   This document proposes change in registration process of SIP for
   avoiding installation of looped bindings spread across more than one
   proxy.  This version of the document broadly outlines the solution.
   Exact details will be provided in the subsequent versions, as the
   solution progresses.

   Will appreciate comments on this.

Thx
Samir

---

From: "Dale R. Worley" <[email-masked]>
Date: Tue, 06 Jun 2006 16:25:23 -0400

>    Exact details will be provided in the subsequent versions, as the

This might be a useful addition to discover routing loops before they
become operational problems, but it's not a complete solution because of
various additional ways that a malicious user could manipulate the
system.  For example, a user could add a binding which uses a domain-
name as the host part of the Contact URI.  After the registrar accepts
the binding, the user could change the translation of the domain-name.
Or the user could install a serially forked AOR whose first contact is
harmless and whose second contact loops.  As long as the first contact
answers, most SIP probing will not discover that the second contact is
dangerous.

Also, a dangerous loop could be completed by a registration in a proxy
that doesn't implement this mechanism, or by making two simultaneous
registrations to two registrars (and winning the race that the audit of
each registration does not see the other registration).

Since a registration could become part of a loop without the
introduction of any other registration, it might be useful to re-audit a
registration occasionally, rather than only auditing it upon first
registration.

Condition C) at the top of page 4 seems dubious.  In general, it is not
possible to discover if a SIP address goes to a proxy, as any SIP agent
can decide to terminate or proxy each SIP dialog on a case-by-case
basis.  And I'm not sure what the second clause means -- AORs (by
definition) are not the name of a physical device.

You might want to get someone to help you on the exposition in section
3.  There are a lot of different mechanisms described there, and it's
hard to keep track of which one is discussed by each sentence.

There are standard domain names that are guaranteed to not refer to real
organizations, and you should use them instead of "abc".  See RFC 2606.

Dale

---

From: "Samir Srivastava" <[email-masked]>
Date: Thu, 8 Jun 2006 14:51:44 -0500

Hi Dale,

   Thx for your quick detailed comments. See response in line below

Thx
Samir

<< Removed Unrelated Stuff>>

SS>> Domain Name to IP Address mapping is valid for TTL. Generally
proxies cache DNS resolved mappings for TTL. If after TTL expiration
mappings is found to be changed, Loop Detection should be run again. And
NOTIFY after TTL expiration will reject the original binding. If
mappings are not 
cached, then before using it should be audited. Periodic audit with some
time interval ( Configurable Implementation Dependent) will be useful,
if caching is not done. 

SS>> This is the most difficult stuff to fix. After the submission I was
thinking of it too. I will be creating another thread for it.

Also, a dangerous loop could be completed by a registration in a proxy
that doesn't implement this mechanism,

SS>> This is the backward compatbility issue (TBD in the draft). We can
define a option tag to find the support of this extension. Other loop
detection solutions also require update at the other
proxies.

 or by making two simultaneous registrations to two registrars (and
winning the race that the audit of each registration does not see the
other registration).

SS>> Here we can introduce one more level of status of "Not Found". If
Proxy P1 has to go to P2, and P2 doesn't have binding at that time, call
request cannot be completed. It can give in the NOTIFY this intermediate
status. P1 can try to talk to P2 with some random interval. Or When P2
is adding the binding, it can Notify P1. When both proxies hit at the
same point of time, random interval with upper bound will be useful.
This interval cannot be too long as user needs the feedback on the
binding addition quickly. 

SS>> I am okay with periodic audits. I think bindings can be installed
either administratively or by  REGISTER. In both cases, audits needs to
be run as per the proposal. Let me know, if you have any other case.

SS>> Agreed. If [email-masked] maps to [email-masked] (Laptop), Now
[email-masked] is forwarded
     to [email-masked] (Desktop)  Here you have [email-masked] as AOR  for
other registration. I 
meant to refer to IP address by physical device. Binding [email-masked]
-> [email-masked] will require the audit. Binding [email-masked] ->
[email-masked] doesn't require audit, if a.b.c.d  is not a proxy e.g.
outbound extension supported device. Text will be fixed.

You might want to get someone to help you on the exposition in section
3.  There are a lot of different mechanisms described there, and it's
hard to keep track of which one is discussed by each sentence.
SS>> Will put more explainations.

SS>> It will be fixed.

Dale

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

---

From: Scott Lawrence <[email-masked]>
Date: Wed, 14 Jun 2006 18:02:25 -0400

>    Exact details will be provided in the subsequent versions, as the

I don't think that it's actually possible to prevent registrations that
cause loops in the general case, by which I mean when a REGISTER request
is allowed to create a binding to a contact in another domain.  Dale
pointed out some of the ways that this could be accomplished in an
earlier response.  Within a single domain, I suspect that it could be
done or at least made difficult, but I would not try to use SIP to do it
- I'd do it out of band and see no need to standardize it.

More importantly, I suspect that if SIP messages are used to perform the
audit (including but not limited to the methods you propose), then the
audit itself could become the amplification that makes an attack
possible.  If I build a chain of registrations, each one can fork to the
next in the list and to some poor person who is the real target of my
attack.  Each time I add another link to the chain, audit packets (and
any other requests I inject) hit that target from every link in the
chain.
  
-- 
Scott Lawrence  tel:+1-781-938-5306;ext=162 or sip:[email-masked]
  sipXpbx project coordinator - SIPfoundry    http://www.sipfoundry.org/sipX
  Chief Architect             - Pingtel Corp. http://www.pingtel.com/

---

From: "Samir Srivastava" <[email-masked]>
Date: Wed, 14 Jun 2006 19:47:41 -0500

Hi Scott,

Thx for your comments. Pl see responses in-line below.

Thx
Samir

<< removed unrelated stuff>>

Scott Lawrence wrote >> I don't think that it's actually possible to
prevent registrations that cause loops in the general case, by which I
mean when a REGISTER request is allowed to create a binding to a contact
in another domain. Dale pointed out some of the ways that this could be
accomplished in an earlier response.  Within a single domain, I suspect
that it could be done or at least made difficult, but I would not try to
use SIP to do it
- I'd do it out of band and see no need to standardize it.

SS>> Dale's concerns were with DNS, Race condition, Backward
Compatibility and forking. They were addressed in my response. Pl refer
them and let me know your comments.

Could you please specify your _other_ methods for doing it in the same
domain. I cannot understand how to make it difficult. Making difficult
doesn't fix the problem in the deterministic way. 

The draft mentions the text for checking defensively, If loop caused is
within the domains handled by same Registrar/Proxy. It states that
Registrar/Proxy should check for the bindings for the contact mentioned
in the REGISTER, if it is in the domain handled by it.  If you are
adding a binding [email-masked] -> [email-masked] , then Registrar
should search for binding for [email-masked]  and see if they are
causing loop. This check can be performed before returning 200 OK for
REGISTER.

This is SIP contact validity issue, it is better to use SIP methods for
verfication. If the end device or any hop is not SIP reachable, Endpoint
can know about its *reachability rightaway* as per the proposal. And use
another binding at the outcome of this, Otherwise bindings are added in
vacum, specifically when they are spanning across multiple domains. 

I can think of SNMP MIB as an out of band way, where I see a security
issue. Provider of a domain does not want to expose it's MIB to the
provider of other domain, as it will expose the reacability data of
other users, which don't have any binding in another provider's domain.
MIB has  global access and they don't have dynamic provider specific
access rules for the entries in contact table. They are not meant for
this.

Could you please let me know other out of band mechanisms, you are
thinking of.

Scott Lawrence wrote >> More importantly, I suspect that if SIP messages
are used to perform the audit (including but not limited to the methods
you propose), then the audit itself could become the amplification that
makes an attack possible.  If I build a chain of registrations, each one
can fork to the next in the list and to some poor person who is the real
target of my attack.  Each time I add another link to the chain, audit
packets (and any other requests I inject) hit that target from every
link in the chain.

SS>> How can you avoid this in the out of band mechanism ? They will
generate SNMP (or other) traffic instead of SIP traffic. If an evil guy
is attacking this way, then it should be caught by 
IDS / IPS (As complete message trails are available) and it should be
taken out. 

Moreover it can be throttled by REG-Event Notification rates, Rate of No
of Registration Requests resulting in going out to different
registrar/proxies etc. Here It can return 503 with Retry After or we can
add another error code with specific reason.
  
--
Scott Lawrence  tel:+1-781-938-5306;ext=162 or sip:[email-masked]
  sipXpbx project coordinator - SIPfoundry
http://www.sipfoundry.org/sipX
  Chief Architect             - Pingtel Corp. http://www.pingtel.com/

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 26 Jun 2006 12:03:17 -0700

Let me first try and clarify the terminology i have been using to  
separate two different things

1) registration where a UA says send call to AOR [email-masked]  
to this UA

2) forwarding where a device tells a proxy to forward calls to the  
AOR [email-masked] to some other address - perhaps tel: 
+14085551212. Forwarding can be configured many ways -  via a web  
page or perhaps sending what is sometimes called a 3rd party REGISTER  
message.

Problem 1 has an obvious and clear solution to the loop problem.

Problem 2 is harder. However, my personal opinion on 2 is that any  
solution worth doing for this should also work when one of the "hops"  
in the loop is the PSTN as this is a very common case where loops  
happen. It also done see much point in solving it for forwards  
installed via registration vs. forwards installed via a web page. I'm  
sure that Dean will point out that there is also one obvious solution  
to 2.

Cullen

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 29 Jun 2006 21:50:32 +0300

Hi,

note that the current version of the draft is this one:
http://www.ietf.org/internet-drafts/draft-ietf-sipping-rtcp-summary-01.txt

and the draft is not in the RFC Editor's queue yet.

Cheers,

Gonzalo