GM -> Q :  HDR, SK{ IDg, REJ, AUTH } 			
		       Q -> GMs: HDR, SK{ S_REQ, AUTH }
		       GMs -> Q: HDR, SK{ SPI_LIST, AUTH }
		       Q -> GMs: HDR, SK{ SAtf, KDtf, AUTH }
						

Figure 3: GSAM_RE_DISTRIBUTION Exchange

In the first message, a GM that detects an SPI collision asserts the identification of the secure group that is the destination address of the rejected GSAM_TEK_GSA in payload IDg and shows its rejection to the suggested GSAM_TEK_GSA in payload REJ. Moreover, GM declares a MAC in payload AUTH.

Q multicasts the second message into a secure group identified by the received IDg. In this message, Q requests a list, called spi_list, in payload S_REQ and shows its signature in payload AUTH.

All GMs in the secure group will send the third message to respond to the request from Q. In the third message, a GM reports its spi_list in payload SPI_LIST and declares its MAC in the payload AUTH.

The fourth message is the same as the GSAM_PUSH message. In the fourth message, Q multicasts an SA pair (i.e., GSAM_TEK_SA) in payload SA and KD and declares a signature in the AUTH payload. However, the SPI parameter in GSAM_TEK_SA has been negotiated with all GMs in the secure group and therefore it cannot cause any collision.

5.2. Querier Operations

When an EU is registered as the first GM of a secure group in the segment, Q will multicast the GSAM_PUSH exchange message in two groups in order: (1) the group 224.0.0.22 or FF02:0:0:0:0:0:0:16 and (2) the secure group that an EU requests to join.

Q multicasts the first multicast GSAM_PUSH message into group 224.0.0.22 or FF02:0:0:0:0:0:0:16. In this message, the KEK_GSA that is just distributed to an EU using GSAM_AUTH exchange is specified in the payloads of SA and KD.

Q creates a new SA pair, called GSAM_TEK_SA, which consists of two GSAs: (1) GSA_q whose direction is from Q to the secure group that an EU (the new GM) requests to join and (2) GSA_r whose direction is from an EU to the secure group that an EU requests to join. The values of important parameter of SPI in GSA_q and GSA_r are suggested ones since they are assigned by Q with no negotiation with other GMs.

After making sure that all the NQs have received the previous GSAM_PUSH message, Q starts to multicast the other GSAM_PUSH message into the group that the EU has requested to join. In the second message, the payloads SA and KD specify the parameter and key material of the new SA pair (GSAM_TEK_SA).

After that, Q starts two timers, called q-timer and r-timer respectively. When q-timer / r-timer expires, Q will update its local SAD [RFC5374] according to GSA_q / GSA_r. The initial value of q-timer should be large enough to make sure all GMs have updated their local SADs according to the distributed GSA_q.

There must be an interval between the first GSAM_PUSH message and the second one. The interval should be large enough to make sure the first message has been received by GMs in 224.0.0.22 or FF02:0:0:0:0:0:0:16 before the second one is sent.

If the registered EU is not the first GM of a secure group, Q multicasts the second GSAM_PUSH message directly without the first message.

When an NQ is registered as a GM in all the groups, Q will directly multicast GSAM_PUSH exchange message in the group of 224.0.0.22 for IPv4 system or FF02:0:0:0:0:0:0:16 for IPv6 system. In this message, GSAM_TEK_GSAs for all the groups are specified in the payloads SA and KD. If the only group Q is maintaining is the super group, no GSAM_PUSH exchange is needed.

Upon receiving the first message of GSAM_RE_DISTRIBUTION, Q verifies the value in the payload AUTH to authenticate a GM. If authentication fails, Q discards the received message directly. Otherwise, Q deletes the q_timer and r_timer if they exist. It multicasts the second message of GSAM_RE_DISTRIBUTION to negotiate SPI values with all the GMs in the secure group.

Upon receiving the third message, Q verifies the AUTH payload to authenticate a GM. If authentication fails, Q discards the received message directly. Otherwise, Q searches its local SGT and looks for a record that is indexed by a secure group identified in the received IDg. The GMS of the found record contains the addresses of all the GMs in the secure group. Q compares the source addresses of the received third messages with the values in the GMS until it has received the third message from all the GMs in the secure group.

