Re: comments on draft-ietf-v6ops-v6inixp-01.txt

[Nick Hilliard <[e-mail]>]

On 29/07/2009 00:21, Roque Gagliano wrote:
> as I mentioned in the WG I had several editorial text to change, I will
> go ahead and foward you the text before submission if that is ok.

No problem.

>> - it would probably be useful to mention that RA should be disabled on
>> all peering lan client routers and if possible, should be blocked at a
>> fabric level with some incantation of draft-ietf-v6ops-ra-guard.
>>
>
> In section 4 it says:
> " Configuring default routes in an IXP
> LAN without an agreement within the parties is normally against IXP
> policies. For that reason, eventhough routers should ignore them,
> rogue ICMPv6 route advertisements may be monitored in order to
> prevent configuration errors. "
>
> is that what you where looking for?

Partly, but it doesn't go far enough.  I'd suggest something like the 
following:

"IPv6 Router Advertisement packets should neither be issued nor accepted by 
routers connected to the IXP.  Where possible, the IXP operator should 
block link-local RA packets using IPv6 RA-Guard.  If this is not possible, 
the IXP operator should monitor the exchange for rogue Router Advertisement 
packets."

As an aside, it's very annoying that tshark doesn't dissect ND and RA 
packets properly and give complete information about source and dest hosts. 
  tcpdump works, but is limited in other areas.  So I end up using both, sigh.

>> - the ixp should maintain a list of
>>
>
> I cannot find this peace of text in the document.

Oops, silly me.  I meant to say that the IXP should maintain a list of all 
ipv6 addresses used by exchange participants.  Surprisingly, this is not 
the case for all IXPs today.

>> - section 6: there is no standard defined for TCP MD5 security for
>> ipv6 packets, although there are several interoperable implementations
>> out there in practice. RFC 2385 assumes ipv4.
>
> I just checked RFC2385 ad could not find a reference to IPv4 specific info.

No - there's no reference in there to ipv4 vs ipv6.  The calculation is 
similar but different due to differences in the ipv6 header.  For 
reference, take a look at tcp_signature_compute() in:

http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/tcp_subr.c?rev=1.349

It's not hugely different or anything, but there may be enough difference 
there to warrant clarification in the RFC.

> I remember the IPv6 round table in NANOG
> in LA, and NTT mentioned that they used IPSEC in Japan....that is as
> close as I got

interesting.

>> - is it worth suggesting that ipv4 bgp afi over ipv6 transport and
>> ipv6 bgp afi over ipv4 transport should be explicitly frowned upon for
>> route servers? It adds complication for no gain whatever.
>
> The current text implicitly mentions this point:
>
> "A good practice is to have IPv6 SAFI (Subsequent Address Family
> Identifiers) information carried over sessions established also on
> top of the IPv6 IP/TCP stack and independently of the IPv4 sessions.
> This configuration allows that in the event of IPv6 reachability
> issues to any IPv6 peer, the IPv6 session will be turned down and the
> IPv4 session to the same peer will not be affected. "
>
> is this enough?

I'm talking about generic bgp session data rather than just SAFI, but the 
same principal applies.  Maybe if the text were changed to read something 
like this:

It is recommended that all BGP sessions used to exchange IPv6 network 
information are configured using IPv6 data transport.  This configuration 
style ensures that as both network reachability information and generic 
packet data transport use the same transport plane, in the event of IPv6 
reachability problems between IPv6 peers, the IPv6 BGP session may be 
terminated independently of any IPv4 sessions.

Hmmm, that's a bit messy, but you get the idea.

>> - security considerations - at face value none. Mind you, I could see
>> small exchange customers getting very upset if their IXP wasn't using
>> MLD snooping and one of their 1G or 10G customers decided to shift a
>> couple of hundred megs of multicast traffic in a moment of
>> experimental exuberance.
>
> MLD snooping will only help you to check the associations to the
> solicited-node multicast group for ND. I believe you are referring to
> PIM snooping, which is not defined in any RFC nor supported in many
> equipments.

It's still a worry though.   Unwanted multicast flooding is bad for those 
ports which don't want it.

>> - I'm still wrangling with myself about the value of an ipv6 ND
>> sponge. Is it better for an end-user DoS attacker to trash an ipv6 lan
>> by causing persistent icmp6 multicast flooding, or by filling up the
>> ipv6 neighbor cache on all connected routers with ipv6 address entries
>> associated the mac address of an ipv6 ND sponge? Has anyone actually
>> measured this in practice? Is the reaction vendor specific? My worry
>> is that attacks of this form will happen one day and right now we are
>> not ready.
>
> so what you are proposing is that we should be able to limit the number
> of IPv6 addresses for a given MAC addresses that is advertised through
> ND to the switch in order to avoid the flooding of unsolicited Neighbor
> advertisement messages that could eventually fill someone's cache
> entries? Looks like a nice question to the list.

It would be very nice to be able to limit this at the switch level.  Dunno 
how you'd do it or anything, but there is a serious security concern here.

I wonder if any vendors might have any ideas on whether it would be 
possible to count the number of different ICMP6 ND packets received on an 
interface and block further ones if this goes beyond a certain limit?  How 
does one go about asking this in IETF-land?

>> - is it worth recommending that the IXP use l3 ipv6 filters to permit
>> only link-local traffic from their assigned (or chosen) address for
>> the purposes of BGP and icmp6 only? What I'm thinking of here is how
>> to deal with people who will do broken stuff like configuring tunnels
>> using their IXP assigned address.
>
> but the IXP assigned address is Global Unicast , not link-local. I can
> see that filtering unicast link-local could be done but I do not see the
> relationship to BGP and tunnels. I know that some people have talk about
> terminating BGP session in link-loca addresses to avoid problem when
> renumbering, but never seeing done and.

I had a situation some while back where an exchange participant configured 
NAT using their exchange LAN ip address, and ended up getting connectivity 
transport using the IXP's routing policy (there was/is transit connectivity 
to the exchange).  They had no malicious intent - it was more a case of not 
realising that this was just a dumb thing to do.

So we sat down and thought about what are the legitimate reasons to use 
your exchange IP address for, and really it's just for icmp, bgp, arp and 
traceroute replies.  If you see an exchange IP address being used for other 
purposes, there's almost certainly a problem.

Similarly in the ipv6 world, do you think it's worth noting that the ipv6 
address assigned or chosen should be used only for bgp, icmp6 and 
traceroute traffic?  Maybe this is too much to suggest as good practice in 
an I-D, though.

Nick