Subject: RE: [Speermint] new version of draft-ietf-speermint-requirements

From: "Jean-Francois Mule" <[email-masked]>
Date: Mon, 3 Dec 2007 04:20:25 -0700

Otmar,

  Thx for the comments. More inline.

Jean-Francois.

> -----Original Message-----
> From: Otmar Lendl [mailto:[email-masked]] On Behalf Of Otmar Lendl
> Sent: Tuesday, November 20, 2007 10:31 AM
> To: Jean-Francois Mule
> Cc: [email-masked]
> Subject: Re: [Speermint] new version of draft-ietf-speermint-
> requirements
> 
[snip]

> The document is much clearer and more consistent this way (e.g. in -02
> the IM sections already listed requirements on protocol features
> whereas the rest of the document described considerations for SSPs).

Ok, credits to A. Houri, E. Aoki and S. Parameswar on this one as noted
in the ID.

> As with the terminology draft, I'm a bit worried whether we're really
> clear and consistent regarding the term "indirect peering". As I read
> this paragraph, in the case of the scenario SSP-O -- SSP-transit --
> SSP-T
> this language suggests that "SSP-O" and "SSP-T" are doing "indirect
> peering" with each other. Daryl's mails seem to indicate that he
> intended that term to be used for the relationship "SSP-O -- SSP-
> transit"
> and "SSP-transit -- SSP-T".
> 
> In other words, is this an example of two indirect peering
> relationships
> or is this just one indirect peering involving three SSPs?
> 
> (I don't particularily care one way or the other, I just strive
> for consistency.)

Based on the updated terminology-ID, this will be fixed in draft-04.

> >3.3.  Session Establishment Data (SED)
> >
> >   The Session Establishment Data (SED) is defined as the data used
> to
> >   route a call or SIP session to the called domain's ingress point
> >   ([I-D.ietf-speermint-terminology]).  Given that SED is the set of
> >   parameters that the Session Managers and outgoing SBEs need to
> >   complete the session establishment, some information is shared
> >   between SSPs.  The following paragraphs capture some general
> >   requirements on the SED data.
> 
> I like the "SIP Route" you mentioned in Req.#5, and perhaps you
> should reference it here again, as the next SIP hop information
> and the request URI to use are the central components of the SED.

I would prefer we keep using SED as the SIP Route is just a sub-set of
SED.

> >3.3.2.  URI Reachability
> >
> >   Based on a well-known URI type (for e.g. sip, pres, or im URIs),
> it
> >   must be possible to determine whether the SSP domain servicing the
> >   URI allows for session peering, and if it does, it should be
> possible
> >   to locate and retrieve the domain's policy and SBE entities.
> 
> Shouldn't that be "allows direct session peering ..."?
> 
> Plus a second sentence like "if the SSP domain servicing the URI can
> be reached via an indirect peering involving a transit SSP, the
> identity
> and the ingress elements of this tranit SSP need to be learned".
> 
> >   For example, an originating service provider must be able to
> >   determine whether a SIP URI is open for direct interconnection
> >   without requiring an SBE to initiate a SIP request.
> 
> Hm? How can there be a direct interconnection without a SIP request?
  That belongs to the solution space, may be it can be done, may be not
but it is a desirable requirement.

> Shouldn't that be "without requiring a pre-established SIP
> connection"?

I'm not sure what you mean by SIP connection?  SIP
request/dialog/session?

> >4.5.2.  Signaling Security and TLS Considerations
> >
> >      5.  SIP and SBE servers involved in the session establishment
> over
> >      TLS must verify and validate the client certificates: the
> client
> >      certificate must contain a DNS or URI choice type in the
> >      subjectAltName which corresponds to the domain asserted in the
> >      host portion of the URI contained in the From header.  It is
> also
> >      recommended that VSPs/ASPs convey the domain identity in the
> >      certificates using both a canonical name of the SIP server(s)
> and
> >      the SIP URI for the domain as described in section 4 of
> >      [I-D.gurbani-sip-domain-certs].
> 
> I'm not up-to-date familiar with the SIP / TLS standards, I just want
> to make sure that customer-owned domains in SIP URIs do not cause
> troubles here.

