[pim] Re: draft-ietf-pim-gaap-11 early Rtgdir review

[Dino Farinacci <[e-mail]>]

Thanks Zheng for your comments. See responses inline. And after you see them, tell me if you think they require spec updating.

> ......
> 4.  GAAP Message Format
> ......
>   Record field descriptions:
> ......
>      Group Name:  A variable length group name the multicast
>         application uses.  It is in ASCII format [RFC0020].  The string
>         is terminated with a null character.  Since the Group Name is
>         variable length, subsequent records may not occur on a long- or
>         short-word boundary.
> 
> ZZ> Because the Group Name is variable-length, the message length may be
> unpredictable based on the Record Count. Furthermore, if the Group Name length
> isn't fixed, how do we determine the starting position of the next record? Is
> it determined by the string terminator "\0"? If it's determined by the string
> terminator, then the next record could start at any position, even a non-8-bit
> aligned position. Is that acceptable?

The starting point of the next record is after th "\0" character/byte. Yes, the next record can start on any byte, short-word, or long-word boundary. This happens all the time (all over the place in OSI protocols since many fields are byte-granularity and variable length).

> ......
> 6.  Detail Protocol Operation
> 
> 6.1.  Allocating Group Addresses
> 
>   When an application needs a group address it provides the GAAP API
>   with a group name, the group name is used as input to a SHA-256 hash
>   function [RFC6234].  Initially, when no group address collision is
>   detected the group name is passed as a string to the hash function
>   and the low-order 32-bits are used for a group address.  The
>   following pseudo-code illustrates the functionality:
> 
> ZZ> Using the algorithm in RFC6234, is the result calculated based on the Group
> Name unique? Is it possible for the same Group Name to correspond to different
> Group Addresses?

Its a one-way hash, so a given group name can only have one hash value. Low-probabilistically another group name could hash to the same value.

If any collision does not resolve quickly, the encryption key is unique so groups don't get joined together from the app level.

> ......
> 6.2.  Claiming Group Addresses
> 
>   When a group address is allocated by a GAAP node it will build and
>   send a Claim message.  Included in the Claim message is the group
>   name, group address, and timestamp.  If the group address collides
>   with other GAAP nodes already using the address, one of the nodes
>   will send a Claim message to notify the colliding node that it needs
>   to allocate a new group address.
> 
>   A collision is defined to be the same group address allocated to 2
>   different group names.  So if a GAAP node is claiming a group address
>   for its group name and a Claim is received with the same group name
>   with the same group address, it is not a collision.  It is simply a
>   peer group participant claiming the group address you both agree to
>   be using.
> 
> ZZ> The conflict is identified from different Group Names using the same Group
> Address. Does this imply two points? 1) that all GAAP-using applications must
> use the same Group Address when using the same Group Name? 2) addressing the
> same issue in section 6.1: if the hash result is not unique, is it normal for
> different applications to advertise the same Group Name but different Group
> Addresses?

No, the collision occurs because there are not enough random bits to hold the hash in a group address. So there could be a many-hash to one group address conflict.

By definition, all apps that use the same group name, will probablistically use the SAME group address.

The answer to your last question is, absolutely no. Because the group address, per this specification, is always derived from the group name (and this algorithm allocation is with the GAAP IANA assigned block). And we have decdied to make that a /10 IANA request for IPv4.

> ......
> 7.  Security Considerations
> 
>   It is strongly suggested that the GAAP protocol run over an encrypted
>   multicast channel.  All GAAP implementations should support the same
>   encryption mechanism and use the same key management procedure to
>   ensure interoperability.  This could be difficult in embedded devices
>   with different configurations.  The message Marker is used to
>   indicate if the packet is sent in plaintext or ciphertext.  If the
>   Marker is not set to 0xAAAAAAAA and the receiver does not have a
>   shared-key configured, the message MUST be dropped.
> 
> ZZ> As described in section 4, messages should be dropped regardless of whether
> the Marker field in the message is not set to 0xAAAAAAAA, or encrypted tunnel
> is used but the receiver is not configured with a shared key. Therefore, please
> consider revising "If the Marker is not set to 0xAAAAAAAA and the receiver does
> not have a shared key configured, the message MUST be dropped." to "If the
> Marker is not set to 0xAAAAAAAA or the receiver does not have a shared key
> configured, the message MUST be dropped."

I would say that is the same as saying it has the wrong key. And I think your text:

> "If the
> Marker is not set to 0xAAAAAAAA or the receiver does not have a shared key
> configured, the message MUST be dropped."

is wrong. It should be an "and" and not an "or". Basically, the spec says if you don't see the marker, the packet is not plaintext, so you need to decrypt, it you cannot decrypt with a key or have not key, you won't see the marker from the output (faulty plaintext).

> ......
>   The following attack threats may exist with possible mitigation
>   techniques:
> 
>   *  Even when an encrypted channel is used, a bad actor could be
>      claiming a group address not derived from one of the group name
>      inputs used for the Acceptable Group Hash List (see Definition of
>      Terms section).  Cooperating nodes should ignore such messages and
>      not try to send Claim messages to correct the bad actor node.
> 
>   *  A bad actor could send an invalid timestamp giving it tie-breaking
>      priority when a group address collision occurs.  If the group
>      address has been prior claimed by another node with a timestamp
>      earlier than the invalid timestamp, cooperating nodes should put
>      the bad actor node on a bad-actor list and ignore future messages
>      from it.  If the group name has not been claimed yet, the
>      timestamp will be accepted only if earlier than the current time
>      for the receiving node.
> 
>   *  A bad actor could send messages too often and is not adhering to
>      the random delay or periodic timer procedures in this document.
>      When this occurs, cooperating nodes should start ignoring messages
>      from the bad actor node and not reset or cancel timers, or send
>      triggered Claim messages
> 
> ZZ> Are there other bad actors that waste receiver processing time by
> constantly sending forged claim messages that carry Group Names that other
> nodes don't have?

When the GAAP API detects this (the protocol runs in the API), it can inform the applications that the group is being jammed, and we can have the apps choose a new group name (one that the actor cannot know). How it does that 
is out of scope since the apps can decide the level of paranoia they are willing to take.

Thanks again for your comments,
Dino