Subject: [Speermint] Comments on draft-mahy-speermint-direct-peering-02

From: "Elwell, John" <[email-masked]>
Date: Mon, 23 Jul 2007 13:29:40 +0100

Rohan,

I generally like this draft. A few comments.

1. In section 3:
"verifiably assert an identity for the sender of most messages".
Only requests - not responses.

2. In section 4.1.6:
"The initiating
   provider MUST be prepared to provide a TLS client certificate upon
   request during the TLS handshake.  The client certificate MUST
   contain a DNS or URI choice type in the subjectAltName which
   corresponds to the domain asserted in the host production of the From
   header URI."
Although the scope of this document is direct peering, it won't work if
two or more direct peering hops are used in for indirect peering. For
example, suppose enterprise domain exampleA.com submits a request from
[email-masked] to tel:+123456789, and domain A's policy is to route
such a request to service provider exampleB.com. This then determines
that the request is to be routed to sip:[email-masked]. The
exampleC.com domain will receive the request from exampleB.com
(exampleB.com in the TLS certificate of the client) but the From header
field URI will contain exampleA.com.
Also it won't work if Alice has put anonymous.invalid in the From header
field domain.
It should only be necessary to check that the certificate indicates a
domain with which peering is acceptable.

Likewise the following statements later are wrong:
"The Identity-Info header must present a
   domain name which is represented in the certificate presented when
   establishing the TLS connection over which the request is sent."
and
"Next the receiving verifies that the Identity header is
   valid, corresponds to the message, 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."

3. In section 4.1.7:
"The following are not acceptable:

   From: "2125551212" <[email-masked];user=phone>
   From: "Anonymous" <[email-masked]>"

I believe the first is valid (at least between enterprise domains). The
second is certainly valid.

4. "The
   initiating peer SHOULD include an Identity header on in-dialog
   requests as well, if the From header field value matches an identity
   the initiating peer is willing to assert."
There should be a reference to RFC 4916.

John

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