Any txt to be added?

> This draft is a huge step forward for speermint.

It still very much is a work in progress.

Jean-Francois.

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

---

From: Otmar Lendl <[email-masked]>
Date: Tue, 4 Dec 2007 16:32:39 +0100

> I would prefer we keep using SED as the SIP Route is just a sub-set of

Fine with me.

> but it is a desirable requirement.

Forget about my comment, I misread that sentence in the draft. Your text
is fine.

> > to make sure that customer-owned domains in SIP URIs do not cause

Rereading this section, I'm not sure whether we're not once again
mixing requirements for speermint with requirements / BCP for
providers. Moving this detailed TLS discussion to the architecture
draft might be a good idea.

For the requirements draft, I think we need something much more basic
along the lines of

Requirement #X: The SIP signalling between peering partners needs to
be secured, this includes
	* Mutual Authentication (e.g. through TLS certs)
	* Confidentiality
	* Integrity

Requirement #X+1: The authentication scheme needs to cope with 
SSPs that run the SIP service for thousands of customer-owned domains.

(In other words, it's not feasible that the TLS of the SBE contains
all the domains its customers use.)

Requirement #X+2: The authentication scheme needs to cope with
transit, i.e. that one of the parties owns neither the domain
in the From:, nor in the To: header.

Requirement #X+3. The selection of a transit SSP must be secure.

/ol
-- 
// Otmar Lendl <[email-masked]>, T: +43 1 5056416 - 33, F: - 933
// nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H
// http://www.nic.at/  LG Salzburg, FN 172568b, Sitz: Salzburg

---

From: "Saverio Niccolini" <[email-masked]>
Date: Tue, 4 Dec 2007 16:41:58 +0100

Dear Otmar and all,  

> Rereading this section, I'm not sure whether we're not once 
> again mixing requirements for speermint with requirements / 
> BCP for providers. Moving this detailed TLS discussion to the 
> architecture draft might be a good idea.

I think we need to define the bounds and decide what goes into
Reqirements/Architecture/BCPs

Yesterday we discussed that BCPs for security (you are now talking
about security requirements) should go into a separate BCP draft
while all the requirements that can references as standard work
should go into the requirements

Now it seems you are suggesting to detail some BCPs in the architecture 
draft. Should not the architecture draft describe architecture and
(maybe) some examples, but not turn to be a BCP-type of document?

I would like to have a clarification on this and opinions from the
group.

Cheers,
Saverio

> 
> For the requirements draft, I think we need something much 
> more basic along the lines of
> 
> Requirement #X: The SIP signalling between peering partners 
> needs to be secured, this includes
> Requirement #X+1: The authentication scheme needs to cope 
> with SSPs that run the SIP service for thousands of 
> customer-owned domains.
> 
> (In other words, it's not feasible that the TLS of the SBE 
> contains all the domains its customers use.)
> 
> Requirement #X+2: The authentication scheme needs to cope 
> with transit, i.e. that one of the parties owns neither the 
> domain in the From:, nor in the To: header.
> 
> // Otmar Lendl <[email-masked]>, T: +43 1 5056416 - 33, F: - 
> 933 // nic.at Internet Verwaltungs- und Betriebsgesellschaft 
> m.b.H // http://www.nic.at/  LG Salzburg, FN 172568b, Sitz: Salzburg
> 

============================================================
Dr. Saverio Niccolini
Senior Researcher
NEC Laboratories Europe, Network Research Division	
Kurfuerstenanlage 36, D-69115 Heidelberg
Tel.     +49 (0)6221 4342-118
Fax:     +49 (0)6221 4342-155
e-mail:  [email-masked] <-- !!! NEW ADDRESS !!!
============================================================
NEC Europe Limited Registered Office: NEC House, 1 Victoria
Road, London W3 6BL Registered in England 2832014