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

[Alexandru Petrescu <[e-mail]>]

Hello,

Just out of curiosity... below...

Le 10/01/2014 11:57, Emmanuel Thierry a écrit :
> 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),

When a virtual machine uses a /96 instead of a /64, is that prefix
present in an RA?

And, is there some address auto-configuration involved?  (wondering
about how is the Interface ID formed, because with Ethernet it must be
64bit long).

(for example, in some non-Ethernet links - like IP/USB, or some
IP/cellular - there are some particular non-documented mechanisms to
form Interface IDs; but these are still 64bit length, never 22bit)

Alex




  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
>> --------------------------------------------------------------------
>
>>
>>
> --------------------------------------------------------------------
>  IETF IPv6 working group mailing list [e-mail] Administrative
> Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
>