Subject: [Speermint] Comments on draft-ietf-speermint-architecture-05

From: "Elwell, John" <[email-masked]>
Date: Mon, 03 Mar 2008 08:03:39 +0000

1. "Two SSPs can form a Layer 
   5 peering over either the public Internet or private Layer3 
   networks. In addition, two or more providers may form a SIP (Layer 
   5) federation [13] on either the public Internet or private Layer 3 
   networks."
This does not cover the case where one SSP is on the public Internet and
the other is on a private L3 network, or federations that span the
public Internet and one or more private L3 networks. Similarly the
bullets further down do not consider this possibility.
Consequently, the distinction between "Public Peering Function" and
"Private SIP Peering" in figure 1 becomes blurred. Since those terms are
not used in the rest of the document, they should be removed.

2. "Peering point" (2 instances). This is not a defined term.

3. "This document assumes that a call from a UAC end user in the 
   initiating peer's network goes through the following steps to 
   establish a call to a UAS in the receiving peer's network:
....
....
....4. the discovery of the UAS"
I am not quite sure how to interpret this list of steps, but step 4
isn't a step taken by the initiating peer's network - it is taken by the
terminating SSP. Perhaps the list of steps was intended to cover steps
taken by either domain. But then in this case, is order supposed to be
significant? Step 5 "Routing of SIP messages" has to occur (at least
routing as far as the terminating SSP) before discovery of the UAS.

5. "5.1. The Location Function (LF) of an Initiating Provider"
LF is not a defined term in the Terminology draft, and also it doesn't
appear in the reference architecture, figure 1. The contents of 5.1 seem
to cover a mixture of LUF and LRF functions - the two should be split.

6. "When the initiating SSP receives a request to communicate, it 
   analyzes the target state data"
What is meant by "target state data"? Presumably the target URI.

7. "If the target address does not represent a resource inside the 
   initiating SSP's administrative domain or federation of domains, the 
   initiating SSP resolves the call routing data by using the Location 
   Function (LF)."
Even if it represents a resource within the federation, surely similar
look-up has to occur.

8. "If an im: or pres: URI is chosen for based on an "E2U+im" [10] or 
   "E2U+pres" [9] enumserver, the peer follows the procedures for 
   resolving these URIs to URIs for specific protocols such a SIP or 
   XMPP as described in the previous section."
This does not seem relevant to a section on User ENUM Lookup

9. "public external peer"
What is this?

10. "Either peer MAY insist on 
   using a sips: URI which asserts that each hop is TLS-protected"
This does not make sense for either peer. It is not the Originating
peer's choice, it is the UAC's choice. Likewise the Terminating peer has
no choice.

11. "The signaling function perform the routing of SIP messages. The 
   optional termination and re-initiation of calls are performed by the 
   signaling path border element (SBE)."
Is this the defined difference between SF and SBE? From figure 2 it
looks like one is a part of the other. I would be surprised if
termination and re-initiation of calls is what is intended by the
definition of SBE.

12. Section 5.4.1. Most of this is duplicating material in the
sip-domain-certs draft (but less precisely). Reference should be made to
that draft instead (currently in WGLC), certainly for any normative
statements.

13. "When sending some requests, the 
   initiating peer MUST verify and assert the senders identity using 
   the SIP Identity mechanism."
What sort of a normative statement is this. If we have a MUST, we must
be precise as to the circumstances. Say which requests.

14. "The domain name in the URI of the From: header MUST be a domain 
   which was present in the certificate provided when establishing the 
   TLS connection for this request, even if the user part has an 
   anonymous value."
We cannot make such a normative statement. In general the originating
SSP is unable to influence the domain part of the From URI. Of course,
it can't sign it with the Identity header field if it is not its own
domain, but this paragraph does not say it is conditional on it being
signed. In fact I would view it the other way round - if the From URI
domain name is different, the originating SSP cannot sign it.

15. "If the From header contains the user URI parameter 
   with the value of "phone", the user part of the From header URI MUST 
   be a complete and valid tel: URI [9] telephone-subscriber 
   production, and SHOULD be a global-number."
Again, the originating SSP cannot influence the user part of the From
header field URI, although of course it cannot sign it with an Identity
header field if it is not a valid URI for which the UAC has provided
credentials.

