Re: [Fwd: I-D Action: draft-carpenter-6man-why64-00.txt]

[Emmanuel Thierry <[e-mail]>]

Hello,

Thanks for your answer.

Le 10 janv. 2014 à 09:53, Alexandru Petrescu a écrit :

> Hello,
> 
> Thanks for the post.
> 
> I could understand the need to spam block an entire /64 instead (a
> single line in a configuration file) rathern than 2^64 lines each
> telling an address in that file.
> 
> Yes, this is relevant when writing other firewalling rules as well.
> 
> In this sense it is good to have an 'overall' number - like a /64 - to
> designate one particular link and subnet.
> 
> And one may like to use other such overall numbers such as a /65 or a
> /63 to designate these links.
> 
> And yes, the privacy extensions RFC4941 makes that attacker may use that
> overall number /64 to generate addresses, and defender may need to use
> same number /64 to comfortably protect against it.  A smarter attacker
> would use a /63 and a smarter defender too.

Definitely. However, as an attacker, having a smaller prefix than a IPv6 /64 to exploit for your attack could correspond in IPv4 to use a smaller prefix than /32.
I mean that as a defender, i would use against an attacker who smartly uses its /63 or smaller, the same techniques than an attacker who have access to an IPv4 /31 or smaller: blacklist sequentially all IPv6 /64 that this attacker is using. So anyway, a /64 boundary would at least help to leverage the problem.

This could also be a good hint to network operators or hosters. Some virtual machine providers (for instance) divide their /64 into smaller prefixes (i saw /96), which may imply that a bad behavior from one of their clients might influence other servers. I think there should be a clear mention of the consequences it may have. Such a mention may help to promote best practices (TODO: define best practices).

Best regards
Emmanuel Thierry


> 
> Le 09/01/2014 18:51, Emmanuel Thierry a écrit :
>> Hello,
>> 
>> (first message on these lists, hope it is accurate)
>> 
>> I'm generally thinking that the /64 limit helps to structure the
>> address space from the receiver point of view. Let's say i'm running
>> a mail server which tries to reduce spam by temporarily blacklisting
>> some senders. if i'm facing spammers who use their IPv6 address
>> space in a smart way, they will just have to generate RFC 4941
>> addresses to exhaust a firewall memory. The pragmatic way to face
>> such attacks is to blacklist the whole /64, never a unique /128.
>> 
>> I don't know if it is to be considered as a best practice, but for
>> these reasons, as a receiver, i personally consider a /64 to be
>> assigned to a unique link, or at least a network managed by a unique
>> network administrator. Enforcing this limit in protocol standards
>> strengthen this assumption. This might be an additional argument for
>> the "please keep /64 for unique links".
>> 
>> As a consequence, subdivide a /64 into several prefixes in order to
>> assign it on several networks might create a risk for devices on one
>> network to be blacklisted by actions performed by some devices on
>> another network, in case the whole /64 have been blacklist by a
>> "pragmatic" receiver.
>> 
>> Best regards Emmanuel Thierry
>> 
>> Le 5 janv. 2014 à 23:07, Brian E Carpenter a écrit :
>> 
>>> Hi,
>>> 
>>> A group of us put this together following a discussion some weeks
>>> ago on the v6ops list about the 64-bit boundary in IPv6 addresses.
>>> Discussion belongs in 6man, please.
>>> 
>>> This draft is incomplete but we'd welcome input. Let me underline
>>> an important comment in the introduction:
>>> 
>>> _The purpose of this document is to analyse the issues around this
>>> question.  We make no proposal for change, but we do analyse the
>>> possible effects of a change._
>>> 
>>> 
>>> Brian + co-authors
>>> 
>>> -------- Original Message -------- Subject: I-D Action:
>>> draft-carpenter-6man-why64-00.txt Date: Sun, 05 Jan 2014 13:59:17
>>> -0800 From: [e-mail] Reply-To:
>>> [e-mail] To: [e-mail]
>>> 
>>> 
>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>> directories.
>>> 
>>> 
>>> Title           : Analysis of the 64-bit Boundary in IPv6
>>> Addressing Authors         : Brian Carpenter Tim Chown Fernando
>>> Gont Sheng Jiang Alexandru Petrescu Andrew Yourtchenko Filename :
>>> draft-carpenter-6man-why64-00.txt Pages           : 14 Date :
>>> 2014-01-05
>>> 
>>> Abstract: The IPv6 unicast addressing format includes a separation
>>> between the prefix used to route packets to a subnet and the
>>> interface identifier used to specify a given interface connected
>>> to that subnet. Historically the interface identifier has been
>>> defined as 64 bits long, leaving 64 bits for the prefix.  This
>>> document discusses the reasons for this fixed boundary and the
>>> issues involved in treating it as a variable boundary.
>>> 
>>> 
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc/draft-carpenter-6man-why64/
>>> 
>>> There's also a htmlized version available at:
>>> http://tools.ietf.org/html/draft-carpenter-6man-why64-00
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> --------------------------------------------------------------------
>>> 
>>> 
>>> 
> IETF IPv6 working group mailing list
>>> [e-mail] Administrative Requests:
>>> https://www.ietf.org/mailman/listinfo/ipv6
>>> --------------------------------------------------------------------
>> 
>>> 
>>> 
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list [e-mail] Administrative
>> Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>> 
>> 
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------