Subject: [Speermint] Just submitted draft-mahy-speermint-direct-peering-00

From: "Rohan Mahy" <[email-masked]>
Date: Mon, 19 Jun 2006 01:59:40 -0700

Hi Folks,

I just submitted a draft with a minimalist approach to peering.  I
thought this might be a useful way to have a productive discussion on
requirements.

Until it appears in the archive, you can get it here:

http://scm.sipfoundry.org/rep/ietf-drafts/rohan/direct-peering/draft-mahy-speermint-direct-peering-00.html
http://scm.sipfoundry.org/rep/ietf-drafts/rohan/direct-peering/draft-mahy-speermint-direct-peering-00.txt

thanks,
-rohan

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

---

From: Otmar Lendl <[email-masked]>
Date: Mon, 19 Jun 2006 17:11:58 +0200

> thought this might be a useful way to have a productive discussion on

Thanks for the contribution.

It's always helpful to have something concrete to talk about.

Some comments:

> 3.  Overview
> 
>    The approach described here assumes that the initiating peer first
>    discovers a SIP [2] target URI handled by the receiving peer, then
>    sends SIP requests directly to the receiving peer.

Perhaps you should also notice here that such ad-hoc peering implies
settlement-free peering.

>    Note that in a federation of domains, the initiating peer role can be
>    logically decomposed.  Domain A1 can forward requests to domain A2,
>    so that A2 actually opens a TLS connection to the receiving peer.
>    Likewise, the receiving peer function can be similarly decomposed.
>    How functions are distributed between or among domains or nodes is
>    not subject to this specification as long as the requirements
>    described in this document are met.

We have to be careful here to keep the terminology consistent between
the various documents.

I used "peering" for calls within a federation, you seem to use
"peering" only for inter-federation connects. The latter are not
covered by draft-lendl-speermint-federations-00.

A common understanding of this aspect will be important.

> 4.  Procedures

I like this section. It's very helpful for the discussion.

> 4.1.2  User ENUM lookup
> 
>    If an external E.164 address is the target, the initiating peer
>    consults the public "User ENUM" rooted at e164.arpa, according to the
>    procedures described in RFC 3761.  The peer MUST query for the "E2U+
>    sip" enumservice as described in RFC 3674 [11], but MAY check for
>    other enumservices.  The initiating peer MAY consult a cache or
>    alternate representation of the ENUM data rather than actual DNS
>    queries.  Also, the peer MAY skip actual DNS queries if the
>    initiating peer is sure that the target address country code is not
>    represented in e164.arpa.  If a sip: or sips: URI is chosen, the peer
>    skips to Section 4.1.5.

IMHO the URIs as returned by User-ENUM do not require TLS (except when
they are sips: ones) as described in 4.1.6.

They could point to end-user controlled devices (an Asterisk
installation, other VoIP-enabled PBX's or simple SIP services).  I see
no need to insist on anything more than pure RFC3263 for these cases.

> 4.1.6  Setup TLS connection
> 
>    Once a transport, port, and address are found, the initiating peer
>    will open or find a reusable TLS connection to the peer.  The
>    initiating provider MUST verify the server certificate which SHOULD
>    be rooted in a well-known certificate authority.  

That is going to be contentious. What are the "well-known certificate
authorities"? The ones which have their keys installed in MSIE and
Firefox?

Do you expect people to run white-lists based on the keys themselves
or based on special-purpose CAs?

Or blacklists to keep baddies out?

 If you allow the same CAs as used for TLS certs for websites then this
 is a huge community of potential peering partners. Not all of them
 are well-meaning and serious operators.

Do you expect to use CRLs?

What if the destination SIP server hosts multiple domains? Which
cert is he supposed to present to an incoming SIP/TLS connection?

(This is the same problem as hosting multiple https: servers on
a single server. Do you need one IP address per domain?)

>    The initiating
>    provider MUST be prepared to provide a TLS client certificate upon
>    request during the TLS handshake.  The client certificate MUST
>    contain a DNS or URI choice type in the subjectAltName which
>    corresponds to the domain asserted in the host production of the From
>    header URI.  The certificate SHOULD be valid and rooted in a well-
>    known certificate authority.

Same question again as above.

What about TLS connection reuse? If both SIP servers serve URIs
in multiple domains, can they reuse TLS connections which were
established based on calls to a different domain (but hosted
on the same server)?

>    Note that the client certificate MAY contain a list of entries in the
>    subjectAltName, only one of which has to match the domain in the From
>    header URI.

What are the scalability limits to that?

Any moderately sized ISP mail server hosts mails for thousands of
domains. Can this TLS setup scale to similar levels of domain hosting?

> 4.2  Receiving Peer
> 4.2.4  Receive SIP requests

>    The receiving peer MAY reject incoming requests due to local policy.
>    When a request is rejected because the initiating peer is not
>    authorized to peer, the receiving peer SHOULD respond with a 403
>    response with the reason phrase "Unsupported Peer".

You have to distinguish rejects based on TLS negotiations and those on
the SIP layer.

What is the sending peer supposed to do in that case?
Fall back to 4.1.4? Cache that result? If caching: per destination
URI or per SIP proxy? For how long?

How do you prevent unsuccessful TLS establishments to become a kind of
DoS attack? Firewalling could be an option on the destination side,
but dropped packets lead to timeouts on the sender side which lead to
unpredictable call-establishment delays.

--------

As I wrote above: this draft is a good starting point for discussions.

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

---

From: "Rohan Mahy" <[email-masked]>
Date: Mon, 19 Jun 2006 14:01:04 -0700

Hi Otmar,

Thanks for the review.  My comments are inline.

> Perhaps you should also notice here that such ad-hoc peering implies

When the receiving peer is the carrier-of-record, settlement-free
certainly makes a lot of sense.  The approach does not prevent
out-of-band settlement, which still makes sense if the receiving peer
is providing PSTN termination.

> A common understanding of this aspect will be important.

Agreed we should get a consensus on what to call inter-federation and
intra-federation communications.

> no need to insist on anything more than pure RFC3263 for these cases.

good point.  I think this would be a good change.

>  are well-meaning and serious operators.

I think well-known CAs (as used in web-browser for example) are
appropriate for authentication.  The reason I put a SHOULD above is to
allow certs signed by a club, or even self-signed certs if both peers
are OK with that. How the receiving peer decides to authorize the
initiating peer is subject to local policy.  Some peers could use an
explicit whitelist mechanism (similar to traditional telephone network
peering) and other peers could use a blacklist mechanism (similar to
email networks with spam filtering).  Either approach could use rating
and/or accreditation services to assist in the authorization decision
making.

> Do you expect to use CRLs?

I do not expect hosts to perform real-time CRL checks, but CRLs are
still potentially useful input to an authorization decision.

> cert is he supposed to present to an incoming SIP/TLS connection?

If the SIP server hosts multiple effectively equivalent domains (ex:
mozilla.org, mozilla.com, getfirefox.com), it could present a single
certificate with all of the domains in the subjectAltName (which is a
really a list of names).

For ordinary virtual hosting, the receiving peer needs to assign a
separate port for each virtual host, just like we do with HTTPS
virtual hosting, but because of SRV records, we can serve several
hosts on a single IP address.

Eventually we should migrate to using a TLS client extension (it
already exists), so the TLS client can state in the client hello which
domain its trying to contact.  The TLS server then responds with the
appropriate cert.

> established based on calls to a different domain (but hosted

As long as the certificate used to open the connection still covers
the target domain.

> What are the scalability limits to that?

Currently getting a CA to sign the resulting certificate is the hard part. ;-)

> domains. Can this TLS setup scale to similar levels of domain hosting?

If User ENUM does not need to use TLS, we only need to scale to the
number of domains one receiving peer needs to handle for its
carrier(s) of record.

> You have to distinguish rejects based on TLS negotiations and those on

good point.

> URI or per SIP proxy? For how long?

I think the sending peer should continue trying other possibilities
until it can't any more.

I would like a message that conveys:  you are not authorized to peer
with this target domain name, so do not try again unless you have
administrative information suggesting that situation has changed.
This is different from the typical meaning of a 403 which means that
the *request* is forbidden.

> unpredictable call-establishment delays.

there are already a variety of products that manage TLS establishment
DoS attacks for web commerce.

thanks,
-rohan