Re: about draft-ietf-mobike-protocol-01.txt (issue 40)

Francis Dupont writes:
>    > - in 2.3 the SPD entries have to be updated too or expired SAs
>    > will be renewed with wrong addresses.
>    
>    I'll add a clarification about this (where exactly the
>    addressses have to be updated depends a lot on the
>    implementation; e.g. the VPN client I have on my PC treats the
>    IPsec tunnel as a virtual interface, and stores some of the
>    information RFC 2401 would call "SPD" in what the implementation
>    calls "routing table").
>    
> => IMHO there is no choice here: the formal description is in 2401bis
> and we have to use it even when we know the implementations have only
> to provide the same behavior and can use very different structures.

The 2401bis describes one way of implementing IPsec, it is not the
only way to do it. It itself says:

   "The model described below is nominal; implementations need not
   match details of this model as presented, but the external behavior
   of implementations MUST correspond to the externally observable
   characteristics of this model in order to be compliant."

Also the mobike extends some aspects of IPsec in way that they cannot
be expressed as rfc2401bis PAD/SPD/SAD model (i.e dynamic updating of
the PAD, SPD, SAD etc databases for example), thus implementations
supporting 2401bis and mobike need to make extensions to the
PAD/SPD/SAD. Thus Pasi's clarifications of the what possible tables or
databases needs to be updated in when the addresses are changed should
be in this document, and it does not need to be restricted in the
2401bis language and model. It should include the 2401bis model too
when applicable, but it can also provide other implementaqtion
instructions. 

>    > - another limitation of 2.3 is it cannot update selectively a
>    > subset of SAs: again a case only is handled!
>    
>    Yes, and this is intentional (there was rough consensus in issue
>    8 to do it this way -- if you want to update a subset of SAs,
>    you need to have several IKE_SAs).
>    
> => the problem is if the intention is not to support multihoming
> (and it seems there is a rough consensus about this :-) the charter
> must be updated. Or we'll get IESG comments or even an appeal
> about the document and its lack of support for anything else
> than mobility.

We do support multihoming, we do not support simultaneous use of
multiple addresses (as it would be load balacing that was explictly
forbidden by the charter). We do allow traffic to move from one
interface to the another (that is not mobility, it is multihoming).
-- 
[email protected]