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

From: Nick Hilliard <[email-masked]>
Date: Tue, 28 Jul 2009 12:42:34 +0100

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.

- 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.

- the ixp should maintain a list of

- 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.

- 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.

- 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.

- 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.

- section 2: (minor) ipv4 requires both 0x0800 (ipv4) and 0x0806 (arp)

- 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.

- 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.

Nick

---

From: Roque Gagliano <[email-masked]>
Date: Tue, 28 Jul 2009 20:21:39 -0300

hi nick,

Thank you very much for the comments. My responses inline.

Roque.

On Jul 28, 2009, at 8:42 AM, Nick Hilliard wrote:

> 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
[email-masked]
GPG Fingerprint: E929 06F4 D8CD 2AD8 9365  DB72 9E4F 964A 01E9 6CEE

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 29 Jul 2009 11:57:01 +0100

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:

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.

> 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.

>> 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.

>> ipv6 bgp afi over ipv4 transport should be explicitly frowned upon for
>> route servers? It adds complication for no gain whatever.
>
> issues to any IPv6 peer, the IPv6 session will be turned down and the

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.
>

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

>> 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.
>
> 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

---

From: Martin Pels <[email-masked]>
Date: Thu, 30 Jul 2009 17:50:43 +0200

Hi,

On Wed, 29 Jul 2009 11:57:01 +0100
Nick Hilliard <[email-masked]> wrote:

> >> 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.

We've had a couple of students research this. The short summary is that
a ND sponge has less value than an ARP sponge. This because compared to
broadcast floods, flooded multicast frames not destined for the router
that receives them require little processing power. There are
differences per vendor though.
If you're interested, I can send you the full report.

Creating a DoS by filling up the cache on all routers with entries for
the sponge is a real risk. This can be mitigated by only sponging
addresses that are assigned to customers (or were in the past). Another
option is to implement the list of sponged addresses as a ring buffer,
where old entries are replaced by newer ones when the buffer is full.

> > 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.

For ND, IPv6 unicast addresses are mapped to a multicast Ethernet
address. Depending on the addressing plan of the IXP, it might be
possible to use Layer-2 ACL's to only allow ND requests to multicast
group addresses that correspond to IPv6 addresses assigned to routers on
the platform.

Kind regards,
Martin