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

From: Julien Laganier <[email-masked]>
Date: Fri, 13 Jul 2007 11:38:14 +0200

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

---

From: Ruri Hiromi <[email-masked]>
Date: Mon, 23 Jul 2007 19:45:03 +0900

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.

--------------------
There are some security incidents when combining these requirements  
described in Section 2 into a protocol.  Particulars are listed in  
the below.
	a. keep data confident and having data protected for avoidance of  
Denial Service Attack at node or network caused by unsafe and  
tampered data.
	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.
	c. keep network availability at a estimated level. This is for  
avoidance of Denial of Service Attack for network resources.
	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.
	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.

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.  The network operational spec will be  
considered and described as what and how it works for the network  
security. It is also preferable to refer and use existing technologies.
	A. consideration of use of necessity for digitally-signed or  
cryptographic message
	B. consideration of use of necessity for confidence of data source
	C. consideration of use of necessity for authentication
	D. consideration of use of necessity for validation mechanism for  
both of nodes and messages
	E. consideration of use of necessity for avoidance mechanism of data  
conflict
	F. consideration of use of necessity for appropriate filtering  
method at domain boundaries
	G. consideration of use of necessity for data independence method at  
node or an interface.
	H. consideration of use of necessity for information control  
mechanism at server if a node gets information from outside of its  
network domain.

Here is a list for estimation of the impact to security incidents  
that the requirements in this document may interfere.

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

> Hope that helps. Best regards,

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

---

From: Julien Laganier <[email-masked]>
Date: Tue, 24 Jul 2007 21:45:41 +0200

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

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

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

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