[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: SECDIR review of draft-ietf-v6ops-addr-select-req-02.txt
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