[Ecrit] RE: Review of phonebcp and framework

Thank you for your comments on these documents.  I will be releasing new
versions of both today.  I have resolved all of them except as noted below:

> * One threat that's not addressed is the one introduced by phonebcp's
> recommendations about call termination, namely that if a phone gets a
> call from another AOR in the same domain as the PSAP, then it should
> drop its current call and take the new one.  This policy introduces a
> denial of service attack: An attacker can send an INVITE with a spoofed
> AoR and force emergency callers to disconnect from PSAPs.  How were the
> authors thinking about dealing with this?
The text is now very specific about when you do that.  It only occurs if
have an active emergency call, the session timer is running, you hang up,
and you get a call back from the domain that answered the original call.
That's a very small window from a spoofed domain.
> 
> * References to draft-rosen-iptel-dialstring should be to RFC 4967.
> However, I think tel: URIs are appropriate in this case.
The reference is fixed.  The text now says MUST dial string and SHOULD tel.
Tel is not appropriate in this case; it is neither a global number nor a
local number.  It is in fact a dial string.

> 
>For endpoints with multiple types of network interfaces (such as
>an Ethernet jack and a WiFi connection), serious incompatibilities would
>ensue unless every network
>supported every protocol, or alternatively, every device supported
>every protocol.
The text says every device supports every protocol.  Did you miss that?  The
text is clearer now in any case.  The device supports all, the network
supports at least one.

>instead of dial strings>Use the "tel:" URI scheme here. RFC 3966 allows for
numbers that
>are not globally routable.
But it's not a telephone number, it is a dial string.  We translate it to a
URI.  As above, the text now says tel SHOULD be accepted.

><security considerations>This section is very incomplete, largely because
the relevant
>security mechanisms don't exist - they're being worked now by the GEOPRIV
>working group. Recommend removing for now; replace with a reference to
>draft-barnes-geoprivlo-sec and draft-ietf-ecrit-security-threats.
I did that, but it seems like a cop-out.  I'd like some more comments from
other work group members (and maybe A-Ds, and maybe asking for a security
directorate reviewer) on the ability to do that.  Note the editors note in
the section.

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit