Subject: Re: [secdir] Review of draft-ietf-sip-media-security-requirements-07.txt

From: "Fries, Steffen" <[email-masked]>
Date: Fri, 9 Jan 2009 08:50:50 +0100

Hi Tero,

sorry for the long delay in replying to your last comments.  

> -----Original Message-----
> From: Tero Kivinen [mailto:[email-masked]] 
> Sent: Monday, November 10, 2008 4:56 PM
> To: Fries, Steffen
> Cc: Dean Willis; 
> [email-masked]; 
> [email-masked]; [email-masked]; [email-masked]
> Subject: RE: Review of 
> draft-ietf-sip-media-security-requirements-07.txt
> 
> Fries, Steffen writes:
> > > The biggest problem I had when I was reading the 
> document, was that 
> > > section 3, suddenly starts listing different requirements like 
> > > R-PASS-MEDIA, R-PASS-SIG etc, and there is no indication 
> where those 
> > > are described. I tried to look for them in the table of contents, 
> > > but couldn't find them listed there.
> > [stf] I added a sentence at the beginning of section 4, which start 
> > using the requirement abbreviations.
> > 	Throughout the subsections requirements are stated by using the
> > 	nomenclature R- to state an explicit requirement. All 
> of the stated
> > 	requirements are explanied in detail in section 5. The 
> requirements
> > 	in section 5 are listed according their association to the key 
> > 	management protocol, to attack scenarios, and requirements 	
> > 	which can be met inside the key management protocol or 
> outside of the
> > 	key management protocol.
> 
> As section 3 already refers to those R-* requirements, I 
> think it would be better to move the paragarph to section 2. 
> Terminology or at least also in the beginning of section 3. 
> 
[stf] done, it is now part of section 2
> 
> > > Reading forward I finally found those in the section 5, 
> but as they 
> > > are not as separate sections there, they were not listed in the 
> > > table of contents. It would be better to move each of those 
> > > requirement to separate subsection, i.e. make
> > > "5.1.1 R-FORK-RETARGET" and so on, so those references 
> earlier could 
> > > point to section 5.1.1 and those would also be listed in 
> the table 
> > > of contents.
> > [stf] I think it is sufficient to include the above 
> sentence instead 
> > of numbering the requirements in sections.
> 
> It would be nice to be able to find the requirements from the 
> document by simply looking at the table contents. 
> Requirements section is now 5 pages long, so bit more 
> specific pointers would be useful in the table of contents. 
> 
[stf] we were discussing putting the requirements into separate section,
but at the end, we decided to leave the requirements clustered as this
better matches the application to use cases and scenarios. 

> > > There is also unexpanded acronym of UAC in section 4.2, 
> and I do not 
> > > what it means and it is not expanded or described in any 
> way. There 
> > > seemed to be also quite a lot of other acronyms, so it would be 
> > > useful to check out if those are really described (or expanded) 
> > > somewhere in the document.
> > [stf] I included the following statement at the beginning of the 
> > terminology section:
> >       Furthermore, the terminology described in SIP 
> >       (<xref target="RFC3261"></xref>) regarding functions and 
> > components
> >       are used throughout the document
> 
> Unfortunately at least I didn't want to read 269 pages to 
> just get all the terminology about SIP when reading this 
> document. I would still suggest replacing it with "User agent 
> client (UAC)" in that one place where it is used in this document. 
[stf] done, I misunderstood your comment in the first place. Sorry for
that.

> > > The description of R-RTP-VALID seems bit odd. It says 
> that "...key 
> > > negotiation packets MUST NOT pass the RTP validity 
> check...". That 
> > > seems bit odd considering that the name is R-RTP-VALID 
> and it says 
> > > MUST NOT pass validity check. Is that description really correct?
> > [stf] I did nothing here, as the stated requirements is correct.
> Why is there requirement that key negotiation packets MUST 
> fail the validity check? Or is this trying to say that they 
> are not processed at all by the validity check operations, 
> i.e. they bypass them. This requirement sound really wierd, 
> and I do not really have any idea why it is here and what it 
> is trying to say, but as I do not know that much about SIP, 
> it might be that I just do not understand something. 
[stf] we changed the requirement name to R-RTP-CHECK to not let it sound
like a negative requirement to be met.
> 
> > > Section A.4.3. SSRC and ROC has typo in word binding: 
> > > "Another, used by Security Descriptions, is to use "late 
> bindng" -- 
> > > ...
> > [stf] changed to
> > 	Another, used by Security Descriptions, is to apply "late 
> > 	bindng ...
> 
> But it is still saying "late bindng" there, and "late 
> binding" in other places. I would guess the "bindng" should 
> be "binding" here too. 
[stf] hoops, missed that one. Changed to "binding"

We will submit an updated version soon. 

Steffen
> --
> [email-masked]
_______________________________________________
secdir mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/secdir