Kurt Erik Lindqvist wrote: > ... > > 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.) > > > ....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. >
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 -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