16. All example From header fields are wrong - they all lack the URI
scheme (SIP or SIPS).

17. "In addition, new requests MUST contain a valid Identity and 
   Identity-Info header"
This seems to either duplicate or be in conflict with the earlier
statement about "some requests" (to which comment 13 applies).

17. In that same sentence, what is a "new request"? Is it a request
outside the context of an existing dialog? If so, say so.

18. "The initiating peer MAY include any SIP option-tags in Supported, 
   Require, or Proxy-Require headers according to procedures in 
   standards-track SIP extensions."
This seems to assume that the initiating peer is implemented as a SIP
B2BUA, rather than a SIP proxy. A SIP proxy must not manipulate option
tags. Up till now, we have only talked about a signalling function,
without indicating whether it is a B2BUA or proxy, and I think we should
keep it that way. Do we really need to make any statement about option
tags?

19. "Next the receiving 
   verifies that the Identity header is valid, corresponds to the 
   message, and corresponds to the Identity-Info header, and that the 
   domain in the From header corresponds to one of the domains in the 
   TLS client certificate."
We cannot make a statement about matching the domain in the TLS client
certificate. The TLS client certificate will identify the domain of the
peer from which the request was received, but that is not necessarily
the originating domain, e.g., in the indirect peering case, or if a
request has been retargeted.

20. "Additionally, the MF MAY 
   perform media relaying, media security, privacy, and encryption."
We are making a normative statement here ("MAY"), yet it is very
imprecise about what is meant. Obviously a MF will perform media
relaying - that is it's basic function. But "security" and "encryption"
- how does it do this, if the UAs have agreed security end-to-end (e.g.,
using DTLS-SRTP)? And what is meant by provision of "privacy" by a MF?

21. "one peering MF is associated 
   with multiple peering proxies"
What is a peering proxy? Is it something different from an SF?

22. "7. Address space considerations"
Make it clear this is network layer address space.

23. "In all cases, cryptographic-based security should be maintained as 
   an optional requirement between peering providers conditioned on the 
   presence or absence of underlying physical security of peer 
   connections, e.g. within the same secure physical building."
Although not stated with RFC 2119 language, in 5.4.1 it seemed to
mandate TLS:
"Once a transport, port, and address are found, the initiating SSP 
   will open or find a reusable TLS connection to the peer."
In fact, that statement in 5.4.1 is ambiguous, since it talks about
selecting a transport and then using TLS, implying there is no selection
involved. Or is TLS here meant to cover DTLS too?

24. The document uses RFC 2119 language in many places, yet it is
Informational. What is the meaning of RFC 2119 language in this
document? Furthermore, the title of the document is architecture, yet
many of the statements that use RFC 2119 language specify things that go
beyond just architecture.

John	

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

---

From: Paul Erkkila <[email-masked]>
Date: Fri, 07 Mar 2008 10:58:51 -0500

> not used in the rest of the document, they should be removed.

For the 2 SSP case a direct peer is already covered since you can just 
pick which address space you want co consider as the primary right?

Direct:
[SSP-A] <-net1|<voodoo>|net2-> [SSP-B]

So are you thinking of the indirect case?

Indirect:
[SSP-A] <-net1-> [(SSP-N + voodoo)+] <-net2-> [SSP-B]

For federations it looks like we need some wording that deals with 
multiple address space issues within federations. I'm not sure which 
doc(s) that would go into though.

-pee

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 10 Mar 2008 11:52:55 +0000

Paul,

I was thinking of the direct case too, e.g., one user in enterprise
space, one in public space.

John 

> -----Original Message-----
> From: Paul Erkkila [mailto:[email-masked]] 
> Sent: 07 March 2008 15:59
> To: Elwell, John
> Cc: [email-masked]
> Subject: Re: [Speermint] Comments on 
> draft-ietf-speermint-architecture-05
> 
> Elwell, John wrote:

---

From: Reinaldo Penno <[email-masked]>
Date: Mon, 10 Mar 2008 13:15:08 -0700

Hello John,

Thanks for your very detailed review. I went though your comments. Please
see my comments inline...

> not used in the rest of the document, they should be removed.

Irrespective of where two SSPs are located they can either peer over a
private network and/or a public network. Is there are other way?

Instead of adding another bullet I could make the statement generic to cover
all possible permutations.

