Displaying / filtering IPv6 ICMP types and codes

Thu Aug 6 22:16:41 EDT 2015

May I offer a vote to keep the hyphen for we poor folks who sometimes have to parse these lines of output and prefer awk ‘{print $(NF)}’ to something using PCRE.

--Dave

From: argus-info-bounces+dedelman=iname.com at lists.andrew.cmu.edu [mailto:argus-info-bounces+dedelman=iname.com at lists.andrew.cmu.edu] On Behalf Of Ken Welker
Sent: Thursday, August 6, 2015 9:17 AM
To: Carter Bullard <carter at qosient.com>
Cc: Argus <argus-info at lists.andrew.cmu.edu>
Subject: Re: [ARGUS] Displaying / filtering IPv6 ICMP types and codes

Hey Carter,

Those values I typed were just examples - certainly can be changed.  The dashes were just for readability, but I wasn't considering yet whether it fit with existing keywords.

I like your examples - these show some nice flexibility with text and numbers.  Having keywords for types that can optionally take modifiers for one or more specific codes seems logical. Seems like the "type" and "code" keywords themselves may not be really needed.

Having the ability to filter on the equivalent types/codes in both IPv6 and IPv4 seem like a powerful combination; probably worth the effort to share the same keywords.

Looks good!

-Ken

Ken Welker
kwelker at vt.edu <mailto:kwelker at vt.edu> 
540-231-0635

On 8/5/2015 12:55 PM, Carter Bullard wrote:

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 <mailto: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, 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/20150806/a1706508/attachment.html>