Re: Issue 46: Questions about additional addresses (was: Comments on draft-ietf-mobike-protocol-03.txt)

[email protected] wrote:

>>>- 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. 
>>>      
>>>
>>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.
>>    
>>
>
>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.

>>>      - 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 ?
>>>      
>>>
>>I can't answer this. Pasi?
>>    
>>
>
>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 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.
>>>      
>>>
>>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.
>>    
>>
>
>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...

--Jari