Last Call Review of draft-ietf-speermint-voip-consolidated-usecases-
I am reviewing this document
draft-ietf-speermint-voip-consolidated-usecases-14 as part of the security
directorate's ongoing effort to review all IETF documents being processed
by the IESG. These comments were written primarily for the benefit of the
security area directors. Document editors and WG chairs should treat
these comments just like any other last call comments (that you received
well after last call). Feel free to forward to any appropriate forum.
This document covers use cases for voip to guide development of work in
the speermint wg. As such, it introduces no security concerns. It points
to the threats document for discussion of threats related to peering.
I did have questions, and attempted to contact the authors at the last
IETF, but one author did not attend and the other author and I were not
able to meet (and as I missed the last call they wanted to consider only
The draft discusses five different use cases, some of which have security
The comments below could be covered in the threats document.
Static Direct Peering
Static Direct Peering (with an assisting LUF and LRF )
Static Indirect Peering (with han assisting LUF and LRF)
Static Indirect Peering
The indirect peering cases say that there may be multiple intermediate
SSPs between the originating and terminating SSP. There's no discussion
of the trust environment for that model (though there is a bit of
discussion of the trust involved in outsourcing to an assigting LUF or
LRF in the second case). I found mentions in the terminology draft of
federations, and imagine that these indirect cases would require a
federation model. If that is the case, it should be mentioned here.
The terminology draft talks of indirect peering as a single transit SSP,
not the multiple intermediate SSPs mentioned here. Some of the discussion
of the indirect case here seem to consider only a single transit (so the
origin and termination SSPs would both be directly connected to all
tansits involved), but section 5.4 says there may be multiple. A
federation with a common trust model would work.
The direct peering -assisting LUF/LRF case says the the assisting SSP
might have other customers and would have to be trusted to separate them
all. The common LUF/LRF function uses DNS, which has no mechanism for
providing searation like that. However, I'm told that there are
implementations that do provide that service. I presume it is OK to rely
on an implementation feature and negotiation between the origin and
assisting LUF to require such a feature?