Subject: Re: SECDIR review of draft-ietf-v6ops-addr-select-req-02.txt

From: Ruri Hiromi <[email-masked]>
Date: Tue, 16 Oct 2007 18:29:12 +0900

Hi,

We have updated our document(from -2 to -3.txt) and I copied security  
consideration section in the below with reflection of the comments  
from SECDIR. How about this? We need more modification/clarification?  
Ant comments are appreciated!
Thanks in advance,

----
3.  Security Considerations

3.1.  List of threats introduced by new address-selection mechanism

    There are some security incidents when combining these requirements
    described in Section 2 into a protocol.  In particular, here are six
    possible threats.

    1.  Hijacking or tapping from malicious nodes connecting from beyond
        unapproved network boundaries.
    2.  Malicious changing of policy data by nonapproved nodes.
    3.  Denial of Service Attack due to higher traffic volume, and
        blocked communication, for example, at both node and network
        caused by sending unsafe and tampered data from unbidden
        controller.
    4.  Attempt to stop service on node/computer resources caused by
        unnecessary communication between the controller and nodes.
    5.  Intrusion into security boundary caused by malicious use of
        multiprefix environment.
    6.  Leakage of network policy information from central controller.

3.2.  List of recommendations in which security mechanism should be
       applied

    All the methods listed below should be well-considered for  
protecting
    against security threats.  There is no necessity to comply with all
    items at same time, if one or more spec(s) could apply to other
    security requirements.  Secure network operation will also be
    considered, and describing network operation for network security
    will be better.  Referring to and using existing technologies is  
also
    preferable.

    1.  Consideration of the necessity to use digitally signed or
        cryptographic messages.
    2.  Consideration of the necessity to maintain confidentiality of
        source of policy data.
    3.  Consideration of the necessity of authentication and validation
        of both entity and message integrity.
    4.  Consideration of the necessity of having a mechanism for the
        avoidance of data conflicts if the policy data comes from
        multiple controllers.
    5.  Consideration of the necessity of an appropriate filtering  
method
        at domain boundaries.
    6.  Consideration of the necessity of data independency at every  
node
        or every interface for avoidance of mixing multiple policy data.
    7.  Consideration of the necessity of having a mechanism for
        controlling policy and all related network information on the
        server if the server stores policy and all related neetowrk
        information on the outside of its network domain.
    8.  Consideration of the necessity to log and collect related system
        data.
----

Regards,

On 2007/07/25, at 4:45, Julien Laganier wrote:

> 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
>> [email-masked]
>
>
>

-------------------------------
Ruri Hiromi
[email-masked]