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

[Roque Gagliano <[e-mail]>]

-----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
[e-mail]
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-----