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

[Pekka Savola <pekkas@netcore.fi>]

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.

On Thu, 16 Oct 2003, Chirayu Patel wrote:
> 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. 

Agreed.

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

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.

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

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

> 4. Section 2.1. 1st paragraph
> 
> s/2002:V4ADDR/2002:V4ADDR::\/48/
> 
> Check for the same in the remaining document.

Agreed.

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

OK.

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

Agreed.

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

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" ?)

> 8. Section 2.4.2
> 
> s/Some seem/Some sites seem/
> 
> s/Some also publish/These sites also publish/

OK.
 
> Remove the last sentence of the last paragraph. It does not add anything.
> 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.

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

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

That's OK, and probably better.  I haven't been too satisfied at the way 
section 3 has looked like myself :-)
 
> 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. 

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.
 
> 12. The flow of text for all the threats is not similar. It hampers
> readability, and it is difficult to identify the missing pieces. 

Totally agree on there (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.>

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


> 13. Section 6
> 
> s/number number/number

OK

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

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

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

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

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

In particular, the security checks are difficult when multiple tunneling 
techniques are used, as noted in section 7.1.
 
> 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.
 
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.

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

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.

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

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

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

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

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.

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

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

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.

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

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

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.

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

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

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

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

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.

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

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.

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

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
>      ^^^^^^^^^^^
> Restriction on what?

On the source address to be forged in the encapsulated packet.
                
>    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 this should actually be the ingress filtering, btw. -- typically 
it would be done at the IPv6 layer.
 
> 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. 

Right :-)

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

OK.

> Packet multiplication can be achieved by distributed DOS? Isn?t the same
> 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..
 
>      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. 

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

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

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)?
 
> 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?

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
> factor?

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

Good question.. depends on how you evaluate the tradeoffs :-)
 
> 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.

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

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
> made more generic (for eg. "src==2002" can be changed to "prefix (src)
> matches 2002". 

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