Re: [v6ops] new draft: draft-elkins-v6ops-multicast-virtual-nodes

[Andrew 👽 Yourtchenko <[e-mail]>]

Hi Michael,

On 9/19/14, Ackermann, Michael <[e-mail]> wrote:
> HI Andrew
>
> Thanks for the great responses and related information.
>
> My comment on the inclusion of MLD,  is that we talked a lot about MLD
> during the creation of this draft and it certainly is consistent with the
> theme and adds to the issues.   However, we chose to leave MLD out of this
> draft, in an effort to keep the draft smaller and more focused.   We do
> mention MLD as being a related factor but state it is outside of the scope
> of the draft.     Given that, a question for you is if you feel this draft
> SHOULD include MLD?

No, my point was about the overall approach of the draft - there
seemed to be two aims:

1) the "TBD" placed into the section aiming at general design of subnets,

2) a question "should the hosts respond to ff0x::1?" following after
the description of a link-local equivalent of a smurf attack.

If the draft had just the (2) above (even limit it to just
observations, maybe? Could someone else from the community chime in
who thinks it is a problem?), and also discussed whether one can use
larger scopes (what happens if ff05::1?), and the *operational*
measures that can be taken today to prevent that threat, this would
make it self-contained. As of now, it reads a bit unclear, and (1) is
a rather broad topic to cover adequately while keeping it a short
read, if you wanted to do so.

>
> One other comment is that although there is education and information about
> these types of IPv6 subjects/issues, most large enterprises are unaware of
> any of this.   Our hope was to spare them from having an unpleasant initial
> experience with IPv6, by pointing out some issues  and pitfalls we have run
> into.   There is enough reluctance to pursue IPv6, in the corporate and
> large enterprise environments today and we want to eliminate as many
> negatives from that decision process as possible.
>
> Hope that makes sense.

My general feeling: if a network is designed/operated in such a way
that ping6 ff02::1 is an unpleasant experience, there should be a big
warning sign "this is the least of your worries, you did not do your
homework, so buckle up for the real fun to come".

At the same time,  if you indeed saw someone operationally messing up
the network due to this issue - a short focused document discussing
the observations and mitigations would be useful to point those people
to.

--a

