Displaying / filtering IPv6 ICMP types and codes

Wed Aug 5 12:55:08 EDT 2015

Hey Ken,
This is a great first start.  

I suggest that we will support a generic type of filter strategy such as:

   ‘icmp[v4|v6]  [[type keyword] [code keyword]]’  icmpv4 or icmpv6 with optional keyword modifiers
   ‘icmp[v4]     type num [code num]’              icmpv4 with numeric keyword modifiers
   ‘icmpv6       type num [code num]’              icmpv6 with numeric keyword modifiers

So this will support these types of examples:

   ‘icmp’                  - any icmp flow, v4 or v6
   'icmp unreach'          - any icmp unreachable flow, v4 or v6
   'icmp echo reply'       - any icmp echo flow, v4 or v6, that had a reply
   ‘icmpv4 type 5 code 2’  - any icmp v4 redirect for TOS
   ‘icmpv6 type 1 code 5’  - any icmp v6 src address failure policy

I think this works pretty well.  There are a few keywords that can be shared between v4 and v6, and we’ll have to work with those.

Currently, for ipv4 icmp, we have a bunch of shortcut keywords, so you can get the idea in one word.
These are echo, redirect, timexed and unreach.  The unreach category has a bunch of keywords, unrnet, unrhost, unrproto, unrport, unrfrag, unrsrcfail, unrnetunk, unrhostunk, unrios, unrnetpro, unrhostpro, unrnettos, unrhosttos, unrfilter, unrhostpre and unrprecut.  This strategy doesn’t give you all the control you may want.  It maybe better to offer:

   ‘unreach'
   ‘unreach host’
   ‘unreach host tos’

Seems that you are breaking down this type of query taxonomy using ‘-’s, in your keyword strings.
The compiler can deal with the ‘-’s in tokens, so that is not a deal breaker, but I’m not sure that they are quite right.   So lets go through a bit to see if we can address the implied strategy and see if we can get something that works.

In the current implementation, “echo-req” and “echo-reply” are approached using “echo”, which implies “echo req or echo reply”, and picks them both up.

    ra - echo

vs your

    ra - echo-req or echo-reply

Currently, we don’t have the optional modifiers for ‘req' and ‘reply'.  You can figure out the req vs reply with the pkt counts, but it would probably be better to have keywords.

But the keywords are there as shortcuts for the numeric filter strategy.
So, do we want to try to support a little hierarchy ???

Something like “mcast-lstnr req” or “mcast-lstnr-query” ???
“mcast-lstnr reply” or “mcast-lstnr-resp” ???

That makes “mcast-lstnr” a keyword for any multicast listener traffic ???

Maybe that we can use the types as keywords, and the codes as modifiers, without typing the word type and code in the query ????
What do you think ???

Carter

