[Speermint] Summary: domain policy drafts

[Otmar Lendl <[e-mail]>]

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 ([e-mail]) | nic.at Systems Engineer >

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