Subject: RE: Comments on draft-dupont-ipv6-rfc3051harmful-05.txt

From: "Christian Huitema" <[email-masked]>
Date: Sun, 1 Aug 2004 15:31:57 -0700

> => I agree but there is still no new work on the RFC3041bis...

The proper place for these considerations is indeed the security
consideration section of RFC3041bis. 

>    But I assume that also would need consensus on the draft..:-)
> 
> => of course (but I did never get objections :-).

For the record, I do not agree with the conclusions of the draft. It is
fairly obvious that there is a tension between privacy and control, but
I believe that when such tensions occur we should aim for more privacy,
not more control.

I also don't believe that we need to restrict address allocation in
order to combat distributed denial of service attacks. There is a
general belief that if we prevent address spoofing, we will have
effectively mitigated DDOS attacks. That belief is just false. I have
closely witnessed the recent DDOS attacks against Microsoft, and the
attackers were "zombies" that did not bother to hide. They were simply
loading the server's home page, again and again. For what I know, the
attacks against SCO and Google followed the same pattern.

That being said, the draft makes a good point: the privacy protections
are mostly effective when the network is large, or when the prefix
changes. The current RFC 3041 is adequate in large networks, but does
not take prefix changes in considerations. If we want better privacy, we
should never use the same privacy suffix on different address prefixes.
This should be clarified in RFC 3041. (By the way, SEND achieves that.)

-- Christian Huitema

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Mon, 2 Aug 2004 00:48:04 +0200

Christian,

> I believe that when such tensions occur we should aim for more privacy,

I am not sure that 'more control' is what I would see as the goal with 
this draft (but I can't speak for the authors obviously)

> attacks against SCO and Google followed the same pattern.

I agree here. The vast majority of DDoS attacks on the Internet today 
are with non-spoofed addresses, however....

> This should be clarified in RFC 3041. (By the way, SEND achieves that.)

....with 3041 addresses, the attacks will look close to forged source 
addresses. This is why I said I think this should go into the security 
consideration section of a RFC3041bis. I don't think that what the 
draft says would invalidate RFC3041. Sites that need 3041 addresses, 
would most likely use them anyway, perhaps with some additional 
mechanisms for looking up previous use in the future. However, the 
drafts does describe considerations that a site that would want to use 
RFC3041 addresses should be aware of, and take into consideration.

So, I think a rewrite of 3041 with this included in the security 
consideration section would be the best way forward.

- - kurtis -

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 4 Aug 2004 17:06:17 -0700

Kurt Erik Lindqvist wrote:
> ...

This draft is just wrong on many counts. Forging is not the cause of the
ddos problem, and turning off 3041 will not do anything to stop it. The
draft discusses the point that uRPF will keep the address in-prefix so
traceability to the wire is preserved. The only reason to forge is to point
blame at someone else known to be on this wire. 

To be clear here, the only difference between forging that this document is
suggesting and normal 3041 operation is running DAD before use. Any bit
pattern in the source address is as valid as any other, so 'forging' is
limited to the case of using someone else's bit pattern. This document tries
to make the case that forging is somehow using a pattern that is outside the
administrator's control. 

The IETF will never resolve the tension between the network administrator
and the system administrator. That is a local CIO function in each
organization. It is reasonable for the security considerations section to
have a balanced discussion of the issues, but biasing recommendations toward
the network admin is not a valid function for the IETF.

Tony

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Thu, 5 Aug 2004 02:35:08 +0200

> the network admin is not a valid function for the IETF.

I was arguing for including the considerations into the security 
considerations, not for recommending to turn it off. So I think we 
agree.

- - kurtis -

---

From: Mohacsi Janos <[email-masked]>
Date: Thu, 5 Aug 2004 09:05:02 +0200 (CEST)

> considerations, not for recommending to turn it off. So I think we

I completly agree with Kurt. I would document why RFC3041 can be 
harmful, let the decision to the local network administrator. - Who is 
ultimately responsible for finding the abusive hosts...

Regards,

Janos Mohacsi
Network Engineer, Research Associate
NIIF/HUNGARNET, HUNGARY
Key 00F9AF98: 8645 1312 D249 471B DBAE  21A2 9F52 0D1F 00F9 AF98

---

From: Brian Haberman <[email-masked]>
Date: Thu, 05 Aug 2004 11:11:28 -0400

> ultimately responsible for finding the abusive hosts...

I would suggest that the issues described in this draft be
included in the Security Considerations section of the 3041
update draft.  That work should be starting shortly.

Regards,
Brian