[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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