Displaying / filtering IPv6 ICMP types and codes
Ken Welker
kwelker at vt.edu
Thu Aug 6 09:16:36 EDT 2015
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
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
>> 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
>>> 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/371799a2/attachment.html>
More information about the argus
mailing list