Comments on draft-ietf-v6ops-6to4-security-00

["Chirayu Patel" <chirayu@chirayu.org>]

Hi Pekka,

draft-ietf-v6ops-6to4-security-00 turned out to be quite thought prvoking
document, and hence I am sending you my comments on the same. At a high
level I think a bit more work needs to go about in the document in terms
of organization, and using the correct technical terms. 

There are still some comments pending on my side, which I will probably
send later, as I still need to develop an understanding about few parts
of the document.

regards,
CP


Editorial comments:
-------------------

1. Abstract

"Spoofing traffic from non-6to4 addresses as if it was coming from a
relay, to a 6to4 relay mode" - This behavior can also be used to perform
a DOS. Are these type of DOS's same as proxy DOS (I have a question about
proxy DOS later on)? If yes, then the Abstract should be rephrases.

2. Section 1. 2nd paragraph

s/malicious parties/malicious IPv6 nodes/

3. Section 1. 3nd paragraph

s/anyone/any IPv4 node outside of the 6to4 site/

You might want to review the usage of "anyone" in the document, and use
specific terminology as applicable.

4. Section 2.1. 1st paragraph

s/2002:V4ADDR/2002:V4ADDR::\/48/

Check for the same in the remaining document.

5. Section 2. 1st paragraph

Rephrase the last sentence to:

Because of this, it is not feasible to limit relays from which 6to4
routers may accept traffic. 

6. Section 2.2. 1st paragraph

s/6to4 address 2002:V4ADDR/6to4 prefix 2002:V4ADDR::\/48/

Make similar change in the figure.

Also instead of 9.0.0.1, you can use V4ADDR in the text, and the figure.
The same comment applies for the figure in section 2.3.

7. Section 2.4.1 2nd paragraph

Rephrase to

If the 6to4 router established a BGP session with few of the 6to4 relays,
the traffic to non-6to4 sites would always go through these relays. An
alternative would be to advertise more specific 6to4 routes between 6to4
relays, and 6to4 routers, as described later (section???, also give
reference to 6to4??) in this document.

8. Section 2.4.2

s/Some seem/Some sites seem/

s/Some also publish/These sites also publish/

Remove the last sentence of the last paragraph. It does not add anything.
Security threats will always be reduced if hosts follow the specs.

9. Section 3. 1st paragraph

Rephrase to

   "This section describes the functionality of the various nodes of a
   6to4 network.

    Note, the functions listed in this section are not exhaustive, and
    are presented to help understand the behavior of the various nodes"

The section can also be renamed to "Functionality of nodes in the 6to4
network"

10. Rename section 3 to "Major functions of 6to4 network nodes"

I would also like if the section was organized into

3. Major functions of 6to4 network nodes
3.1. 6to4 host
3.2. 6to4 router
3.3. 6to4 relay
...
...

Divide each subsection into "Functions", and "Security checks" (this is
essentially the section 3.2, just that it has been worded differently).
"Non-functions" is a non-standard word.

11. I am not able to understand the significance of section 4. It talks
about the special (what is so special?) processing of 6to4. IMHO, this
section can be merged with the previous section. 

12. The flow of text for all the threats is not similar. It hampers
readability, and it is difficult to identify the missing pieces. 

My suggestion is that the text for each threat should be divided amongst
the following headings. (More headings may be headed as required)

------------------------------------------------------------------------

THREAT DESCRIPTION

<Describe the threat>

EXTENSIONS

<In what ways can the attack be extended? If the type of attack is
different for each extension then mention that.>

MESSAGES INVOLVED

<List the messages that are involved in the threat, and
its extensions. For example ND messages, or DATA messages, or specific
DATA messages>

THREAT ANALYSIS AND SOLUTIONS/MITIGATION METHODS

<Analyze the threat for each model. Describe solutions/mitigation methods
if available, and provide a reference for each known solution wherever
possible.>

<Merge section 5.4 with the appropriate threats>

COMPARISON TO SITUATION WITHOUT 6to4

<Compare if the threat can exist in IPv6, and IPv4 networks that do not
implement 6to4.>

------------------------------------------------------------------------


13. Section 6

s/number number/number


Technical comments:
-------------------

1. Section 1.

What is the meaning of the term "proxy denial of service"? I have not
observed the term word "proxy" used along with "denial of service". It
appears from Section 1, that it is the same as distributed reflection
DOS. 
	
2. Section 1.

What is the meaning of traffic laundering? It does not seem to be
standard terminology. Incase it is, can you give a reference?

3. Section 1. 4th Paragraph

Can you elaborate a little about which "quite a few" security
considerations have been difficult to implement? I think the only
security consideration that has been difficult to implement is that "6to4
routers must be configured to accept traffic from relay routers". 6to4
routers do not know of all the relay routers, and hence a susceptible to
attacks.

The paragraph should be rephrased to say - 1) Security considerations in
6to4 specifications are not complete, and some of them have not been
implemented due to their abstract nature, and 2) Additional security
considerations have been discovered after the 6to4 specifications have
been released.

I am guessing that the 2nd point is true based on the "Acknowledgements"
section. My association with 6to4 has been very recent.

4. Section 2.1. 2nd paragraph.

Three comments here:

1. s/It is required/It is mandated/

2. My opinion is to delete all text from the 2nd sentence onwards "If
this is restricted", as it is speculative, and would violate 6to4
specification (section 5.2, and section 5.3)