After that, Q starts to calculate a list, called spi_list_all, which is a union of spi_lists received from all GMs in the secure group. Then Q resets the values of SPI in GSAM_TEK_SA. The new SPI values must not be in the spi_list_all to effectively avoid SPI collisions at any GM. Then Q multicasts the fourth message of GSAM_RE_DISTRIBUTION, whose payloads SA and KD specify the revised GSAM_TEK_SA. Finally, Q re-starts q-timer and r-timer. When q-timer / r-timer expires, Q updates its local SAD according to GSA_q / GSA_r whose SPI value has been negotiated among GMs.

5.3. GM Operations

Upon receiving the GSAM_PUSH message, a GM verifies the value in the payload AUTH to authenticate Q. If authentication fails, a GM discards the received message directly. Otherwise, a GM parses the received payloads SA and KD. If payloads SA and KD specify KEK_GSAs and a GM is an NQ, a GM will accept the KEK_GSA directly and wait for receiving the following GSAM_PUSH message protected by KEK_GSA. Otherwise payloads SA and KD specify a GSAM_TEK_SA. In this case, a GM checks SPI, an important parameter of GSAM_TEK_SA. If SPI values in GSAM_TEK_SA have not used in its local SAD, a GM will start q-timer and r-timer and no other exchange is needed. When q-timer/ r-timer expires, a GM updates its local SAD according to GSA_q / GSA_r. If the source address of received GSA_r is the same as a local address, the initial value of r-timer should be large enough to make sure all other GMs and Q have updated their local SADs according to GSA_r. If the suggested SPI values in GSAM_TEK_SA have collided with the used SPI values in local SAD, a GM must start GSAM_RE_DISTRIBUTION exchange as follows.

A GM calculates a MAC and encapsulates it in AUTH payload. Then it sends the first message of GSAM_RE_DISTRIBUTION to Q to show its rejection.

Upon receiving the second message in GSAM_RE_DISTRIBUTION, a GM verifies the received AUTH payload. If the verification fails, a GM discards the received message. Otherwise, a GM deletes the pending q-timer and r-timer at once if they exist. It accesses its local SAD to obtain the all the used SPI values in the SAD and saves them in an spi_list. After that, the status of local SADB is set as "read_only" to prevent any modification from any other processes. The GM encapsulates an spi_list in the payload SPI_LIST. Moreover, a MAC value is calculated and encapsulated in the AUTH payload. After that, the GM sends the third message with the payload SPI_LIST and AUTH payload.

Upon receiving the fourth message in GSAM_RE_DISTRIBUTION, the GM verifies the value in the payload AUTH to authenticate Q. If authentication fails, the GM discards the received message directly. Otherwise, the GM is forced to accept GSAM_TEK_SA specified in the received payload SA and KD. It re-starts q-timer and r-timer. When q-timer/r-timer expires, a GM updates its local SAD according to GSA_q/GSA_r. After that, GMs clears the "read_only" status of its local SAD to permit the modification to the SAD from other processes.

6. Handover of Q

Although ERs are usually stable, a new ER may be added into the network and an old ER may fail to work. In these cases, a querier election is caused and then a new Q may be elected in the link. The new Q will take over the work of old Q automatically and become GCKS soon in the link. All the EUs and NQs will discover the new Q since they will receive the general query sent by the new Q in SIGMP/SMLD. They initiate new GSAM sessions with the new Q. If they are authenticated successfully, the new Q will distribute new GSAM_TEK_SAs to them. SIGMP / SMLD messages will be protected by the new GSAM_TEK_SAs.

7. IANA Considerations

GSAM runs over UDP. A UDP port should be assigned to GSAM.

8. References

8.1. Normative References

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

8.2. Informative References

[I-D.atwood-pim-sigmp]	william.atwood@concordia.ca, w. and B. Li, "Secure Internet Group Management Protocol", Internet-Draft draft-atwood-pim-sigmp-01, July 2014.
[I-D.yeung-g-ikev2]	Rowles, S., Yeung, A., Tran, P. and Y. Nir, "Group Key Management using IKEv2", Internet-Draft draft-yeung-g-ikev2-07, November 2013.
[RFC4301]	Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC5191]	Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H. and A. Yegin, "Protocol for Carrying Authentication for Network Access (PANA)", RFC 5191, May 2008.
[RFC5374]	Weis, B., Gross, G. and D. Ignjatic, "Multicast Extensions to the Security Architecture for the Internet Protocol", RFC 5374, November 2008.
[RFC5996]	Kaufman, C., Hoffman, P., Nir, Y. and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010.
[RFC6407]	Weis, B., Rowles, S. and T. Hardjono, "The Group Domain of Interpretation", RFC 6407, October 2011.

Authors' Addresses