[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: comments on draft-ietf-v6ops-v6inixp-01.txt
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
hi nick,
Thank you very much for the comments. My responses inline.
Roque.
On Jul 28, 2009, at 8:42 AM, Nick Hilliard wrote:
Hello,
a couple of comments on the v6inixp draft.
- the text needs some style editing and a quick run-over with a
spell-checker. I'm happy to do this, but am just an ietf egg and
don't know what procedure to follow. The draft text as-is does not
look like the canonical text source.
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.
- 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?
- the ixp should maintain a list of
I cannot find this peace of text in the document.
- 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.
- it may be good to suggest the use of GTSM in addition to MD5 /
ipsec. Does anyone actually use ipsec for securing bgp sessions? I
hear only occasional talk and have never come across it in practice.
ok will add reference to GTSM. 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
- 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?
- 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.
- section 2: (minor) ipv4 requires both 0x0800 (ipv4) and 0x0806 (arp)
ok, I was particularly mention how to differentiate between v4 and v6
data traffic
- 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.
- 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.
r.
Nick
- -------------------------------------------------------------
Roque Gagliano
LACNIC
roque@lacnic.net
GPG Fingerprint: E929 06F4 D8CD 2AD8 9365 DB72 9E4F 964A 01E9 6CEE
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
iEYEARECAAYFAkpviAQACgkQnk+WSgHpbO5tCACff/FUocahlYsBC1NIs/WY1NUk
nNIAoJo7InY1mRAAMY0YdcvKIXAMm4TZ
=FE83
-----END PGP SIGNATURE-----