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

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


> > >       - 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.
> 
Then, i should be able to use NO_NATS_ALLOWED in any message
to protect the IP header. Sorry, i still can't understand.

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

-mohan


-mohan

> Best regards,
> Pasi
> _______________________________________________
> Mobike mailing list
> [email protected]
> https://www.machshav.com/mailman/listinfo.cgi/mobike