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

From: Gorry Fairhurst <[email-masked]>
Date: Sat, 13 Oct 2007 17:14:17 +0100

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)

---

From: Michael Noisternig <[email-masked]>
Date: Wed, 24 Oct 2007 19:12:38 +0200

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...

---

From: Michael Noisternig <[email-masked]>
Date: Thu, 25 Oct 2007 12:18:21 +0200

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

---

From: Gorry Fairhurst <[email-masked]>
Date: Wed, 31 Oct 2007 07:45:50 +0000

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:
>> I'll take the last chance and raise my hand once more. There is only 
>> two minor issues I have with the current document.
>>
>> Therefore I suggest to add the following paragraph at the end of 
>> section 3.1:
>>
>> 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:
>>
>> In this scenario, measures must be taken to protect the ULE payload 
>> data and the identity of ULE Receivers.
>>
>>> 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