> On Aug 5, 2015, at 11:12 AM, Ken Welker <kwelker at vt.edu> wrote:
> 
> Hey Carter,
> 
> Here's a first stab at defining text equivalents of the defined Types and Codes.  Hopefully they're consistent and distinctive, though people can weigh in on that.  These would allow users to make filter commands more readable, at least for defined ones, if they so choose.
> 
> -Ken
> 
> (These are from http://www.iana.org/assignments/icmpv6-params/icmpv6-params.xhtml <http://www.iana.org/assignments/icmpv6-params/icmpv6-params.xhtml>, hacked up by me.)
> 
> Type,String
> -----------
> 1,dst-unreach
> 2,pkt-too-big
> 3,time-exc
> 4,param-prob
> 128,echo-req
> 129,echo-reply
> 130,mcast-lstnr-query
> 131,mcast-lstnr-rpt
> 132,mcast-lstnr-done
> 133,rtr-sol
> 134,rtr-adv
> 135,neigh-sol
> 136,neigh-adv
> 137,redir
> 138,rtr-renum
> 139,icmp-node-info-query
> 140,icmp-node-info-resp
> 141,inv-neigh-disc-sol
> 142,inv-neigh-disc-adv
> 143,v2-mcast-lstnr-rpt
> 144,home-agt-addr-disc-req
> 145,home-agt-addr-disc-reply
> 146,mob-pref-sol
> 147,mob-pref-adv
> 148,cert-path-sol
> 149,cert-path-adv
> 151,mcast-rtr-adv
> 152,mcast-rtr-sol
> 153,mcast-rtr-term
> 154,fmipv6
> 155,rpl-cont
> 156,ilnpv6-lctr-update
> 157,dup-addr-req
> 158,dup-addr-confm
> 159,mpl-cont
> 
> Type,Code,String
> ----------------
> 1,0,no-rt-to-dst
> 1,1,dst-admin-prohib
> 1,2,beyond-scope-src-addr
> 1,3,addr-unreach
> 1,4,port-unreach
> 1,5,src-addr-fail-ingr-egr-pol
> 1,6,rej-rt-to-dst
> 1,7,err-src-rtg-hdr
> 
> 3,0,hop-limit-exc
> 3,1,frag-rsmb-time-exc
> 
> 4,0,err-hdr-field
> 4,1,unrec-next-hdr-type
> 4,2,unrec-ipv6-opt
> 4,3,first-frag-incompl-ipv6-hdr-chain
> 
> 138,0,rtr-renum-cmd
> 138,1,rtr-renum-result
> 138,255,seq-num-reset
> 
> 139,0,ipv6-addr-query
> 139,1,name-query
> 139,2,ipv4-addr-query
> 
> 140,0,success
> 140,1,resp-refused
> 140,2,unk-qtype
> 
> Ken Welker
> kwelker at vt.edu <mailto:kwelker at vt.edu>
> 540-231-0635
> On 8/4/2015 2:06 PM, Ken Welker wrote:
>> Carter,
>> 
>> Agree that printing and filtering are the most important tasks.
>> 
>> From my testing, it looks like the ICMPv6 Type is printed in the low byte of the Sport field, while the Code is in the high byte, such that Sport = (Code*256) + Type; Dport is always 0.  That's not horrible to decode, but requires a bit of effort if Code is nonzero.  These are printed in decimal, but allowing a choice between hex and decimal would allow the user to express their preference.
>> 
>> Looks like IPv4 also stuffs both Type and Code in the Sport like that as well, but prints in hex.
>> 
>> Perhaps there's a few defined combinations of Type/Code that can be added to the State field; haven't looked at that yet thoroughly.  I'm mostly thinking about all the *undefined* ones, like Type 128 (echo-request) and code 42 (??? from IANA).  That's why I think it would be good to allow displaying Type and Code in their own columns if desired.
>> 
>> As for filtering, compiler keywords for Type and Codes will be good, but again, I'm thinking about all the undefined ones that I eventually will want to be able to filter on as needed.  I agree that the icmp keyword should include both in filtering (but I just got syntax errors with it), and I like the icmpv4 and icmpv6 shortcuts. 
>> 
>> -Ken
>>   
>> Ken Welker
>> kwelker at vt.edu <mailto:kwelker at vt.edu>
>> 540-231-0635
>> On 8/4/2015 11:12 AM, Carter Bullard wrote:
>>> Hey Ken,
>>> There are a number of basic operations that argus clients need to do with the data that is in an argus record.  Print, filter, sort, graph, aggregate, union, join, intersection, split, anonymize, etc …
>>> 
>>> The most important first step is printing and filtering.  
>>> 
>>> For printing, if you think the State field for ICMPv6 needs work, we’ll need to figure out which types and codes need help.  The type and code fields are in the src and dst port fields, just like IPv4.  If that doesn’t look to be working, then we need to fix that.  ICMP type and code fields by default are hex outputs, do you think you want to be able to change that format, say to a decimal value ???
>>> 
>>> Can we get a list of the compiler keywords we want to use to filter on type and code values for ICMPv6 ???  Numbers are not the best way to do that.
>>> 
>>> We don’t make a distinction between ipv4 and ipv6 when you use the icmp keyword to get any icmp traffic, so we could add shortcut terms ‘icmpv4’ and ‘icmpv6’.  To get just ipv6-icmp, you have to say “ proto ipv6-icmp “, so we can add that. 
>>> 
>>> We currently support 4 icmp type filter keywords, but they apply to only v4 icmp:
>>>    ‘echo’
>>>    ‘unreach’
>>>    ‘redirect’
>>>    ‘timexed’
>>> 
>>> We’ll need to extend the keywords so that they generate filters for ipv6-icmp.
>>> 
>>> The keywords ‘type’ and ‘code’ are not used, so we can add that support to the filter, with the notion that they refer to icmp traffic. Generating a list of keywords for all the types and codes will be most of the heavy work we need.
>>> 
>>>  but to provide v4 vs v6 differentiation, we’ll need a filter like
>>>    “icmpv4 and type unreach and code port”
>>> 
>>> It maybe cool to be able to type:
>>> 
>>>    “icmpv4 unreachable port”
>>>    “icmpv4 redirect host"
>>> 
>>> That is possible, but we’ll need to get the syntax down pat.
>>> 
>>> If we get these issues nailed down, we may be able to say we did good ;O)
>>> Carter
>>> 
>>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20150805/7260bb64/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6837 bytes
Desc: not available
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20150805/7260bb64/attachment.bin>