Subject: [Enum] I-D: Publishing SIP Peering Policy

From: Michael Haberler <[email-masked]>
Date: Thu, 29 Dec 2005 16:32:35 +0100

[we've worked out a method to publish SIP peering policy through the 
DNS. It falls into SPEERMINT territory but I think it's relevant for 
ENUM as well.
here's the gist in a nutshell - flames on. -mah]

--

There will be many, potentially incompatible SIP peering schemes, and looking
at a SIP URI does not help in deciding wether it is reachable (or 
"peerable"). Such
information could be managed in local tables at the egress point. 
However, such static
setup information is unwieldy to manage and similar in nature to a 
hosts.txt table, or
static routes, and associated disadvantages.

To aid runtime discovery of "peerable" destinations, and facilitate 
management of
peering arrangements (including auto-discovery of new peering 
partners which subscribe
to the same set of policies), we propose to name the scheme(s) used 
by a provider and
publish them in the DNS, by specialized NAPTR RRs. This enables the 
egress point to
decide - in advance and without pre-configuration of peers - wether 
the ingress
point will accept a SIP INVITE, and which technique should be employed.
Our proposal also allows smooth migration between peering methods and 
helps reduce
the complexity of arrangements by introducing federations, of which a 
bilateral
arrangement is just a special case.

Our proposal focuses on the URI level, and assumes that E.164 numbers 
are already
mapped to a URI, for instance by some form of ENUM.

This draft addresses the problem of managing the peering fabric from 
an end-to-end
perspective, which is a core task of the SPEERMINT charter.

Michael Haberler
Otmar Lendl

On 2005/12/28 16:12, [email-masked] wrote:
 > A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
 >
 >
 > 	Title		: Publishing SIP Peering Policy
 > 	Author(s)	: O. Lendl
 > 	Filename	: draft-lendl-sip-peering-policy-00.txt
 > 	Pages		: 16
 > 	Date		: 2005-12-28
 > 	
 > This documents proposes the use of DNS entries to publish a SIP
 >    proxy's policy for accepting incoming calls.  Such published policies
 >    can be used to selectively establish peering relationships between
 >    VoIP service providers.
 >
 > A URL for this Internet-Draft is:
 > http://www.ietf.org/internet-drafts/draft-lendl-sip-peering-policy-00.txt
 >
 > [...]

_______________________________________________
enum mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/enum

---

From: "Henry Sinnreich" <[email-masked]>
Date: Thu, 29 Dec 2005 16:32:49 -0600

This is seems to be an excellent approach and I suggest we discuss it on the
list and close at the 65 IETF meeting in March.

Are there any issues with overloading the DNS?

Maybe it would be useful to define XML based policy profiles and have them
registered at IANA?

Thanks, Henry

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Michael Haberler
Sent: Thursday, December 29, 2005 9:33 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: [voipeer] I-D: Publishing SIP Peering Policy

--

There will be many, potentially incompatible SIP peering schemes, and
looking

Michael Haberler
Otmar Lendl

directories.
 > http://www.ietf.org/internet-drafts/draft-lendl-sip-peering-policy-00.txt

____________________________________________________________________________
_
List Archive: http://darkwing.uoregon.edu/~llynch/voipeer/
User Tools: http://darkwing.uoregon.edu/~llynch/voipeer.html

---

From: Otmar Lendl <[email-masked]>
Date: Fri, 30 Dec 2005 17:00:39 +0100

> list and close at the 65 IETF meeting in March.

We're looking forward to a lively discussion. There are a lot of
open questions (marked by "FIXME") in the draft where we hope that
input from the list will lead to good solutions.

The actual ressource record format is open for discussion as well.

> Are there any issues with overloading the DNS?

The basic questions which are answered by the scheme proposed in this
draft are very close to those where DNS has traditionally been the
answer. e.g. "I have this URI, what communication parameters do I need
to use it?".

This being the DNS, the answers need to be concise. There is no room for
elaborate policy documents to be sent in the DNS answer.

> Maybe it would be useful to define XML based policy profiles and have them

The draft talks about two distinct types of policies.

a) Federation rules.

   Definition and publication of these rules are out of scope for this draft. 
   I see no need to parse those rules at call-setup time in an automatic
   fashion. Either your own VSP is a member of this federation, in which
   case you already made sure that you agree and follow that policy, or
   you are not, making the question whether you could follow the rules
   of that federation moot.

   A clear definition language for federation rules comes in handy 
   when you consider to join a given federation. My guess here is that
   such rules will have at least twice as much legalese (who is allowed
   to do what, settlement, dispute resolution, abuse handling, ...) than
   actual technical rules (SIP/TLS details, Layer 3 arrangements, ...).

   I expect such rules to be similar to the contracts you have to
   sign when you connect to a layer 3 exchange point. See e.g. 
   https://www.linx.net/www_public/about/corporate_governance/index_html/contentpanels_view?pageIndex=2

b) Technical restrictions.

   These are independent to any federation membership. While I think
   that typical VoIP providers will use federations to peer with each
   other, smaller entities (corporations, educational institutions, ...)
   will want to enable ad-hoc peering. They don't want or need to sign
   contracts with peering partners. But they might want not to run
   a completely open SIP server.

   Consider the email case: These days most SMTP servers already
   implement restrictions like "The sender domain must exist" or 
   "client IP address not listed in blackhole lists". As email is
   not real-time, it does not really hurt to just try to deliver the
   mail and be told "no, sorry, we don't want your mail this way".
   Your MTA will fall back to other MXs or smart-relays. 
   
   With SIP, we're in real-time communications where call-setup 
   times are important. The sender prefers to know about such restrictions
   before connecting to the destination.

   [A similar idea was recently implemented in BGP4 as ORF
   (Outbound Route Filtering) where one BGP speaker tells his
   peer about his filter-rules so that route announcements can
   be tailored on the sender side.]

   For this case, a clear description language for restrictions
   is indeed helpful.

   As the DNS answers cannot hold the full text of such 
   XML descriptions I agree that an IANA registry which maps
   rule descriptions to simple unique identifier is needed.

   [A similar solution was used in the XML DSIG standard regarding
   transformations, see http://www.w3.org/TR/xmldsig-core/#sec-TransformAlg ]

   I'm not 100% sure whether it's possible to design a XML scheme
   which can cover all possible policies. Once again, email
   could act as model. If one can design a scheme which covers
   all the currently employed email restrictions, then the same
   should be possible for SIP.

   Full XML syntax is only needed for automatic processing of
   such restrictions. For most cases I think that SIP senders
   will just compare the announced policy-identifiers with locally
   configured ones. No XML processing will be done at
   call-setup time.

/ol
-- 
< Otmar Lendl ([email-masked]) | nic.at Systems Engineer >