As far as federation goes, they can peer over both (private and public). But
it still just two possibilities. I can consolidate the drawing to say
"private/public" in the same cloud and just connect everything to it. In the
process I can remove the boxes "Private peering function" and Public peering
function".

Let me know your thoughts.

> 2. "Peering point" (2 instances). This is not a defined term.

Should we define it?

> routing as far as the terminating SSP) before discovery of the UAS.

Let me ask you a kind of SIP philosophical question. Would say that from a
UAC perspective it is always trying to find a UAS? I mean, the fact that it
is talking to the SF of another provider is of no concern to it.

Or would say that a UAC behavior is different because the call is crossing
SSPs? I guess I'm trying to avoid having text that suggests a UAC behavior
is different depending on the style of the call.

Let me know.

> LF is not a defined term in the Terminology draft,

There will also be new terms defined. The terminology draft cannot predict
everything. Maybe a better solution is to just define LF in the beginning of
the draft.

and also it doesn't
> appear in the reference architecture, figure 1.

I can draw a LF box around the two terms. Would that be okay?

The contents of 5.1 seem
> to cover a mixture of LUF and LRF functions - the two should be split.

A few paragraphs above I define LF as being composed of both. But I can
split it.

> What is meant by "target state data"? Presumably the target URI.

Yes, I will fix it.

> Even if it represents a resource within the federation, surely similar

Yes, but I'm assuming that's out of scope of Speermint.

> peer's choice, it is the UAC's choice. Likewise the Terminating peer has

Sure, but the terminating peer has the choice of refusing the call, right?

> termination and re-initiation of calls is what is intended by the

I believe that is one of the main functions of a SBE. That is my
understanding from the terminology and use-cases draft.
> that draft instead (currently in WGLC), certainly for any normative

I will fix 12 to 17.

> be precise as to the circumstances. Say which requests.

I will fix normative statements since this is a informative draft.

> using DTLS-SRTP)? And what is meant by provision of "privacy" by a MF?

Privacy would be associated with media relaying. Of course if the endpoints
agreed to end-to-end security that would not be possible. I'm assuming a
originating SSP cold require media to be sent in clear if media relying is a
pre-condition.

> What is a peering proxy? Is it something different from an SF?

SF is a function, not necessarily a proxy.
 
> Make it clear this is network layer address space.

Okay.
 
> beyond just architecture.

I will fix the normative statements

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 12 Mar 2008 12:03:32 +0000

Reinaldo,

See below.

John 

> From: Reinaldo Penno [mailto:[email-masked]] 
> Sent: 10 March 2008 20:15
> To: Elwell, John; [email-masked]
[JRE] Yes, I don't think it is important to separate them - just
acknowledge that the two exist. So this consolidation would be fine.

> > 2. "Peering point" (2 instances). This is not a defined term.
[JRE] Either define it or avoid using it.

> is different depending on the style of the call.
[JRE] I could accept the proposal from Hadriel on 4th March.

> I can draw a LF box around the two terms. Would that be okay?
[JRE] If we think this would be a useful term for this particular draft,
that would be OK (and include it in the terminology section). But on the
whole I prefer to avoid proliferating new terms if we can avoid it. It
depends how often it is used (I haven't checked), but if it is used only
a few times we could use something like "LUF and LRF" instead.

> A few paragraphs above I define LF as being composed of both. 
[JRE] In the terminology draft we went to great pains to have clear
definitions of the two, clearly separating the two functions. It would
be a shame to mix everything up again in the architecture draft.

> Yes, but I'm assuming that's out of scope of Speermint.
[JRE] I disagree. Even if it is in the same federation, it still
involves peering between one SSP in the federation and another SSP in
the federation.

> > This does not seem relevant to a section on User ENUM Lookup
[JRE] What is your response on this?

> > 9. "public external peer"
[JRE] What is your response on this?

> Sure, but the terminating peer has the choice of refusing the 
[JRE] OK, so it would be better to word it in terms of the Terminating
peer being permitted t reject a SIP URI if it requires a SIPS URI.

> understanding from the terminology and use-cases draft.
[JRE] Why would an SBE terminate and re-initiate calls?

> originating SSP cold require media to be sent in clear if 
[JRE] You can relay encrypted media.

> SF is a function, not necessarily a proxy.
[JRE] So what is a "peering proxy"?