Subject: [Speermint] domain-policy-ddds-00: federations

From: Otmar Lendl <[email-masked]>
Date: Wed, 22 Mar 2006 18:37:53 +0100

[This is the second followup to monday's WG discussion on this draft.]

Regarding the definition of "federation":

The definition in draft-lendl-speermint-federations-00 has a simple focus:
Call routing. A shared federation membership means I can reach the other
VSP though that federation.

This is just like IP networking 101 where we have the fact that
two hosts in the same subnet can talk to each other directly.
There the L3 routing logic contains the simple step:

  * Do I have an interface with an IP-address that lies in the same
    subnet as the destination adress? If yes, use rules of the L2 
    infrastructure of that interface to transport the packet.

My federation definition does the same for SIP:

  * Am I a member of any federation where the destination is also
    a member? If yes, do whatever that federation proscribes to
    route the call.

--

As I read draft-ietf-sipping-trait-authz-02 (btw, are there any other
documents on TRAITS? I haven't found any.), the proposal there is to

* embed cryptographic tokens into SIP messages which assert some
  attribute of the sender. E.g. "I'm a valid user of provider XXX", 
  "I'm a student of XXX", "I can settle bills using YYY".

* Members of a TRAITS federation honor each other's assertions. 

As I see it, TRAITS is a framework on how to communicate attributes and 
it will defined a concrete set of protocols how to authenticate 
message to build trust relationships. It's a "how to do something" idea.

My federation definition doesn't care how federations authenticate
members and how the trust is established. It's a "Can I use it to do X"-
kind of definition. For all I care it can be a bunch of access lists on the
firewall of the participating VSPs.

A TRAITs federation can be used to implement a federation as defined in
draft-lendl-speermint-federations-00. e.g. "all calls with the TRAIT
"valid-user" signed by any member of this federation will be accepted
over the public Internet by all other members of the federation."

Not all TRAIT-federations are federations as defined in my draft.
Just because members recognize each other's trait tags, this does
not necessarily mean that they will accept calls from each other.

On the other hand, using TRAITs is just one way of implementing
a federation for sip peering. You can do that using a walled
garden or TLS certs and without touching SIP headers.

Further remarks: 

* The set of all open SIP servers on the public Internet 
  fulfills the definition of a federation as well.

* So does the set of two VSPs which have a private peering relationship.

* I'm very much open to an alternative name for my federation concept.
  If that's what it takes to reduce the confusion, bring it on.

Comments?

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

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