CN-4-11 - Generation of nonces
Host
HA----------R2----------R1----------R0
| | | |
| | | |
|---- |---- |----MN |----CN(NUT)
| | | |
| | | |
Home Link Link2 Link1 Link0
(Foreign) (Foreign)
Link0 3ffe:501:ffff:100::/64 Link1 3ffe:501:ffff:101::/64 Foreign Link Link2 3ffe:501:ffff:102::/64 Foreign Link 2 Home Link 3ffe:501:ffff:104::/64 Home Link CN(NUT) 3ffe:501:ffff:100::X
Auto Configuration (InterfaceID)MN(in Link1) 3ffe:501:ffff:101::Y
Increased in each test (InterfaceID)MN care-of address MN(in Home Link) 3ffe:501:ffff:104::Y
Increased in each test (InterfaceID)MN home address R0(Link0) 3ffe:501:ffff:100::1 R1(Link1) 3ffe:501:ffff:101::1 R2(Link2) 3ffe:501:ffff:102::1 HA(Home Link) 3ffe:501:ffff:104::1
Reboot NUT (reboot.rmt)
MN R1 HA R0 CN(NUT)
| | | | |
| | | |------>| 1.RA
| | | | |
| | | |------>| 2.NS
| | | | |
| | | |<------| 3.NA
| | | | |
|-------------->|-------------->| 4.Echo Request
| | | | |
|<--------------|<--------------| 5.Echo Reply
| | | | |
|------------------------------>| 6.Echo Request(Home Address option)
| | | | |
|<------------------------------| 7.BE(Status=1)
| | | | |
|------------------------------>| 8.CoTI
| | | | |
|<------------------------------| 9.CoT
| | | | |
|------------------------------>| 10.CoTI
| | | | |
|<------------------------------| 11.CoT (*1)
| | | | |
| | | | | Repeat 10. and 11. until receiving different index (Max 240s)
| | | | |
|-------------->|-------------->| 12.HoTI
| | | | |
|<--------------|<--------------| 13.HoT
| | | | |
|-------------->|-------------->| 14.HoTI
| | | | |
|<--------------|<--------------| 15.HoT (*2)
| | | | |
| | | | | Repeat 14. and 15. until receiving different index (Max 240s)
| | | | |
1. Send Router Advertisement. 2. Send Neighbor Solicitation. 3. Receive Neighbor Advertisement. 4. Send ICMP Echo Request. 5. Receive ICMP Echo Reply. 6. Send ICMP Echo Request(Home Address option). 7. Receive Binding Error(Status=1). 8. Send Care-of Test Init. 9. Receive Care-of Test. 10. Send Care-of Test Init. 11. Receive Care-of Test(different index from 9). *Repeat 10. and 11. until receiving different index (Max 240s) 12. Send Home Test Init. 13. Receive Home Test. 14. Send Home Test Init. 15. Receive Home Test(different index from 13). *Repeat 14. and 15. until receiving different index (Max 240s)
Packet Format 10. Care-of Test Init 11. Care-of Test 14. Home Test Init 15. Home Test
(*1) MN receives Care-of Test. - The Care-of Nonce Index is different from the value of the first Care-of Test.
(*2) MN receives Home Test. - The Home Nonce Index is different from the value of the first Home Test.
(draft-ietf-mobileip-ipv6-24.txt)
5.2.2 Nonces
Each nonce is identified by a nonce index. When a new nonce is generated, it must be associated with a new nonce index; this may be done, for example, by incrementing the value of the previous nonce index, if the nonce index is used as an array pointer into a linear array of nonces. However, there is no requirement that nonces be stored that way, or that the values of subsequent nonce indices have any particular relationship to each other. The index value is communicated in the protocol, so that if a nonce is replaced by new nonce during the run of a protocol, the correspondent node can distinguish messages that should be checked against the old nonce from messages that should be checked against the new nonce. Strictly speaking, indices are not necessary in the authentication, but allow the correspondent node to efficiently find the nonce value that it used in creating a keygen token.
5.2.7 Updating Node Keys and Nonces
Correspondent nodes generate nonces at regular intervals. It is recommended to keep each nonce (identified by a nonce index) acceptable for at least MAX_TOKEN_LIFETIME seconds (see Section 12) after it has been first used in constructing a return routability message response. However, the correspondent node MUST NOT accept nonces beyond MAX_NONCE_LIFETIME seconds (see Section 12) after the first use. As the difference between these two constants is 30 seconds, a convenient way to enforce the above lifetimes is to generate a new nonce every 30 seconds. The node can then continue to accept tokens that have been based on the last 8 (MAX_NONCE_LIFETIME / 30) nonces. This results in tokens being acceptable MAX_TOKEN_LIFETIME to MAX_NONCE_LIFETIME seconds after they have been sent to the mobile node, depending on whether the token was sent at the beginning or end of the first 30 second period. Note that the correspondent node may also attempt to generate new nonces on demand, or only if the old nonces have been used. This is possible, as long as the correspondent node keeps track of how long a time ago the nonces were used for the first time, and does not generate new nonces on every return routability request.