Hi Ruri,
On Monday 23 July 2007, Ruri Hiromi wrote:
Hello,
SECDIR and Shunsuke Suzuki pointed out that we did
not sufficiently describe security influence this
requirement might be brought.
For this issue, I would like to put these words in
the section 3 (security consideration part). Please
check this, all of you. Thanks for advance.
It's good to see that you want to expand the sec-cons
section.
Overall, I think the text is too unclear, or is mixing
different aspects together that will make it hard to
make sure a specific protocol satisfies the security
requirements put forth below. I think the sec-cons
section should have two parts: 1) a list of threats
introduced by new address selection mechanisms (what
an attacker could do), and 2) a list of recommendation
on which security mechanisms (e.g. entity
authentication, message authentication,
confidentiality protection) should be applied to
counter these attacks.
Detailed comments are inlined in your text below:
--------------------
There are some security incidents when combining
these requirements described in Section 2 into a
protocol. Particulars are listed in the below.
I think the above text should clarify what is listed
below. I am confused as to what the list of items
below is. It seems it is mixing threats with
solution/requirements to block the corresponding
attacks. These should be listed separately, IMHO.
a. keep data confident and having data protected
for avoidance of Denial Service Attack at node or
network caused by unsafe and tampered data.
I actually think that confidentiality and integrity
protection should be treated separately since there
are cases in which the data is not confidential and
thus it makes no sense to protect confidentiality.
In that particular case it would be good to spell out
why an address selection protocol exchanges would need
to be confidentiality protected since it is not
obvious (at least to me). I have the impression that,
depending on the protocol and the threat model it
might or might not be needed.
For example, if the protocol is just used to broadcast
the same address selection directives/policies from a
central server to all nodes of the domain, I am not
sure there need to be confidentiality protection.
On the other hand, if the protocol is used to let a
node of the domain query a server about best address
selection outcome to reach a particular destination,
then confidentiality protection could be used to
protects from some attacks, e.g. where an attacker
could collect a list of destinations with which the
node communicates with.
Then, w.r.t. the mentioned "Denial Service Attack", it
should be clarified what the attack actually is, e.g.
what's the asset being attacked, how is it being
attacked, etc.
b. detect a certified information resource(s) and
keep communication with confidential information
resource(s). This is for avoidance of hijacking or
tapping from unsafe node.
When you mean detect, do you mean discovery? If you
mean discovery, then the requirements on a secure
discovery mechanisms should be spelled out -- i.e. is
it simply avoiding a rogue resource to be discovered,
and does it also include protection against an
attacker denying discovery of that resource?
I also have the same concerns than for item a) above,
i.e. certification and confidentiality protection
should be decoupled.
Also as above, it should be clarified how the attack
occurs, i.e. how an address selection protocol could
lead to hijacking or tapping.
c. keep network availability at a estimated level.
This is for avoidance of Denial of Service Attack
for network resources.
Ditto (What's the attack, what's the asset, etc.)
d. keep service availability
in a specific node at an estimated level. This is
for Avoidance of Denial of Service Attack for node/
computer resources.
Ditto.
e. keep an estimated administrative, controlled
level in the whole network. This is for avoidance of
intrusion of security boundary caused by malicious
use of multiprefix environment. This is also for
avoidance of leakage of some information from
central controller.
I don't understand what the first sentence means.
Regarding what's being avoided, same comment as
before, how would the attack be realized, what are the
assets, etc.
All the way listed below should be well-considered
for the protection from security threats. There is
no necessity to comply with all items at same time,
and it will be accepted if one or more spec will
come to apply the other spec.
What does the last sentence mean? Do you mean that it
is possible to have multiple specifications where one
specification defines the main address selection
protocol, and others specifications defines mechanisms
used to protect the main protocol against different
threats?
The network operational spec will be considered and
described as what and how it works for the network
security.
This I'm not sure I understand either...
It is also preferable to refer and use existing
technologies.
Right.
A. consideration of use of necessity
for digitally-signed or cryptographic message
In the above, and what follows (i.e. items A-H)
I'm assuming that "consideration of use of necessity
for" means "considerations on the necessity to use".
Is that right? If yes that should be replaced.
Also, do you mean Message Authentication Code (MAC)
instead of "cryptographic message" ?
B. consideration of use of necessity for confidence
of data source
s/confidence/confidentiality
Also here do you mean confidentiality protection of the
data exchanged? Or of the source? If the latter what
does that mean? You mean the source address?
C. consideration of use of necessity for
authentication
Are you referring to entity authentication (a.k.a
entity identification) or message authentication
(a.k.a message integrity protection) ?
D. consideration of use of necessity for validation
mechanism for both of nodes and messages
What kind of validation mechanism are referring to? Is
that message integrity protection?
E. consideration of use of necessity for avoidance
mechanism of data conflict
I do not understand that. Can you clarify?
F. consideration of use of necessity for
appropriate filtering method at domain boundaries
Ok.
G. consideration of use of necessity for data
independence method at node or an interface.
I do not understand that. Can you clarify?
H. consideration of use of necessity for
information control mechanism at server if a node
gets information from outside of its network domain.
Here I assume you mean access control to the service
providing address selection, is that right?
Here is a list for estimation of the impact to
security incidents that the requirements in this
document may interfere.
I don't really understand what is being listed. I am
not going to comments on what follows. I recommend
rewriting the text as suggested in my overall comment
with 1) list of threats and 2) countermeasures to the
threats.
Hope that helps. Best,
--julien
2-1: Effectiveness will have no impact to security
issues
2-2: Timing will have no impact to security issues
2-3: Dynamic update has a possibility if it is
maliciously used to lead high load average for
network and machine resources. This may become a
Denial of Service attack. Safe protocol should be
used.
2-4: Node-Specific behavior has a possibility to
take attacks to a specific node. Authorization and
validation will protect this.
2-5: Application specific behavior will have no
impact to security issues
2-6: Multiple interfaces has a possibility to take
denial of service to machine resources. It also has
a possibility of becoming a steppingstone beyond
security boundary. It is necessary to have a
filtering mechanism at domain boundary and
independence between interfaces. It is desirable to
have some protection by a protocol or operation.
2-7: Central control mechanism has a possibility to
take session hijack attacks if the central
controller is unsafe and gives invalid information
to nodes. Information should be managed. Protocol
should have a mechanism for validation, confidence,
authentication, authorization.
2-8: Next-hop selection has a possibility to take
denial of service due to a conflict between routing
system and policy table. If a routing system has own
security mechanism, it is necessary to cooperate
with it, not interfere the mechanism.
--------------------
On 2007/07/13, at 18:38, Julien Laganier wrote:
I have reviewed this document 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.
Background: In multi-prefix environments it is
possible for an IPv6 node to have multiple IPv6
addresses available. There is thus a need to
select appropriate source and destination
addresses when initiating communication. RFC3484
defines default address selection for IPv6.
Another v6ops draft
[I-D.ietf-v6ops-addr-select-ps] points to some
situations in which RFC3484 leads to problems,
hence the desire to introduce new selection
mechanisms overcoming those. This document
discusses requirements for such mechanisms.
Security Review: While I think this is useful
work, I am concerned that security wasn't made a
requirement in itself and is instead just touched
upon in the security considerations section. I
also think that the security considerations
section is not appropriate: it doesn't do a good
job of analyzing threats that might be introduced
by address selection mechanisms. It is
insufficient to state that "incorrect address
selection can lead to serious security problems,
such as session hijack", this is too vague.
Security threats should be listed exhaustively. As
I already said, I believe that it should be made a
requirement in itself that these threats are
appropriately countered. Since it also seems that
address selection mechanisms can be realized via
protocols, it might also be good to go into what
are the requirements on protection of these
protocols (e.g. network filtering at the domain
boundary, message authentication, etc.).
Non-security nit: In section 2.5., "address
selection API" could reference a recently approved
individual submission
[I-D.chakrabarti-ipv6-addrselect-api].
Hope that helps. Best regards,
--julien
-------------------------------
Ruri Hiromi
hiromi@inetcore.com