>
> Thanks again
>
> Mike
>
>
>
> -----Original Message-----
> From: v6ops [mailto:[e-mail]] On Behalf Of Andrew ??
> Yourtchenko
> Sent: Friday, September 19, 2014 4:27 PM
> To: Nalini Elkins
> Cc: [e-mail];
> [e-mail]
> Subject: Re: [v6ops] new draft: draft-elkins-v6ops-multicast-virtual-nodes
>
> On 9/19/14, Nalini Elkins <[e-mail]> wrote:
>>
>>>A directed broadcast ping on IPv4 gives pretty much the same result.
>>>Did you test the effects of that ?
>>
>> I had not.  But, since you mentioned it, I did it on two different
>> Windows machines.  The one that is the server in question had the
>> following results:
>>
>> C:\Users\Administrator>ping x.x.x.255
>>
>> Pinging x.x.x.255 with 32 bytes of data:
>> Request timed out.
>> Request timed out.
>> Request timed out.
>> Request timed out.
>>
>> Ping statistics for x.x.x.255:
>>     Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
>>
>> Arp cache was not updated.   I did a packet trace in the background and
>> indeed no ICMP replies were seen.
>>
>> I did the same ping x.x.x.255 on one of my client PCs and saw:
>>
>> Pinging x.x.x.255 with 32 bytes of data:
>> Request timed out.
>> Request timed out.
>> Request timed out.
>> Request timed out.
>>
>> But this time the packet trace showed that actually ICMP replies were
>> sent.
>>
>
> So, besides this cosmetic difference the behavior is identical for the case
> of IPv4 ping ?
>
>>>Of course, private VLANs or (if we are talking VMs) or just using p2p
>>>links with /128s would help this in the environments where the hosts
>>>can not be trusted - and this of course is not virtual/physical
>>>specific.
>>
>> Yes.  We wanted to bring up the topic of isolation of nodes for
>> discussion.
>
> This is a useful topic in general - especially in light of the MLD-related
> thread, but the draft seems to focus on a very corner case
> - there are many much better reasons not to do large L2 networks.
>
>>
>>>If we're talking specifically virtual environment, here's an approach
>>>on how to use ebtables to isolate the hosts:
>>
>>>ebtables -P FORWARD DROP
>>>ebtables -F FORWARD
>>>ebtables -A FORWARD -i $uplinkPort -j ACCEPT # let the traffic flow
>>>from uplink to any ports ebtables -A FORWARD -o $uplinkPort -j ACCEPT
>>># let the traffic flow from any ports to uplink
>>
>>>(source:http://serverfault.com/questions/388544/is-it-possible-to-enab
>>>le-port-isolation-on-linux-bridges)
>>
>> I think this is very good.  But, unfortunately not very well known.
>> Also,
>> is this possible for all platforms or just Linux?
>
> This was just my first google.com search result when searching for "private
> vlans linux".
>
> The first google.com search result on "private vlans windows" brings up
> http://blogs.technet.com/b/scvmm/archive/2013/06/04/logical-networks-part-iv-pvlan-isolation.aspx
> which seems to document similar technique.
>
> "private vlan vmware" results in
> http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1010691
> as its first hit.
>
> Would an IETF publication be easier to find than the above ?
>
>>
>>>So looks like the question at hand is:
>>
>>>"Should IPv6 nodes respond to Ping to FF0x::1?"
>>
>>>Which can be rephrased differently to ease the start of the discussion:
>>
>>>"What are the legitimate uses of a ping to ff0x::1 ?"
>>
>>>Right ?
>>
>> Yes.
>
> Allright, so I'll mention my use of ping6 ff0x::1:
>
> * quick check to find "a few hosts that are alive on this link"
> (obviously not to be done on large segments).
>
> * A way to trigger the remote side's ND process without having to do one
> myself (I know the multicast packet to all-hosts *will* usually get received
> regardless of the underlying issues with the L2.5 infrastructure (snooping,
> etc.)
>
> * A way to further debug malfunctioning L2.5 infra, by comparing the
> reaction to pings to ff02::1, solicited node multicast, other multicast
> groups, etc.
>
> Summary: the ff02::1 current ping behavior does help in a non-trivial amount
> of cases.
>
> The security aspects the draft mentions indeed do exist, but in a properly
> configured network can be easily mitigated as I've shown above. So I'd be
> against changing the functionality in the existing stacks.
>
> On the education side: the existing search results
> https://www.google.com/?gws_rd=ssl#q=ping6+ff02::1 show 8000-something
> results - so indeed probably this behavior may be highlighted more during
> the IPv6 education. However: every IPv6 course I've heard says "there is no
> broadcast in IPv6, but there is all-hosts multicast" which should not make
> the behavior the draft describes a major surprise.
>
> --a
>
>>
>> --a
>>
>>
>> On 9/19/14, [e-mail] <[e-mail]> wrote:
>>> A new draft has been posted, at
>>> http://tools.ietf.org/html/draft-elkins-v6ops-multicast-virtual-nodes.
>>> Please take a look at it and comment.
>>>
>>> _______________________________________________
>>> v6ops mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/v6ops
>>>
>
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>
>
> The information contained in this communication is highly confidential and
> is intended solely for the use of the individual(s) to whom this
> communication is directed. If you are not the intended recipient, you are
> hereby notified that any viewing, copying, disclosure or distribution of
> this information is prohibited. Please notify the sender, by electronic mail
> or telephone, of any unintended receipt and delete the original message
> without making any copies.
>
>  Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are
> nonprofit corporations and independent licensees of the Blue Cross and Blue
> Shield Association.
>