icmp-type for target:: cisco inet6 generates error

[GoogleCodeExporter]

What steps will reproduce the problem?
1.include in policy file:

term icmp-filter-IRC-servers-I {
  destination-address:: IRC_SERVERS_SNT
  icmp-type:: echo-reply
  protocol:: icmp
  action:: accept
}

2. change 'target:: cisco' to inet6 or mixed

3. run aclgen.py

Traceback (most recent call last):
  File "./aclgen.py", line 172, in <module>
    main()
  File "./aclgen.py", line 152, in main
    count = load_and_render(FLAGS.policy_directory, defs)
  File "./aclgen.py", line 69, in load_and_render
    defs))
  File "./aclgen.py", line 114, in render_filters
    do_output_filter(str(fw), filter_name(source_file, fw._SUFFIX))
  File "/home/hoek/capirca-test/lib/cisco.py", line 634, in __str__
    target.append(str(term))
  File "/home/hoek/capirca-test/lib/cisco.py", line 394, in __str__
    self.term.name)
  File "/home/hoek/capirca-test/lib/aclgenerator.py", line 163, in NormalizeIcmpTypes
    self.term.name))
lib.aclgenerator.MismatchIcmpInetError: ICMP/ICMPv6 mismatch with address 
family IPv4/IPv6 in term icmp-filter-IRC-servers-I

What version of the product are you using? On what operating system?
capirca revision 155 (didn't work on rev 149 either) on ubuntu 11.10

Original issue reported on code.google.com by rhh...@gmail.com on 20 Dec 2011 at 4:39

[GoogleCodeExporter]

Thank you for reporting this.  The issue was confirmed and the code has been 
fixed.
This has been resolved in revision 167.

Original comment by watson on 28 Feb 2012 at 11:44

• Changed state: Fixed

[GoogleCodeExporter]

Sorry to say but the issue is still not fixed.
I have tested with version 168 and 172. 
Sample policy file:
-------------------------------------------
header {
#  target:: cisco icmp_type_test inet6
  target:: cisco icmp_type_test mixed
}

term icmp-test {
  destination-address:: WEB_SERVERS MAIL_SERVERS
  protocol:: icmp
  icmp-type:: unreachable
#  icmp-type:: echo-request unreachable time-exceeded
  action:: accept
}

-------------------------------------------

Output of aclgen.py (V172)
Traceback (most recent call last):
  File "./aclgen.py", line 184, in <module>
    main()
  File "./aclgen.py", line 164, in main
    count = load_and_render(FLAGS.policy_directory, defs)
  File "./aclgen.py", line 69, in load_and_render
    rendered += render_filters(fname, defs)
  File "./aclgen.py", line 122, in render_filters
    do_output_filter(str(fw), filter_name(source_file, fw._SUFFIX))
  File "/home/tens/capirca/lib/cisco.py", line 636, in __str__
    target.append(str(term))
  File "/home/tens/capirca/lib/cisco.py", line 394, in __str__
    self.term.name)
  File "/home/tens/capirca/lib/aclgenerator.py", line 163, in NormalizeIcmpTypes
    self.term.name))
lib.aclgenerator.MismatchIcmpInetError: ICMP/ICMPv6 mismatch with address 
family IPv4/IPv6 in term icmp-test

Original comment by rhh...@gmail.com on 23 Mar 2012 at 1:03

[GoogleCodeExporter]

I'm starting to replace our in house Cisco ACL generator with Capirca and have 
also had problems with this bug.

There are two ICMP protocols recognized by Capirca: icmp (for IPv4) and icmpv6 
(for IPv6). If you try to use icmp in an IPv6 filter it will fail with 
MismatchIcmpInetError - this is fine. 

Unfortunately Cisco output generator handles mixed filter types as two separate 
filters - extended and inet6. NormalizeIcmpTypes function does not see that the 
original filter type was "mixed" but only the address family for current pass 
of filter. Therefore it is not possible to use any kind of ICMP terms with 
mixed filter type.

I think the best way to handle policies of mixed filter types would be to 
modify NormalizeIcmpTypes to ignore af - icmp protocol mismatches and skip that 
term if the filter type is mixed. If filter type is not mixed, do still raise a 
MismatchIcmpInetError exception on mismatch.

Just my two cents.

Original comment by ma...@vadnjal.net on 23 Mar 2012 at 3:08

[GoogleCodeExporter]

re-opening this issue to take a look at reported concerns with cisco 'mixed' 
filters.

Original comment by watson@google.com on 16 Jul 2012 at 3:04

• Changed state: Accepted

[GoogleCodeExporter]

So this is fundamentally a problem outside the scope of Capirca.  Specifying a 
'mixed' filter effectively creates a list ['inet', 'inet6'] of filter types to 
iterate through, generating two output filters.  By specifying 'mixed' while 
also using "protocol:: icmp" or "protocol:: icmpv6" you are ensuring that at 
least one pass (either inet or inet6) will fail with an icmp/AF mismatch.  This 
isn't a bug in Capirca, but a reality that IPv4 and IPv6 have different ICMP 
specifications (perhaps blame the IETF :) http://tools.ietf.org/html/rfc4443 )

In order to resolve this problem I'd propose that instead of one policy of type 
'mixed', create two policies - one for inet and one for inet6.  Each policy 
will then be able to properly specify icmp for the AF.

Original comment by watson@google.com on 16 Jul 2012 at 4:00

• Changed state: WontFix

[GoogleCodeExporter]

It is clear that IPv4 and IPv6 have different ICMP specifications. But there 
are some icmp-types that are valid for both, icmp and icmpv6.
Is it possible that capirca just generates a warning and then skips the 
erroneous term and then continue rendering the output? 

Another approach could be that, by default, an inet designation skips all 
'protocol:: icmpv6' terms and an inet6 skips all 'protocol:: icmp' terms.

My point is that the strength of capira is that you can create just one policy 
and generate both, an IPv4 and IPv6 ACL.

Original comment by rhh...@gmail.com on 17 Jul 2012 at 8:59

[GoogleCodeExporter]

Ok.  So it seems reasonable to not render a 'protocol:: icmpv6' term inside an 
'inet' filter, and similarly not to render a 'protocol:: icmp' term inside an 
'inet6' filter.

I've added this check to the generator libs.
You can now develop a filter that includes both icmp and icmp6 terms, which 
only render when generating output of inet/inet6 respectively.  This should 
improve the ability to make cross-platform / cross-AF policies.

Thanks for the good suggestions and feedback.  Let me know if this works for 
you.

Implemented at r189

Original comment by watson@google.com on 18 Jul 2012 at 4:46

• Changed state: Fixed

[GoogleCodeExporter]

Thanks a lot!
Yes it works!
(tested with r195)

Original comment by rhh...@gmail.com on 19 Jul 2012 at 12:10