Re: WG Last-Call (WGLC) for comments: draft-ietf-ipdvb-sec-req-04.txt

[Gorry Fairhurst <gorry@erg.abdn.ac.uk>]

The current wording in the I-D is:

 " There
   could be other extension headers (either mandatory or optional)
   but these will always be placed after the security extension
   header. However, there is an exception: the timestamp extension
   may be placed before the security extension header [ID-EXT]"

Adapting your wording slightly, I would suggest:

 " There could be other extension headers (either mandatory or
   optional). It is RECOMMENDED that these are placed after the
   security extension header. This permits full protection for all
   headers. It avoids situations where the SNDU has to be discarded
   on processing the security extension header, while preceding headers
   have already have been evaluated. One exception is the Timestamp
   extension which SHOULD precede the security extension header
   [ID-EXT]. "

- Please check, I think the only change is that I suggest the normally 
correct place for the timestamp *is* in front of the security extensio, 
and hence this is a SHOULD, rather than a MAY.

Gorry

Michael Noisternig wrote:
> More more thing... If it is a too strong requirement to fix the position 
> of the security extension header at first place, then it is also too 
> strong to make the timestamp header the only exception to this rule.
>
> Therefore, I think a better wording for section A.1.2 would be
>
> "There could be other extension headers (either mandatory or optional) 
> but it is recommended that these are always placed after the security 
> extension header. This permits full protection for all headers, and 
> avoids situations where the SNDU has to be discarded on processing the 
> security extension header while preceding headers will already have been 
> evaluated. One exception to this is the timestamp extension which may 
> precede the security extension header [ID-EXT]."
>
> Regards,
> Michael
>
> Michael Noisternig wrote:
> > Dear authors,
> >
> > I'll take the last chance and raise my hand once more. There is only 
> > two minor issues I have with the current document.
> >
> > First, I want to repeat what I asked for in a previous mail. There is 
> > missing some additional case/motivation for ULEsec in the threat 
> > analysis section:
> >
> > What you've got is
> > - you want end-to-end security, and you can use it (but-last paragraph 
> > of section 3.1),
> > - you do not need end-to-end security (last paragraph of 3.1).
> >
> > What is missing is
> > - you want end-to-end security, but you CANNOT use it.
> >
> > Therefore I suggest to add the following paragraph at the end of 
> > section 3.1:
> >
> > ULE links may also be used for communications where the two end-points 
> > are not under central control (e.g., when browsing a public web site). 
> > In these cases, it may be impossible to enforce any end-to-end 
> > security mechanisms. Yet, a common objective is that users can rely on 
> > security assumptions as of wired links. ULE security could achieve 
> > this by protecting the vulnerable (in terms of passive attacks) ULE link.
> >
> >
> > Second, I only realized this now, but you are mixing data (traffic) 
> > flow confidentiality with data confidentiality. Data confidentiality 
> > means protecting the payload data, the content, against eavesdropping. 
> > Data (or traffic) _flow_ confidentiality has to do with concealing 
> > addresses, packet lengths, or frequency of communication. So identity 
> > protection is a type of data flow confidentiality, while data 
> > confidentiality will simply do encryption of the payload. There is 
> > several instances of this mix-up:
> >
> > Section 3.3, case 1, should say:
> > In this scenario, measures must be taken to protect the ULE payload 
> > data and the identity of ULE Receivers.
> >
> > Section 4, item 1: Data confidentiality is the major requirement...
> >
> > Section 4, case 1: Data confidentiality MUST be provided...
> >
> >
> > Gorry Fairhurst wrote:
> > > This note starts the WG two week Last-Call for comments for the WG
> > > document named below:
> > >
> > > Security requirements for the Unidirectional Lightweight
> > > Encapsulation (ULE) protocol
> > >
> > > http://www.ietf.org/internet-drafts/draft-ietf-ipdvb-sec-req-04.txt
> > >
> > > This Last-Call will end on midnight GMT, 30th September 2007.
> > >
> > > Members of the IETF ipdvb WG are now asked to read the above draft 
> > > and send any issues, comments, or corrections to this mailing list. 
> > > The WGLC
> > > procedure is the last chance for this working group to modify/correct
> > > this document. This document is intended for publication as an 
> > > INFORMATIONAL RFC.
> > >
> > > Please *DO* forward any comments to the list. The document shepherd for
> > > the process following completion of the WGLC shall be the ipdvb
> > > Chair (Gorry Fairhurst).
> > >
> > > Best wishes,
> > >
> > > Gorry Fairhurst
> > > (ipdvb WG Chair)