Last Call Review of draft-ietf-speermint-voip-consolidated-usecases-

Request Review of draft-ietf-speermint-voip-consolidated-usecases
Requested rev. no specific revision (document currently at 19)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2009-10-06
Requested 2009-06-25
Authors Yiu Lee, Adam Uzelac
Draft last updated 2009-10-08
Completed reviews Secdir Last Call review of -?? by Sandra Murphy
Assignment Reviewer Sandra Murphy
State Completed
Review review-ietf-speermint-voip-consolidated-usecases-secdir-lc-murphy-2009-10-08
Review completed: 2009-10-08


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 

minor changes).

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
On-demand 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?