Hi Gerhard, yes this is correct. The hash range is given by the function. But you need to define the "hash selection range" which is a subset of the hash range and gives you the range of hash values for which packets are selected. I think in general it would be good if it is possible to retrieve the initialiserValue but it should be possible to restrict access to this information. Kind regards Tanja > -----Ursprüngliche Nachricht----- > Von: Gerhard Muenz [mailto:muenz at net.in.tum.de] > Gesendet: Mittwoch, 21. Oktober 2009 13:38 > An: Zseby, Tanja > Cc: Benoit Claise; ipfix at ietf.org; DUFFIELD, NICHOLAS G (NICK); Aamer > Akhter (aakhter) > Betreff: Re: AW: Hash-based filtering config parameters > > > Hi Tanja, all, > > Ok, so if I understand correctly, the hash range directly results from > the choice of the hash function. > > BOB -> 0..2^32-1 > IPSX -> 0..2^16-1 > CRC-32 -> 0..2^32-1 > > Which means that we do not configure the hash range, only the hash > function. > > Please find below how the configuration data model looks like at the > moment. Feel free to comment. > > One detail which may be worth discussing: > If initiliserValue is not configured, the monitoring devices chooses > one > arbitrarily. > Should the NETCONF manager be able to retrieve this chosen value? > At the moment, this is not foreseen in the model, meaning that the > chosen value will not be given to the NETCONF manager. Not sure which > behavior is desired. > > Regards, > Gerhard > > > +--------------------------+ > | FilterHash | > +--------------------------+ 1..* +---------------+ > | hashFunction = BOB |<>-------| SelectedRange | > | ipPayloadOffset = 0 | +---------------+ > | ipPayloadSize = 8 | | name | > | digestOutput = false | | min | > | initialiserValue[0..1] | | max | > +--------------------------+ +---------------+ > > Figure 10: Filter classes > > For hash-based filtering, the configuration parameters are: > > hashFunction: Hash function to be used. The following parameter > values are defined by the configuration data model: > * BOB: BOB Hash Function as specified in [RFC5475], Appendix > A.2 > * IPSX: IP Shift-XOR (IPSX) Hash Function as specified in > [RFC5475], Appendix A.1 > * CRC: CRC-32 function as specified in [RFC1141] > The default value is "BOB". > > ipPayloadOffset, ipPayloadSize: ipPayloadOffset and ipPayloadSize > configure the offset and the size of the payload section used as > input to the hash function. These parameters correspond to the > Information Elements hashIPPayloadOffset and hashIPPayloadSize > [RFC5477]. Default values are 0 and 8, respectively, > corresponding to the minimum configurable values according to > [RFC5476], Section 6.2.5.6. > > digestOutput: digestOutput enables or disables the inclusion of > the > packet digest in the resulting PSAMP Packet Report. This > requires > that the Cache Layout of the Cache generating the Packet Reports > includes a digestHashValue field. This parameter corresponds to > the Information Element hashDigestOutput [RFC5477]. > > initialiserValue: Initialiser value to the hash function. This > parameter corresponds to the Information Element > hashInitialiserValue [RFC5477]. If not configured, the > monitoring > device arbitrarily chooses an initialiser value. > > One or more ranges of matching hash values are defined by the min > and > max parameters of the SelectedRange subclass. These parameters > correspond to the Information Elements hashSelectedRangeMin and > hashSelectedRangeMax [RFC5477]. > > > Zseby, Tanja wrote: > > Hi all, > > > > in general the parameters are configurable (section 7.2 of RFC5475) > in order to support different (proprietary) hash functions. But for the > usage of the recommended BOB function these parameters have to be > filled with the according values and are fixed (see section 6.2.4.1. of > RFC5475 which is in line with RFC 5476). > > > > Kind regards > > Tanja > > > > > >> -----Ursprüngliche Nachricht----- > >> Von: Benoit Claise [mailto:bclaise at cisco.com] > >> Gesendet: Mittwoch, 21. Oktober 2009 10:54 > >> An: Gerhard Muenz > >> Cc: ipfix at ietf.org; Zseby, Tanja; DUFFIELD, NICHOLAS G (NICK); me; > >> Aamer Akhter (aakhter) > >> Betreff: Re: Hash-based filtering config parameters > >> > >> Gerhard, > >> > >>> Hi Tanja, Benoit, all, > >>> > >>> I have two questions regarding the configuration of hash-based > >> filtering. > >>> 1) Are IP header fields/bits fixed or configurable? > >>> > >>> RFC 5475, Section 7.2 says: > >>> http://tools.ietf.org/html/rfc5475#section-7.2 > >>> > >>> Case hashing: > >>> - Hash Domain (input bits from packet) > >>> - <Header type = IPv4> > >>> - <Input bit specification, header part> > >>> - <Header type = IPv6> > >>> - <Input bit specification, header part> > >>> - <payload byte number N> > >>> - <Input bit specification, payload part> > >>> > >>> => header bits seems to be configurable > >>> > >>> > >>> RFC 5476, Section 6.5.2.6 says: > >>> http://tools.ietf.org/html/rfc5476#section-6.5.2.6 > >>> > >>> In Hash-based Selection, a Hash Function is run on IPv4 traffic. > >> The > >>> following fields MUST be used as input to that Hash Function: > >>> > >>> - IP identification field > >>> > >>> - Flags field > >>> > >>> - Fragment offset > >>> > >>> - Source IP address > >>> > >>> - Destination IP address > >>> > >>> - A number of bytes from the IP payload. The number of bytes > >> and > >>> starting offset MUST be configurable if the Hash Function > >>> supports it. > >>> > >>> => header fields seems to be fixed. > >> I would be tempted to believe the protocol. So RFC5476. > >> > >> I'll let Tanja or Nick answer the question below. > >> > >> Regards, Benoit. > >>> > >>> > >>> 2) Is the output range of the hash function a configuration > parameter > >>> or just an invariant property of the hash function itself? > >>> If yes, should it be configured as min and max or as length and > >> bitmask? > >>> RFC 5475, Section 7.2 says: > >>> http://tools.ietf.org/html/rfc5475#section-7.2 > >>> > >>> - Hash Function > >>> - Hash Function name > >>> - Length of input key (eliminate 0x bytes) > >>> - Output value (length M and bitmask) > >>> - Hash Selection Range, as a list of non-overlapping > >>> intervals [start value, end value] where value is in > >>> [0,2^M-1] > >>> - Additional parameters are dependent on specific Hash > >>> Function (e.g., hash input bits (seed)) > >>> > >>> => output value length and bitmask seem to correspond to the output > >>> range defined by hashOutputRangeMin and hashOutputRangeMax > >>> > >>> Thanks, > >>> Gerhard > >>> > > > > -- > Dipl.-Ing. Gerhard Münz > Chair for Network Architectures and Services (I8) > Technische Universität München - Department of Informatics > Boltzmannstr. 3, 85748 Garching bei München, Germany > Phone: +49 89 289-18008 Fax: +49 89 289-18033 > E-mail: muenz at net.in.tum.de WWW: http://www.net.in.tum.de/~muenz >
Attachment:
smime.p7s
Description: S/MIME cryptographic signature