5. Section 2.4.3 2nd paragraph.

I don't understand the example. What does the following line mean?

   This assumes that all
   outgoing traffic from the main organization (but not between branch
   offices) uses one or more non-6to4 connections.

You have not mentioned the relationship between the main organization,
the branch office, and the native IPv6 internet. Perhaps then the
sentence would be clear.

I also fail to see how it is similar to the "optimization method". 

6. Section 5, 1st paragraph

You mention about the security checks listed in 6to4. Can you summarize
the security checks within this document? If not, can you give specific
references? Are these same as the checks listed in section 3?

You also mention - "Many implementations are known to be problematic at
least in some cases". Can you enumerate the implementations, and the
specific cases? I guess Linux is one of them based on the
Acknowledgements section.

7. Section 5.1.

Do you mean 6to4 hosts as compared to 6to4 nodes?

8. Section 5.2

Remove the 1st paragraph. It is quite confusing. Instead of interpreting
"6to4 routers" as all nodes that have a 6to4 pseudo-interfaces, it would
be better to use the triplet of 6to4 routers, 6to4 hosts, and relay
routers. 

9. Section 5.2.1.

The attacks are not against the 6to4 pseudo-interface. They are against
nodes -- 6to4 routers, 6to4 hosts, and relay routers -- and they employ a
specific method - ND (or are you implying other types of attacks?). Maybe
the section can be renamed to "ND attacks against 6to4 nodes".

In the 3rd paragraph you mention future uses of 6to4. What are the future
uses? I can't locate anything in section 3.1 of 6to4.

10. Section 5.2.1.1.

What is the "situation without 6to4"? Do you mean all forms of *IPv6, and
IPv4* networks that do not employ 6to4? 

In he same section. What is open decapsulation?

I am also a bit confused about this section. Are you trying to list
networks that face a similar threat, and how the threat is handled in
those networks?

11. Section 5.2.2

When you refer to IPv6 nodes, I am assuming that you mean *any* (native
IPv6 node, 6to4 router, 6to4 host, 6to4 relay, native IPv6 router etc)
node on the global IPv6 network. Correct?

What is unidirectional address spoofing? I am a bit ignorant on this
front. The text should mention a concise definition or provide a
reference. 

12. Section 5.2.2.1

I don't understand the first paragraph. See below for questions embedded
within the text.

   The unidirectional spoofing attack exists without 6to4 too, but it
   requires the attacker is able to spoof IPv6 source addresses.  With
   6to4, one is able to launch this attack without any spoofing at all.

How can the attack be launched without spoofing?

   A restriction is that the source address cannot be spoofed to belong
     ^^^^^^^^^^^
Restriction on what?
               
   to the destination site as only non-6to4 addresses can be spoofed
   (assuming correct implementations).  Blindly trusting source address
   of packets coming from the Internet without other precautions is very
   bad practise, though -- and this attack would typically be useful
   only for spoofing destination site -- which is not possible, and can
   be protected against with egress filtering.

Who does the egress filtering, and at what layer - IPv4, IPv6?

I think I have too many questions in this section, and despite rereading
it, I am not able to make much sense. Rephrasing seems to be only
recourse. 

13. Section 5.2.2.1 

I am not in agreement with some of the points made about why the DOS
attack is not critical.

     o 6to4 as an enabling mechanism does not provide any possibility
       for packet multiplication, attacks are generally 1:1,

The word enabling can be removed. 

Packet multiplication can be achieved by distributed DOS? Isn?t the same
property (1:1) exhibited in reflection attacks in the IPv4 internet?

     o victim receives packets as replies from "dst": unless echo
       service (e.g. UDP port 7) is used, the attacker has reasonably
       little control on the content of packets; for example, pure "SYN"
       TCP packets often used for flooding cannot be sent,

If the Reflection attacks are distributed, then they might be severe. 

     o attack packets pass through choke point(s), namely (one or more)
       6to4 relays; in addition to physical limitations, these could
       implement some form 6to4-site-specific traffic limiting, and

Yes. Traffic limiting may be done. But it is not a deterministic property
of 6to4 relays, and if the reflection attacks are distributed, then a
large number of relays will be involved, and traffic limiting might not
work.

     o one has to know a valid destination address (however, this is
       easily guessable or deducible with e.g. an ICMP echo request with
       a limited Hop Count).

This is a moot point. If you are attacking someone you will *have to*
know their address.

The 3rd last para mentions - "The attack can be launched from hosts...".
Which hosts do you mean? IPv4 hosts that can access the 6to4 routers?

Don't understand the 2nd last paragraph. Which point is not a real
factor?

The last sentence says that "This is one of the most serious threats".
Whereas, the section contains many points to argue that the attack is not
critical. Which is it?

15. I have yet to review the document beyond this point thoroughly. I am
getting a bit confused with the text organization, and mainly with the
usage of the terms - hosts, routers, IPv6 nodes, 6to4 routers - and some
of the contents in particular. I will try to send out remaining comments
in another mail.

16. Ok a quick one before I send of this mail. The algorithms also need
some work to make them more readable, and organized. I am still not able
to appreciate the difference between the generic, and simplified
approach, and the language used for depicting the algorithm needs to be
made more generic (for eg. "src==2002" can be changed to "prefix (src)
matches 2002".