[Speermint] Summary: domain policy drafts
Otmar Lendl <lendl@nic.at> Wed, 18 October 2006 16:51 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaEdF-0005UZ-Ko; Wed, 18 Oct 2006 12:51:05 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaEdE-0005UU-VR for speermint@ietf.org; Wed, 18 Oct 2006 12:51:04 -0400
Received: from arachne.bofh.priv.at ([193.154.150.108] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaEd8-0007Fc-EL for speermint@ietf.org; Wed, 18 Oct 2006 12:51:04 -0400
Received: by mail.bofh.priv.at (Postfix, from userid 1000) id 59C011A35F; Wed, 18 Oct 2006 18:50:48 +0200 (CEST)
Date: Wed, 18 Oct 2006 18:50:48 +0200
From: Otmar Lendl <lendl@nic.at>
To: speermint@ietf.org
Message-ID: <20061018165048.GN19113@nic.at>
Mail-Followup-To: Otmar Lendl <lendl@nic.at>, speermint@ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
User-Agent: Mutt/1.5.6+20040907i
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3971661e40967acfc35f708dd5f33760
Subject: [Speermint] Summary: domain policy drafts
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the speermint working group <speermint.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>, <mailto:speermint-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/speermint>
List-Post: <mailto:speermint@ietf.org>
List-Help: <mailto:speermint-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>, <mailto:speermint-request@ietf.org?subject=subscribe>
Errors-To: speermint-bounces@ietf.org
Jean-Francois asked me to give a quick summary to the list what kind of parameters can be fetched using the mechanisms proposed in draft-lendl-domain-policy-ddds-02 and the companion drafts. The main draft "draft-lendl-domain-policy-ddds-02" describes a framework with which a VSP can use DNS entries in its domain to announce requirements this VSP places on incoming communications. That draft does not specify what such requirements can be. Such individual requirements ("atomic policy rules") are defined in other drafts. The main draft defines the generic DNS algorithm which just explains the processing order and the boolean operations to be performed on these individual rules. Individual rules are denoted as URIs. Generally speaking, two basic types of atomic policy rules are possible: a) Referrals to external, possible offline documents. No automatic parsing possible. Will be configured as "ok, I can do that" by hand. Example: Federation membership These are called "Notifications" in the draft. b) Technical requirements. Automatic realtime parsing is possible. Could be configured e.g. in the default settings of a SIP proxy. These are called "Publication" in the draft. There are two ways of encoding such rechnical requirements in URIs: b1) By value: E.g. as defined in draft-lendl-speermint-technical-policy-00 where standards are indicated in the URI (as their urn:ietf:rfc:...) identifier. b2) By reference: (No draft describes this yet, draft-lendl-domain-policy-ddds-02 contains an example for SAML documents, though.) In that case, the atomic policy URI is in fact an URL which points to a complex requirements specification. Usage: ------ Initially, I expect only the federation announcements (as defined in draft-lendl-speermint-federations-03) to be used. This is of type a) and thus does not list any of the actual parameters used within that federation. What rules federations will come up with for their internal use is irrelevant to the domain policy DDDS algorithm. The DNS just enables the discovery of the list of federation a VSP is member of. Regarding technical policies: draft-lendl-speermint-technical-policy-00 defines how RFCs, I-Ds and other standards can be referenced. I expect the following initial use-cases: * TLS CA-list The URI contains a list of CAs where one of them needs to have signed the TLS key of the calling SIP proxy. (There is no defined URI format for that yet.) * SIP identity The caller needs to provide a signed identity (draft-ietf-sip-identity-06) in INVITEs. This might be combined with the previous one to define a list of accepted CAs for these identities. * P-* header support VSPs which have pstn-like user terminals might require peering partners to use some of the P- headers to support the transmission of a number-based caller-id, cnam information and perhaps privacy settings. * SRTP requirements Some VSP might want to accept only calls providing a secure media transport as well. The policy rule could be the RFC or ID of the key exchange algorithm used. * IPsec parameters Instead of TLS, IPsec parameters (key exchange) could also be one possible requirement. * Peering Event package Peers need to subscribe to the peering event package before INVITES will be accepted from them. * Other authentication schemes There were some proposals out there that peers need to "REGISTER" with peering partners before calls can be completed. ----------- Federation internal ideas: Daryl's list is a good start on what federation internal rules might contain, here are some from the top of my head: * Which IP network to use (VPNs, walled gardens, open internet, ...) * How to locate the ingress point (Static configuration? Private DNS?, ev. prefixes in public DNS?, Federation's location server?) * What credentials to use to authenticate at the peer's SIP proxy * Conventions on caller-ID (e.g. how to transmit numbers) * Codec support * Settlement * Call-rate and bandwidth limits * Security arrangements (tls, srtp, ...) * regulatory stuff (calea, e911, ...) * Contractual issues (liabilities, cancellation terms, ...) * Abuse and fraud handling * Quality assurance, trouble-shooting procedures * Supported media (video, presence, IM?) * Supported features (ring back on busy, DND, ...) * Rules concerning the use of SBCs (Most of these rules are not suitable for automatic discovery and thus will never show up in "technical restriction" domain policy DDDS records.) /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint
- [Speermint] Summary: domain policy drafts Otmar Lendl