Mailing List Archive: ASR9001 ASR9901 IOS-XR IPv6 filtering

ASR9001 ASR9901 IOS-XR IPv6 filtering

Jun 10, 2020, 5:21 AM

Post #1 of 5 (1394 views)

Hi List,

I would like to filter the incoming IPv6 traffic from upstream and peering
relatively strong like I do it for IPv4
(no martian src allowed,
Traffic on the link to upstream/peerinc allowed,
my and customers prefixes allowed as dst ).

Having link-local addresses will complicate this ,
also the ND etc.
So I came up to a relatively long ACL and big question-marks:

1. With classical IOS, "IP" Rules include icmp, udp, tcp ,...
Is this also true on IOS-XR for IPv6 ?

2. On the Neighbor Discovery ets stuff is src and dst allway link-lokal
or must I allow explicit the four pairs LL-LL LL-real real-LL real-real ?

3. will that ACL work on the mentioned devices in Hardware
or is it done in software slowing down everything ?

With 1. And 2. I could probably short the sketch below down
and avoid unspecific icmp "any any "rules

!==========
ipv6 access-list AL6-FILTER-IN
! from http://www.bgp4all.com.au/pfs/_media/workshops/12-ipv6-security.pdf
2000 permit icmpv6 any any echo-reply
2010 permit icmpv6 any any echo-request
2020 permit icmpv6 any any 1 3
2030 permit icmpv6 any any 1 4
2040 permit icmpv6 any any packet-too-big
2050 permit icmpv6 any any time-exceeded
2060 permit icmpv6 any any parameter-problem
! not accepted 2070 permit icmpv6 any any mld-query
! not accepted 2080 permit icmpv6 any any mld-reduction
! not accepted 2090 permit icmpv6 any any mld-report
2100 permit icmpv6 any any nd-na
2110 permit icmpv6 any any nd-ns
2120 permit icmpv6 any any router-solicitation

!HSRP 2200 permit udp FE80::/16 eq 2029 host FF02::66 eq 2029

2900 deny icmpv9 any any
!
! tmp block bad src
3000 deny ipv6 2605:9880:300::/48 any
!
! transit to upstreams and peering
6000 permit ipv6 2001:qwer::1234/126 2001:qwer::1234/126
6020 permit ipv6 2001:789::/64 2001:789::/64
6030 permit ipv6 2001:asdf:ghjk:uiop::/64 2001:asdf:ghjk:uiop::/64
!
!! my and customers ipv6 ranges src
! wrong direction
!7000 permit ipv6 2a00:xxxx:/32 any
!7100 permit ipv6 2a01:asdf::/32 any
!
! my and customers ipv6 ranges dst
8000 permit ipv6 any 2a00:xxxx::/32
8100 permit ipv6 any 2a01:asdf::/32
!
9000 deny ipv6 any any
!
!==========

Thank you for suggestions on how do do this "right",

Juergen.

_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: ASR9001 ASR9901 IOS-XR IPv6 filtering [ In reply to ]

gert at greenie

Jun 10, 2020, 5:58 AM

Post #2 of 5 (1394 views)

Permalink

Hi,

On Wed, Jun 10, 2020 at 02:21:55PM +0200, cnsp@marenda.net wrote:
> 2. On the Neighbor Discovery ets stuff is src and dst allway link-lokal
> or must I allow explicit the four pairs LL-LL LL-real real-LL real-real ?

IPv6 ND sucks big time. You'll also see :: sources (DAD).

This is what we have at DECIX:

20 permit icmpv6 fe80::/64 2001:7f8::/64 nd-ns
30 permit icmpv6 2001:7f8::/64 2001:7f8::/64 nd-ns ttl eq 255
40 permit icmpv6 2001:7f8::/64 2001:7f8::/64 nd-na ttl eq 255
90 permit icmpv6 any ff02::/64 nd-ns
100 permit icmpv6 fe80::/64 fe80::/64 nd-ns
110 permit icmpv6 any fe80::/64 nd-ns
120 permit icmpv6 any fe80::/64 nd-na
130 permit icmpv6 any host ff02::1 nd-na
140 deny icmpv6 any any nd-ns log
150 deny icmpv6 any any nd-na log
160 permit ipv6 fe80::/64 fe80::/64
170 permit ipv6 fe80::/64 ff02::/64
180 deny ipv6 fe80::/64 any
...

(looking closer, I seem to have any-to-LLA nd-ns twice here... that is
obviously not needed)

You should be able to filter ND/NS by matching on TTL 255, but when
we did this, we saw peer routers send out NS with lower TTLs - which is
a violation of RFCs, but nobody seems to care...

We do filter link-local to anything non-multicast / non-onlink - nobody
should ever forward these, but we did see packets.

> 3. will that ACL work on the mentioned devices in Hardware
> or is it done in software slowing down everything ?

This is fairly easy, XR will do things in hardware, or not at all.

gert
--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany gert@greenie.muc.de

Re: ASR9001 ASR9901 IOS-XR IPv6 filtering [ In reply to ]

saku at ytti

Jun 10, 2020, 8:10 AM

Post #3 of 5 (1390 views)

Permalink

On Wed, 10 Jun 2020 at 16:04, Gert Doering <gert@greenie.muc.de> wrote:

> You should be able to filter ND/NS by matching on TTL 255, but when
> we did this, we saw peer routers send out NS with lower TTLs - which is
> a violation of RFCs, but nobody seems to care...

We match hop-limit 255, and not any addr globally in every market
against diverse set of implementations and have not had a single
issue. I suspect you may have attributed the problem incorrectly.

Please add a new rule before existing ones which is just hop-limit 255
match, and observe if counters move to that rule. It is normal to see
non-255 due to random internet trash.

We regularly do have IPv6 ND problems, sometimes IPv6 BGP to customer
breaks when _WE_ change device in our end, and the customer does
nothing. Because the customer is filtering ND address based and allows
only LL or only GUA and our end changed from LL to GUA or from GUA to
LL and is no longer allowed by the customer. Not always easy task
convincing customer their filters are wrong, when they changed nothing
and it broke, thanks IPv6!

--
++ytti
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: ASR9001 ASR9901 IOS-XR IPv6 filtering [ In reply to ]

chriztoffer.hansen at de-cix

Jun 10, 2020, 10:50 AM

Post #4 of 5 (1387 views)

Permalink

Saku Ytti wrote on 2020-06-10 17:10:
> Not always easy task
> convincing customer their filters are wrong, when they changed nothing
> and it broke, thanks IPv6!

Write a public FAQ article on your corp. website about it. And refer
customers to this every time your hit these "corner"-cases?

Re: ASR9001 ASR9901 IOS-XR IPv6 filtering [ In reply to ]

cnsp at marenda

Jun 12, 2020, 11:30 AM

Post #5 of 5 (1349 views)

Permalink

Thank you for sharing your experience and the concrete example .
Also good to know that I am not the only one trying to filter
up-streams/peerings and of course the customer's traffic.

Sorry for the late "thanks", I had to collect logs and dump
from the 9901 ? again,
https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvs53433
https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvu49346
with - for this list - a trivial configuration.
Worst cisco experience for the last 10 years.

Mit freundlichen Grüßen
Kind regards
Veuillez agréer mes salutations distinguées
Met vriendelijke groet

Jürgen Marenda.

_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Mailing List Archive

Mailing List Archive

Attached Files: