[secdir] a few brief comments on raft-ietf-speermint-voip-consolidated-usecases-14

Sandra Murphy <sandy@sparta.com> Thu, 08 October 2009 17:10 UTC

Date: Thu, 08 Oct 2009 13:12:02 -0400
From: Sandra Murphy <sandy@sparta.com>
To: secdir@ietf.org
Message-ID: <Pine.WNT.4.64.0910081254130.3532@SANDYM-LT.columbia.ads.sparta.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
Cc: adam.uzelac@globalcrossing.com, yiu_lee@cable.comcast.com
Subject: [secdir] a few brief comments on raft-ietf-speermint-voip-consolidated-usecases-14
Precedence: list

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

[secdir] a few brief comments on raft-ietf-speerm… Sandra Murphy