-------------------- Mohan Parthasarathy (2005-10-03): - Section 4.5 - What is the use of "NO_ADDITIONAL_ADDRESS" notification ? At least i did not see any description/hint of how one would use it. - What is the use in adding NO_NATS_ALLOWED along with ADDITIONAL_ADDRESS notification ? The receiver of ADDITIONAL_ADDRESS takes it from the notification payload and not from the IP header. Is it just that you want to include NO_NATS_ALLOWED with all possible notifications ? But section 4.8 allows only with IKE_SA_INIT and UPDATE_SA _ADDRESS and ADDITIONAL_ADDRESS. In the IKE_SA_INIT and UPDATE_SA, you take from the IP header and hence it makes sense. Why do we need it for ADDITIONAL_ADDRESS ? - The VPN gateway may have a single address but the client may have multiple addresses. In that case it is okay if it does not send ADDITIONAL_ADDRESS notification but it needs to process one from the client. The last paragraph states something different. -------------------- Jari Arkko (2005-10-03): Missing text, I think. Section 4.5 or 5.3 should include something along the following lines: The ADDITIONAL_*_ADDRESS notification MUST be used when there's more than one address to be communicated to the peer. The NO_ADDITIONAL_ADDRESSES notification MUST be used when there is only one address, and the peer was previously informed of multiple addresses. As a result, NO_ADDITIONAL_ADDRESSES notification is not needed in the initial IKEv2 exchange, and the ADDITIONAL_*_ADDRESSES notification is needed in the the initial exchange only if there is more than one address. I can't answer this. Pasi? Agreed, this is an issue. I think we wanted to say that clients that do not intend to use more than one address do not have to send ADDITIONAL_*_ADDRESS notifications. But they still need to be able to handle them. This is a part of the basic mobike protocol that devices supporting this rfc-to-be should support. -------------------- Pasi Eronen (2005-10-03): https://www.machshav.com/pipermail/mobike/2005-October/001092.html This is already described in Section 5.3, but I agree, the text perhaps needs some clarification.. Because just like in the IKE_SA_INIT case, the notifications contain addresses _in_addition_ to the one used in the IP header. So we need NO_NATS_ALLOWED to protect the one in the IP header. (We could change it so that all the addresses were in ADDITIONAL_*_ADDRESS notifications, but this way it's more uniform treatment IKE_SA_INIT vs. INFORMATIONAL, and NAT-T vs. NAT prohibition.) The text actually says that "a simple "VPN gateway" that has only a single address, and is not going to change it, does not need to send or understand ADDITIONAL_*_ADDRESS notifications. This is correct: the responder in this case does not have to understand ADDITIONAL_*_ADDRESS notifications because the only time it would use the information is when its own address changes. Or in other words, even if it did understand them, it would not make any difference since the information would not be used for anything. -------------------- Jari Arkko (2005-10-03): https://www.machshav.com/pipermail/mobike/2005-October/001093.html >This is already described in Section 5.3, but I agree, the text >perhaps needs some clarification.. > > Ok. Use your judgment to edit this in. But I think the current text on this point is vague. >Because just like in the IKE_SA_INIT case, the notifications >contain addresses _in_addition_ to the one used in the IP header. >So we need NO_NATS_ALLOWED to protect the one in the IP header. > > Hmm. Is that address used for something, beyond responding to the request? >The text actually says that > > "a simple "VPN gateway" that has only a single address, and is > not going to change it, does not need to send or understand > ADDITIONAL_*_ADDRESS notifications. > >This is correct: the responder in this case does not have to >understand ADDITIONAL_*_ADDRESS notifications because the only time >it would use the information is when its own address changes. Or >in other words, even if it did understand them, it would not make >any difference since the information would not be used for anything > > Ok. Now I understand. But you still had the other part in the text that said: A minimal "mobile client" could have a policy that says that only the responder's address specified in local configuration is acceptable. I can see that such a policy is possible. But I'm not sure I see the same initiator-decides effect here than was present in the gateway side. Since the client is responsible for address selection in both, it seems that a client that does not implement gateway ADDITIONAL_*_ADDRESS payloads does not implement the full protocol. We can of course choose what our mandatory-to-implement requirements are. Does the text above mean that a minimal mobile client can choose not to implement this part of the protocol, or only that its legal to configure it so that expects a single address from the other side? I'd rather see the latter... -------------------- Mohan Parthasarathy (2005-10-03): https://www.machshav.com/pipermail/mobike/2005-October/001096.html > This is already described in Section 5.3, but I agree, the text > perhaps needs some clarification.. So, if i informed the peer about 5 addresses, and two of my addresses became invalid, what do i do then ? Why is returning to one valid address case special ? > Because just like in the IKE_SA_INIT case, the notifications > contain addresses _in_addition_ to the one used in the IP header. > So we need NO_NATS_ALLOWED to protect the one in the IP header. > Then, i should be able to use NO_NATS_ALLOWED in any message to protect the IP header. Sorry, i still can't understand. > The text actually says that > > "a simple "VPN gateway" that has only a single address, and is > not going to change it, does not need to send or understand > ADDITIONAL_*_ADDRESS notifications. > > This is correct: the responder in this case does not have to > understand ADDITIONAL_*_ADDRESS notifications because the only time > it would use the information is when its own address changes. Or > in other words, even if it did understand them, it would not make > any difference since the information would not be used for anything. Hmm.. but it can still change the peer's address given in the ADDITIONAL_ADDRESS. I understand that it does not have to change. But if the client has multiple addresses and there is some connectivity problem, it can try a different address, right ? -------------------- Tero Kivinen (2005-10-28): https://www.machshav.com/pipermail/mobike/2005-October/001234.html There are some changes still missing from the 05 for this. The beginning of the 3.6 would need to be changed, i.e. change ---------------------------------------------------------------------- As described in Section 3.4, both the initiator and responder can send a list of additional addresses in the IKE_AUTH exchange. This information can be updated by sending an INFORMATIONAL exchange request message that contains either one or more ADDITIONAL_IP4/ 6_ADDRESS notifications or the NO_ADDITIONAL_ADDRESSES notification. The message exchange will look as follows: ---------------------------------------------------------------------- to ---------------------------------------------------------------------- As described in Section 3.4, both the initiator and responder can send a list of additional addresses in the IKE_AUTH exchange. This information can be updated by sending an INFORMATIONAL exchange request message that contains either one or more ADDITIONAL_IP4/ 6_ADDRESS notifications or the NO_ADDITIONAL_ADDRESSES notification. The NO_ADDITIONAL_ADDRESSES notify is used to indicate that there are no additional addresses besides the address used in the IP-headers. The ADDITIONAL_IP4/6_ADDRESS are used to give complete list of additional addresses (in addition to the one in the IP-header). The new address list will completely overwrite the previous list. The message exchange will look as follows: ---------------------------------------------------------------------- -------------------- Mohan Parthasarathy (2005-10-28): https://www.machshav.com/pipermail/mobike/2005-October/001244.html Why does one have to indicate that they have NO_ADDITIONAL_ADDRESSES ? If i don't send ADDITIONAL_IP* notification then you just have one address to operate with. What is the use of explicitly indicating this ? Also, ADDITIONAL_IP with zero address can do the same i guess i.e ADDITIONAL_IP* replaces the previous list with zero or more addresses. -------------------- Tero Kivinen (2005-10-31): Ok, lets add explination about that too: The NO_ADDITIONAL_ADDRESSES notify is needed, as otherwise it would not be possible to distinguish empty DPD message from address update message that does not have any additional addresses. Now we can distinguish them, as DPD is empty INFORMATIONAL exchange and address update with no extra addresses is INFORMATIONAL exchange having only N(NO_ADDITIONAL_ADDRESSES). Both of them can have other additional payloads like N(COOKIE2) etc. -------------------- Mohan Parthasarathy (2005-11-01): https://www.machshav.com/pipermail/mobike/2005-November/001247.html Hmm...part of the problem is that NO_ADDITIONAL_ADDRESS is really DELETE_ADDITIONAL_ADDRESS. But we don't want to use the word DELETE because we provide only replace semantics. It may sound trivial, but what exact action (delete the addresses contained in the previous ADD_ADDITIONAL_IP*) needs to be performed is not explained anywhere (not in 05). The defintion in 4.3 contains : The NO_ADDITIONAL_ADDRESSES notification can be included in an INFORMATIONAL exchange request message to indicate that the exchange initiator does not have addresses beyond the one used in the exchange (see Section 3.6 for more detailed description). Section 3.6 only contains "update the peer addresses ...". Perhaps the definition should be appended with.. "The exchange initiator sends this notification to delete the addresses sent in the earlier ADD_ADDITIONAL_ADDRESS notification". -------------------- Pasi Eronen (2005-11-07): https://www.machshav.com/pipermail/mobike/2005-November/001277.html The draft does not have an ADD_ADDITIONAL_ADDRESS notification; the new list always replaces the old information. But here's a yet another attempt to rewrite the beginning of Section 3.6: As described in Section 3.4, both the initiator and responder can send a list of additional addresses in the IKE_AUTH exchange. This information can be updated by sending an INFORMATIONAL exchange request message that contains either one or more ADDITIONAL_IP4/ 6_ADDRESS notifications or the NO_ADDITIONAL_ADDRESSES notification. If the exchange initiator has only a single IP address, it is placed in the IP header, and the message contains the NO_ADDITIONAL_ADDRESSES notification. If the exchange initiator has several addresses, one of them is placed in the IP header, and the rest in ADDITIONAL_IP4/6_ADDRESS notifications. The new list of addresses replaces the old information (in other words, there are no separate add/delete operations; instead, the complete list is sent every time these notifications are used). Does this look better? (BTW, it seems issue 58 is essentially a duplicate of this one) -------------------- Mohan Parthasarathy (2005-11-07): https://www.machshav.com/pipermail/mobike/2005-November/001281.html If there is only one address, why do you need to explicitly tell your peer that you have NO_ADDITIONAL_ADDRESS ? Isn't NO_ADDITIONAL_ADDRESS needed only when oyu have sent ADDITIONAL_ADDRESS previously ? Please see my comments above. I think the only time we send NO_ADDITIONAL_ADDRESS is when you have sent ADDITIONAL_IP before. Otherwise, i don't know why we need one. -------------------- Tero Kivinen (2005-11-07): https://www.machshav.com/pipermail/mobike/2005-November/001283.html If you do not include it then then you are not updating address list of the other end. See my previous email to the list, i.e. would adding follogin text help: ---------------------------------------------------------------------- The NO_ADDITIONAL_ADDRESSES notify is needed, as otherwise it would not be possible to distinguish empty DPD message from address update message that does not have any additional addresses. Now we can distinguish them, as DPD is empty INFORMATIONAL exchange and address update with no extra addresses is INFORMATIONAL exchange having only N(NO_ADDITIONAL_ADDRESSES). Both of them can have other additional payloads like N(COOKIE2) etc. -------------------- Pasi Eronen (2005-11-08): https://www.machshav.com/pipermail/mobike/2005-November/001284.html Tero already answered this, but here's another take: we update the address list only if the request contains either NO_ADDITIONAL_ADDRESS or ADDITIONAL_*_ADDRESS. Otherwise, we would have to include the whole address list in every single IKEv2 request, even when the list has not changed. -------------------- Mohan Parthasarathy (2005-11-08): https://www.machshav.com/pipermail/mobike/2005-November/001285.html Ok, face to face exchange clarified this. You send NO_ADDITIONAL_ADDRESS whenever you are left with just one address and that address appears in the IP header. ADDITIONAL_ADDRESS is sent only when you have more than one address. Perhaps, i am the only one so confused :-) --------------------