Displaying / filtering IPv6 ICMP types and codes

Tue Aug 4 14:06:37 EDT 2015

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
>
>
>> On Aug 4, 2015, at 9:09 AM, Ken Welker <kwelker at vt.edu 
>> <mailto:kwelker at vt.edu>> wrote:
>>
>> Hey Carter,
>>
>> ICMPv6 has some of the same names for types and codes, plus lots of 
>> new ones, and the numeric values are different; overall, I'd say 
>> things are fairly different.
>>
>> I'd be happy to help out with this how I can, as time is available.
>>
>> -Ken
>>
>> Ken Welker
>> kwelker at vt.edu
>> On 8/3/2015 2:19 PM, Carter Bullard wrote:
>>> Hey Ken,
>>> The list of v4 ICMP keywords we use in the filters today, such as 
>>> unreach, are basically from the list of types from IANA.  Are the 
>>> ICMPv6 types fundamentally different ???  Someone will need to 
>>> become the IPv6 ICMP expert if we intend to do a good job at this. 
>>>  Are you willing ???
>>> Carter
>>>
>>>
>>> 	
>>> 	
>>>
>>>
>>> On Aug 3, 2015, at 1:25 PM, Ken Welker <kwelker at vt.edu> wrote:
>>>
>>>> Hi Carter,
>>>>
>>>> Thanks for your quick reply.
>>>>
>>>> For displaying, the numeric Type/Code could be listed the same as 
>>>> in IPv4 (in the Sport field; Dport in IPv4 is the ICMP sequence 
>>>> number, right?).  Even better, perhaps add something like 
>>>> 'icmp-type' and 'icmp-code' to the list of fields that can be 
>>>> printed with the '-s' option. (This might be useful in IPv4 as well.)
>>>>
>>>> To update the simple example,
>>>>
>>>> ra -c, -r argus_file.gz -s stime flgs proto saddr daddr icmp-type 
>>>> icmp-code pkts bytes - proto ipv6-icmp
>>>>
>>>> could give the following
>>>>
>>>> StartTime,Flgs,Proto,SrcAddr,Dir,DstAddr,IcmpType,IcmpCode,TotPkts,TotBytes
>>>> 22:59:02.021047, e 
>>>> ,ipv6-icmp,2001:db8::1111,<->,2001:db8::5555,128,0,3,354
>>>> ...
>>>>
>>>>
>>>>
>>>> For filter, I'd like to be able to use a filter like " - ipv6-icmp 
>>>> and icmp-type 128", as well as  " - ipv6-icmp and icmp-type 128 and 
>>>> ! icmp-code 0", where it should be allowed to specify any numeric 
>>>> value in the legal range, regardless of whether it's defined.  (Of 
>>>> course, icmp type 128 (echo-request) only has code 0 defined, so 
>>>> all other codes would be anomalous and potentially suspicious.) 
>>>>  These filter options may be useful for IPv4 too.
>>>>
>>>> Adding the ability to alternately specify filter values as text, 
>>>> perhaps like " - ipv6-icmp and icmp-type destination-unreachable 
>>>> and icmp-code port-unreachable" may improve readability, but the 
>>>> numeric values would be the more flexible method.
>>>>
>>>> I'll work to get some anonymized flows sent to you directly.
>>>>
>>>> -Ken
>>>>
>>>> Ken Welker
>>>> kwelker at vt.edu <mailto:kwelker at vt.edu>
>>>> 540-231-0635
>>>>
>>>> On 8/3/2015 11:59 AM, Carter Bullard wrote:
>>>>> Hey Ken,
>>>>> Argus has been doing the V6 thing for an amazingly long time, the 
>>>>> first implementations being done before some of the ICMP messages 
>>>>> were created.  We haven’t put a lot of effort into V6 because 
>>>>> there has not been that much dialog around it, so the 
>>>>> implementation is not complete.
>>>>>
>>>>> OK, with that said, the type and code fields are in the flow 
>>>>> record, but there maybe some gaps in how those are aggregated, 
>>>>> processed and printed.  Which we can and will fix.
>>>>>
>>>>> So, can you give me some specifics on what is needed ??  Do you 
>>>>> have any records where you know what they should print, and how 
>>>>> you would want them printed ???  Can you share the argus file of 
>>>>> those records ??  That way we can have something concrete to talk 
>>>>> about ….
>>>>>
>>>>> Sorry for any inconvenience,
>>>>>
>>>>> Carter
>>>>>
>>>>>> On Aug 3, 2015, at 11:42 AM, Ken Welker <kwelker at vt.edu 
>>>>>> <mailto:kwelker at vt.edu>> wrote:
>>>>>>
>>>>>> Hi!  I'm using argus to explore options for analyzing IPv6 flows, 
>>>>>> and am having trouble figuring out how to display all ipv6-icmp 
>>>>>> Types and Codes.  The default display shows the Type in the Sport 
>>>>>> field, and a text summary code in the State field.  Perhaps the 
>>>>>> Code is included in the Dport field, but it always seems to be 0.
>>>>>>
>>>>>> Simple example:
>>>>>> ra -c, -r argus_file.gz - proto ipv6-icmp
>>>>>>
>>>>>> gives the following
>>>>>>
>>>>>> StartTime,Flgs,Proto,SrcAddr,Sport,Dir,DstAddr,Dport,TotPkts,TotBytes,State
>>>>>> 22:59:02.021047, e 
>>>>>> ,ipv6-icmp,2001:db8::1111,128,<->,2001:db8::5555,0,3,354,ECO
>>>>>> ...
>>>>>>
>>>>>> While the State field summarizes many of the type/code 
>>>>>> combinations, it doesn't cover them all, especially rare or 
>>>>>> undefined combinations.  IPv6 use is increasing, and since ICMPv6 
>>>>>> plays such a central role, it's likely that anomalous ICMPv6 
>>>>>> traffic will increase as well.
>>>>>>
>>>>>> Is it possible to display and/or filter on all numeric ICMPv6 
>>>>>> Types and Codes?  If not, may this be added?
>>>>>>
>>>>>> Thank you!
>>>>>>
>>>>>> -Ken
>>>>>>
>>>>>> -- 
>>>>>> Ken Welker
>>>>>> kwelker at vt.edu <mailto:kwelker at vt.edu>
>>>>>>
>>>>>>
>>>>
>>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20150804/e34c1824/attachment.html>