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

From: "Chirayu Patel" <[email-masked]>
Date: Thu, 16 Oct 2003 17:53:16 +0530

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

---

From: Pekka Savola <[email-masked]>
Date: Fri, 17 Oct 2003 16:01:13 +0300 (EEST)

Hi,

(more inline)

*WG chair hat=ON*

First, thanks a lot for the bunch of very good and timely comments.

Second, we asked Chirayu to step in as co-author, to help edit the
document; it is a long and rather complex document.  Thanks a lot for that
as well. It's very nice to see fresh faces in active participation in the
WG. :-)

Pekka, Jonne & Bob

*WG chair hat=OFF*

Now, after the formal rounds, I'll try to comment on the proposed 
modifications so that I'll have easier time syncing up opinions when 
editing the document with my new co-author.. :-)

We can probably continue from here off-list as necessary.

> of organization, and using the correct technical terms. 

Agreed.

> Editorial comments:

This behaviour can be used for both spoofing and DoS.  The definition of 
DoS, proxy DoS, etc. are probably rather inconsistent, and we'll probably 
need to use better terminology here.

> specific terminology as applicable.

Agreed with these.  Good and more consistent terminology would make it 
easier to read the document.

> Check for the same in the remaining document.

Agreed.

> routers may accept traffic. 

OK.

> The same comment applies for the figure in section 2.3.

Agreed.

> reference to 6to4??) in this document.

I'm not sure if I agree here.  This seems to change the point of the 
paragraph, that is, the return path from the non-6to4 sites is a problem 
unless you have a BGP session to all the relays (or some other 
infrastructure) -- sending *to* non-6to4 sites is a simpler issue.

(Also note the use of "few" ?  intentional or "a few" ?)

> s/Some also publish/These sites also publish/

OK.
 
> Security threats will always be reduced if hosts follow the specs.

I'm OK with removal even though I'm I think keeping this in here might not 
hurt.

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

OK.
 
> "Non-functions" is a non-standard word.

That's OK, and probably better.  I haven't been too satisfied at the way 
section 3 has looked like myself :-)
 
> section can be merged with the previous section. 

OK with the merge.

The point of the section is to try to summarize, hopefully briefly, how 
6to4 differs from e.g. native IPv6 use, i.e., what kind of functionalities 
result from the 6to4 implementation depending on which function it serves.
 
> readability, and it is difficult to identify the missing pieces. 

Totally agree on there (difficult to identify the missing pieces)
 
> the following headings. (More headings may be headed as required)

This seems to make sense.  This is probably also close to what Christian 
Huitema was suggesting some months ago, but which I was not sure how to 
proceed with.

The reason why I chose the current model was that I wanted it to be easy 
for folks just using 6to4 as a router, relay etc. to look which threats 
apply to them and exactly how.  With threat-centric approach, this needs 
to be ensured otherwise (but probably makes more sense, as a whole).

> s/number number/number

OK

> Technical comments:

Yep, "proxy" in this case is used more or less interchangeably with 
reflection DoS attacks.. :-(

> standard terminology. Incase it is, can you give a reference?

I'm not sure if this is standard terminology, or whether something else 
would better fit here.  I used it to basically refer to sending traffic 
through some other nodes, to make it seem as if the other would have sent 
it itself -- to make it more difficult to trace the trails.

Perhaps something else would be more appropriate, or at the very least, 
the term needs to be explained better..

> routers do not know of all the relay routers, and hence a susceptible to

In particular, the security checks are difficult when multiple tunneling 
techniques are used, as noted in section 7.1.
 
> section. My association with 6to4 has been very recent.
 
I guess the above characterization is also pretty close to the mark.  The 
6to4 spec does mention some checks, but does not spell them out and 
discuss them properly.  This draft (in particular, section 6), tries to 
spell these out.  Additionally, the draft includes a) a better 
introduction to 6to4 operational modes (sections 2-4), b) threat 
analysis, and c) some other stuff, like thoughts on ways to enhance 6to4 
to better cope with security stuff.

Confusing, eh... :-)  If it seems appropriate, some of these will probably 
need to be killed from the document at some point and/or moved elsewhere.

> specification (section 5.2, and section 5.3)

The reason why the text was in there was because at least one 
implementation had (or has, not sure) a knob to tune that behaviour, and I 
wanted to illustrate why it didn't work.  Maybe this needs rewording, 
moved somewhere else, or whatnot.

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

True.. the text takes a bit of assumptions that's for sure :-).

The line is used to refer to the fact that 6to4, in this case, would only 
be used in the "tunnel-endpoint mesh", not in the regular nodes  at all.  
In this case, 6to4 addresses should never be used as source address 
outside of the site.

As for the optimization method, I agree that it's not really all that 
similar: the reason I used the term is because it's used for optimization 
within the set of border routers (those still have to have non-6to4 
addresses) which use 6to4 as the tunnel-endpoint number technique.
 
> references? Are these same as the checks listed in section 3?

This is a bit confusing aspect here.  Initially the draft set out as to 
elaborate, *expand* and enhance the 6to4 security considerations section.  
It has evolved since.  Thus, the relation what's required by RFC3056 and 
what's included in this draft is not always clear (this draft also 
adds some checks and spells out the encapsulation/decapsulation rules 
more).  Perhaps their differences should be looked at in more detail...

> Acknowledgements section.

Linux is one of them, yes.  It includes no security checks at all.  BSD 
implementations also missed some checks, at least when I checked over a 
year ago.

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

No, I think this issue is more generic than that and encompasses all 6to4 
nodes.

