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

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Mon, 19 Jun 2006 11:44:29 -0400

To add to the discussion.

I think it might be useful that federations as part of their role in
peering to establish certificate authorities.

One aspect of the comments below that we have to keep very distinct is
that of authentication from authorization.  You could potentially know,
because a certificate is valid, exactly who the offending SP is.
Whether you then white list or black list is a separate authorization
issue.  In that case, if they subscribe to get your policy, you send
them to the ingress proxy at:  0.0.0.0  :)

Mike

> -----Original Message-----
> From: Otmar Lendl [mailto:[email-masked]] 
> Sent: Monday, June 19, 2006 11:12 AM
> To: [email-masked]
> Subject: Re: [Speermint] Just submitted 
> draft-mahy-speermint-direct-peering-00
> 
> On 2006/06/19 10:06, Rohan Mahy <[email-masked]> wrote:
> > 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.
> 
> 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 >
> 
> _______________________________________________
> Speermint mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/speermint
> 

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

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 19 Jun 2006 13:45:13 -0400

Does this strike a chord with others?

A federation is DEFINED, at least partially, by a CA handing out certs to
club members useful to restrict calls to members of the club?

I do think many federations will have more restrictive security policies
than simply possession of a valid federation cert, but this idea could be
one of those rare cases where a PKI can work.

Remember: this is TLS.  The NEXT HOP is the one that counts.  So transit
networks would work here.  A transit network offering transit from A to B
would have a cert in A and a cert in B.  Originator X, in federation A, can
check the transit network's A cert, and Y, the terminating network in B, can
check the transit network's B cert.

X -> ( A cloud ) -> Transit -> ( B cloud ) -> Y

It's simple enough.  If peering is by federation, it might work pretty well.

Brian

-----Original Message-----
From: Michael Hammer (mhammer) [mailto:[email-masked]] 
Sent: Monday, June 19, 2006 11:44 AM
To: Otmar Lendl; [email-masked]
Subject: RE: [Speermint] Just submitted

Mike

---

From: Otmar Lendl <[email-masked]>
Date: Mon, 19 Jun 2006 21:09:45 +0200

> Does this strike a chord with others?

http://www.ietf.org/internet-drafts/draft-lendl-speermint-federations-00.txt
3., first example.

> It's simple enough.  If peering is by federation, it might work pretty well.

Yes.

My drafts aimed at getting the simple case within clouds/clubs (which
are called federations in my drafts) nailed down and then build some
sort of transit scheme on top of that. Some proposals on how to do this
transit routing are floating around lunch conversations and private
email and we hope to get some preliminary drafts ready for Montreal.

Please note that TLS is just one scheme of building such clubs
of SIP providers. You can do the same thing with IPsec, Firewalling
or VPN setups.

/ol

---

From: Michael Haberler <[email-masked]>
Date: Tue, 20 Jun 2006 11:55:27 +0200

Brian Rosen schrieb:

...
> one of those rare cases where a PKI can work.
this is why we worked on OpenSer to add support for multiple TLS 
connection, per-connection certificates and enable choice of TLS pipe 
based on the target federation as delivered by the domain policy 
matching method as per Otmar's I-D

for inquisitive minds:
see http://www.openser.org/docs/tls.html for the multiple TLS 
connection/cert support
see http://www.enum.at/index.php?id=dokumente (free signup required) for 
code and documentation on domain policy matching, and infrastructure 
ENUM resolver in OpenSer

-Michael

-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.394 / Virus Database: 268.9.1/369 - Release Date: 19.06.2006