Last Call Review of draft-ietf-speermint-voip-consolidated-usecases-
review-ietf-speermint-voip-consolidated-usecases-secdir-lc-murphy-2009-10-08-00

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 


aspects.




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?





--Sandy