[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Comments on draft-ietf-ipdvb-sec-req-06
Thank you for preparing a response to the SECDIR review.
I've now had time to read the new revision and consider the review
comments. I think there are still some areas where the language could be
further improved - especially to clarify the requirements. My comments
follow. Some of these are minor editorial (which I shall forward
separately), some detailed comments may require proposing new text. Most
of these comments stem from the need to clarify the requirements.
I suggest that you quickly prepare a new revision that addresses these
concerns and any others raised by the group, and we can then put the
revised document to a short WGLC before sending to the IESG.
Best wishes,
Gorry
----
Overall comments:
Page 8:
* /Examining the threat cases in section 3.3, /
- This section makes requirements. It looks like a summary, if it is a
summary it probably should not use keywords, since these requirements
have already been defined earlier?
- How best should these paragraphs be best formatted?
---
Page 11:
* I wonder whether the May Requirements for 2,3,4,5 have really been
captured correctly? I can see what you are saying, but at the same time,
I think you would agree that the framework MUST or SHOULD support these
functions, but their use is OPTIONAL, depending on the profile. Can you
think of a better way to express this?
---
Page 13:
* The three cases on page 13 appear also to introduce RFC 2119
requirements. I find this confusing (as did the SECDIR reviewer). I can
see what you are trying to do here (and this seems to be heading towards
two (or more?) profiles, but it does not quite work for me, yet.
----
=======
---
page 8:
/could still have to employ approved
cryptographic equipment at the network layer or above, unless a
manufacturer of ULE Link Security equipment obtains governmental
approval for their implementation./
- True in a way, but I think this could be clearer...
- Is this any better:
/will need to employ approved
cryptographic equipment (e.g. at the network layer). An
implementation of ULE Link Security equipment could also be certified
for use by specific user communities./
---
In section 3.1, page 8:
/ where the two end-points are not under central control /
- Are these IP end-points or ULE end-points (i.e. Encapsulator and
Receiver)?
- I saw this discussion on the mailing list, but the final text seems
to need some re-wording.
---
Page 8:
- I can not recall the history of:
/ In contrast to the above, if a ULE Stream is used to directly
join networks which are considered physically secure, for example
branch offices to a central office, ULE link Security could be
the sole provider of confidentiality and integrity. In this
scenario, governmental users could still have to employ approved
cryptographic equipment at the network layer or above, unless a
manufacturer of ULE Link Security equipment obtains governmental
approval for their implementation./
- /join/ seems the wrong word, could it be "link"
- /which/that/
- I also find this last case rather confusing, could we perhaps simplify
this to:
/When a ULE Stream connects two offices to a central office, ULE link
Security could be the sole provider of confidentiality and integrity. /
- Even in this case, I am not sure why we need to say this. I have some
doubts whether ULE Link-Layer security really satisfies this need, and
would probably prefer to recommend additional higher layer methods.
---
Page 10:
/ Req 1. Data confidentiality MUST be considered in order to/
- Do you need to consider, or provide? (I think the latter)
- I suggest:
/ Req 1. Data confidentiality MUST be provided by a link that supports
ULE Stream Security to/
---
Page 11:
/ Req 5. Layer L2 ULE Source and Receiver authentication MAY /
- this worries me.
- Do you wish to justify this choice?
- I suspect that key authentication is a SHOULD when bidirectional
communication is provided, although at the link layer authentication of
individual packets is not a strong requirement because there is a single
ULE Encapsulator feeding each ULE stream.
---
/ Other general requirements are:/
- I guess you mean by this that these are required for all threat cases
for link-layer security? - Please clarify.
---
/GReq (a) ULE key management functions SHALL be decoupled/
- Agreed can you chnage /SHALL/MUST/
---
/GReq (b,c)/c
- Seems good
---
/GReq (d,e)/
- These properties do not seem to be requirements at the link layer, but
more system-wide requirements. I am not sure what value they have in
this document.
---
/GReq (e)/
- I am not sure how you propose to satisfy this requirement?
- It seems quite general, and something that needs consideration at the
system level, do we need to explicitly call this out in the document?
---
/GReq (f) The security system MUST be compatible
networking functions such as NAT Network Address Translation.../
- Not sure I would agree, and anyway how can this be a MUST for
/TCP acceleration/ when this defines a set of various methods.?
- My suggestion would be to eliminate this requirement and if you really
want to, then make it a comment, rather than a requirement. I'd suggest
that NAT and PEP interactions are problem-spaces in themselves, and it
may be best to discount these from this document.
---
/GReq (h)/
- The use of MAY here is not dictating a requirement, you need to
rephrase this. I am also not sure what this requirement requires, is
this saying we need to do this in some case, or may do something, I am
not sure.
---
Table 1 would be more valuable if it directly follows the above.
- please change /Dos/ to /DoS/ or /DOS/
- There are also some slight formatting problems that I tried to correct:
Please view in a fixed-width font such as Monaco or Courier.
Mitigation of Threat
+-------+-------+-------+-------+-------+------+
|Data | Data |Source |Data |Intru |Iden |
|Privacy| fresh |Authent|Integ |sion |tity |
| | ness |ication|rity |Dete |Prote |
| | | | |ction |ction |
Attack | | | | | | |
+--------------+-------+-------+-------+-------+-------+------+
|Monitoring | X | - | - | - | - | X |
+--------------+-------+-------+-------+-------+-------+------+
|Masquerading | X | - | X | X | - | X |
+--------------+-------+-------+-------+-------+-------+------+
|Replay Attacks| - | X | X | X | X | - |
+--------------+-------+-------+-------+-------+-------+------+
|Dos Attacks | - | X | X | X | X | - |
+--------------+-------+-------+-------+-------+-------+------+
|Modification | - | - | X | X | X | - |
|of Messages | | | | | | |
+--------------+-------+-------+-------+-------+-------+------+
- I also wonder whether this would be improved by linking two the two
profiles - i.e. say which Threats Attacks are considered in each profile.
p Mitigation of Threat
r +-------+-------+-------+-------+-------+------+
o |Data | Data |Source |Data |Intru |Iden |
f |Privacy| fresh |Authent|Integ |sion |tity |
i | | ness |ication|rity |Dete |Prote |
l | | | | |ction |ction |
Attack e | | | | | | |
+--------------+---+-------+-------+-------+-------+-------+------+
|Monitoring | 1 | X | - | - | - | - | X |
+--------------+---+-------+-------+-------+-------+-------+------+
|Masquerading | 1 | X | - | X | X | - | X |
+--------------+---+-------+-------+-------+-------+-------+------+
|Replay Attacks|1,2| - | X | X | X | X | - |
+--------------+---+-------+-------+-------+-------+-------+------+
|Dos Attacks |1,2| - | X | X | X | X | - |
+--------------+---+-------+-------+-------+-------+-------+------+
|Modification |1,2| - | - | X | X | X | - |
|of Messages | | | | | | | |
+--------------+---+-------+-------+-------+-------+-------+------+
Would this work? - or not?
- Are these correct assignments to the two profiles?
- Are there more than 2 profiles?
- Does identity hiding also counter masquerading?
---
section 7:
/optional requirement/
- The SECDIR review commented on this.
- I think the requirement is that framework must support the optional
ability to provide...
---
/This is optional
because of the associated overheads for the extra features and
they are only required for specific service cases./
- need to be clear
/This set of features are optional to reduce encapsulation
overhead when these features are not required./
-End-
--
Dr Gorry Fairhurst, School of Engineering.
The University of Aberdeen is a charity registered in
Scotland No SC013683.