Subject: [stir] Few thoughts on rfc4474bis

From: Anton Tveretin <[email-masked]>
Date: Wed, 02 Mar 2016 13:30:09 +0500

Hello All,
Currently, we consider no distinction between "public" and "private" networks. Public network operator is regulated and licensed.
UNI (i.e. the interface between a public network and its user, which may be a private network) has asymmetric trust, it is expected that the user trusts the network, but the network doesn't trust its user. (Think not of malicious clients but misconfigured equipment which might put the entire network at risk.)
As far as I understand, the public network MUST NOT reject a call just because its source is unidentified. This is inconsistent with current I-D (verifier MUST reject some calls). I suggest some rewording...as
According to local policy and regulations, the verifier either: rejects the call (in public networks, this is allowed only when explicitly requested by user), or marks the call by removing Identity header and adding a Warning header (default for public networks), or does nothing.
Regards,
Anton.

---

From: "Peterson, Jon" <[email-masked]>
Date: Wed, 2 Mar 2016 17:09:12 +0000

I don't think I agree with your reading here, in a number ways.

The fact that there is a trust relationship between the user and their
communication services provider is built into SIP, and into RFC4474bis. It
is why the authentication and verification services can be implemented as
network services by CSPs, and thus the providers themselves in those
architectures choose to deploy private, or preferably cryptographically
secured, connections to user agents or to deploy public, unsecured ones.
There's no need to formally distinguish those environments in RFC4474bis;
this is just a protocol design, it's not prescribing any network
architecture.

The question of whether a "public network" is required to not reject
unidentified calls sounds like some regulatory or policy question that
STIR won't take sides on. RFC4474bis says explicitly those questions are
matters of policy: see the last paragraph of 4.2, "this specification does
not propose any authorization policy... to follow based on the presence of
a valid Identity header, the presence of an invalid Identity header, or
the absence of an Identity header". There is no need to reword that
language to differentiate public or private networks, or to say that calls
be blocked if user preferences allow it. It is definitely true that
different providers might implement different policies, and that some
might take user preferences into account, but that is not in the scope of
RFC4474bis, and nothing about the protocol design will change in
environments where providers adopt those policies.

Npw, the current I-D does say that implementations of the verifier role
MUST reject SIP requests under limited circumstances, but explicitly not
because the source is unidentified. it's in cases where, for example,
there is a signature but the signature is malformed, due to an protocol
error or tampering. SIP user agent reject all kinds of requests in cases
where there are protocol error: if there was a malformed Contact header,
say, a user agent implementation might reject that too, regardless of
whether its source was identified or not. "Reject" here also doesn't mean
"block," it is a protocol-level error that is potentially a recoverable
error; a case where the user agent can resubmit a request if it can be
repaired. Call blocking is a policy decision; this is just basic protocol
operation. 

Jon Peterson
Neustar, Inc.

On 3/2/16, 12:30 AM, "stir on behalf of Anton Tveretin"
<[email-masked] on behalf of [email-masked]> wrote:

>Hello All,
>Currently, we consider no distinction between "public" and "private"
>networks. Public network operator is regulated and licensed.
>UNI (i.e. the interface between a public network and its user, which may
>be a private network) has asymmetric trust, it is expected that the user
>trusts the network, but the network doesn't trust its user. (Think not of
>malicious clients but misconfigured equipment which might put the entire
>network at risk.)
>As far as I understand, the public network MUST NOT reject a call just
>because its source is unidentified. This is inconsistent with current I-D
>(verifier MUST reject some calls). I suggest some rewording...as
>According to local policy and regulations, the verifier either: rejects
>the call (in public networks, this is allowed only when explicitly
>requested by user), or marks the call by removing Identity header and
>adding a Warning header (default for public networks), or does nothing.
>Regards,
>Anton.
>
>_______________________________________________
>stir mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/stir