> be better to use the triplet of 6to4 routers, 6to4 hosts, and relay

Yeah, it's confusing, but 6to4 is a bit like that at times.  Note that
6to4 hosts don't necessarily have to have a 6to4 pseudo-interface.  By
"6to4 host", I mean e.g. a node that has autoconfigured a 6to4 address
from a RA from a 6to4 router -- it is sometimes also used to refer to an 
IPv6 host which implements the 6to4 pseudointerface and uses it (but is 
not a router).  

The RFC3056 terminology is also confusing on this one, as there is no
explicit definion for an IPv6 host which has the pseudo-interface.

> the section can be renamed to "ND attacks against 6to4 nodes".

Correct, but these attacks come in through the pseudo-interface, and thus 
the wording.  I'm fine with either way as long as this is clear.  Note 
that the security properties of "open to everyone" 6to4 pseudointerface 
and your regular physical link are likely to be quite different.
 
> uses? I can't locate anything in section 3.1 of 6to4.

For example, some mechanism to send link-local packets between 6to4 nodes.  
Section 3.1 of RFC3056 lists how the address would be created but can't 
figure out any way how to use it currently -- as it would require some 
kind of odd IPv4 link-layer mapping technique.

A case here could be routing site-local addresses (or some of their 
counterparts) through 6to4 interfaces, with 6to4 used as a tunnel endpoint 
mechanism.  Not sure if relevant..

This text refers to the case if such a future use would be invented (e.g., 
relating to multicast w/ 6to4).  Not sure if it's really relevant here.

> IPv4* networks that do not employ 6to4? 

It's a bit of hand-waving, all right :-).  The originally I thought it 
like "if 6to4 did not exist", but that may not be practical .. :-)
 
> In he same section. What is open decapsulation?

I use the term "open decapsulation" to refer to an issue in most automatic 
tunneling techniques, where the decapsulator of the tunnel packets has 
little or no way to guarantee the tunnel end-point, that is, basically 
"every packet must be decapsulated".  E.g. configured tunneling is not 
"open" in this sense, as the address of the end-point is known before the 
fact, and e.g. packets from other sources can even be firewalled away.  
With open encapsulation, the protocol must be open to the whole world.
 
> networks that face a similar threat, and how the threat is handled in

Yep, that's maybe a bit bad idea..

> node on the global IPv6 network. Correct?

I think I used the term "native IPv6 node", which I used to mean non-6to4 
nodes.  As a matter of fact, the critical thing here should probably be 
the existance of the the 6to4 pseudo-interface.

> front. The text should mention a concise definition or provide a

I don't think this has been coined up, it's a term made up by me (figures 
... :-).

I use it to refer to spoofing the address to be able to inject packets to 
a target network for some, typically non-DoS, gain.  For example, assume 
an UDP port in the target host is configured to allow packets only from 
its on-link neighbor.  Now, assume the service behind that UDP port has a 
security hole which can be exploited using a single (or a couple of 
packets, no extensive interaction required) packet after passing the 
"access-list".  Using "unidirectional address spoofing", the attacker 
could try to spoof the source address to be the on-link neighbor and hope 
to circumvent the access-list ("get better privileges").  The response 
packets, if any, are naturally lost.

> How can the attack be launched without spoofing?

Good catch.  I meant spoofing that the attacker's ISP could catch, because 
the attacker doesn't have to spoof anything at the IPv4 layer, just IPv6 
which is encapsulated.
 
>    A restriction is that the source address cannot be spoofed to belong

On the source address to be forged in the encapsulated packet.
                
> Who does the egress filtering, and at what layer - IPv4, IPv6?

I think this should actually be the ingress filtering, btw. -- typically 
it would be done at the IPv6 layer.
 
> it, I am not able to make much sense. Rephrasing seems to be only

Right :-)

> The word enabling can be removed. 

OK.

> property (1:1) exhibited in reflection attacks in the IPv4 internet?

Yep, that's true.  I was trying to refer that 6to4 is not 
"directed-broadcast" -type DDoS attack, which does provide multiplication.  
Granted, those are pretty scarce..
 
> If the Reflection attacks are distributed, then they might be severe. 

Agreed
 
> large number of relays will be involved, and traffic limiting might not

Agreed, there are problems with this model, and if implemented, it would 
require new specification, implementation etc.  This should have been 
fleshed out a bit at 5.4.3, but is still "TBD." :-)
 
> This is a moot point. If you are attacking someone you will *have to*

You have know about the address of the ultimate target, yes, but you may 
not have to know about the address of the reflector (if just the prefix 
was enough)?
 
> Which hosts do you mean? IPv4 hosts that can access the 6to4 routers?

IPv4 hosts, as the attack is done using the encapsulated 6to4 packets.
 
> Don't understand the 2nd last paragraph. Which point is not a real

This tries to (badly) to phrase that sometimes it is not important to
spoof your source address anyway, if the attacker is not real you but just
a couple of hundred compromized, zombie hosts you don't even know where
they are..
 
> Whereas, the section contains many points to argue that the attack is not

Good question.. depends on how you evaluate the tradeoffs :-)
 
> of the contents in particular. I will try to send out remaining comments

Agreed.
 
> approach, 

The simplified just tries to state what the generic says shorter, with a 
few assumptions -- to be more readable, basically.

> and the language used for depicting the algorithm needs to be

True, I think "src == 2002" should be enough, but as long as the syntax 
stays simple enough, more precise one should be used instead.

Whew.. Thanks for a lot of comments.. I didn't think I would ever be able 
to get to the end of the document :-)

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings