Re: MOBIKE WG Agenda for IETF-64, take 1

--- Francis Dupont <[email protected]>
wrote:

>  In your previous mail you wrote:
> 
>    > => MIPv6 BU protection and SCTP have an
>    > authorization issue
>    > (remember the zillion of messages in the mip WG
>    > mailing list
>    > about this). The address management provided my
>    > MOBIKE
>    > is a clean and simple solution to this issue.
>    > So MOBIKE is not needed but simplifies the
> world.
>    > (you should reread the draft, even you are one
> of
>    > the few
>    > persons I know they have read it :-).
> 
>    In the case of MIP6 it might make sense because
>    MN-HA MUST use IPsec to protect BUs and MOBIKE
>    provides the RR check for the CoA.
> 
> => hum, it seems we are in complete
> misunderstanding...
>
hmm.. i am not sure whether there were zillions of
mail
on this case :-)

> In MIPv6 the MN-HA IKE is run over the CoA but the
> IPsec SA
> pair in transport mode must be established with the
> HoA.
> So IKE has to check if the MN has the authorization
> to use
> this particular HoA. In place to have a dedicated
> code for MIPv6
> in IKE I simply propose to use the MOBIKE framework
> to add the
> HoA as an additional address and to check (not using
> RR please :-)
> if it is authorized.
> 
So, the authorization still happens the same way as
defined in RFC 3776.  It is just that you are using
a different mechanism to convey the home address i.e
instead of ID/Traffic selectors i.e you are using
MOBIKE mechanism. Am i understanding this right ? 

>    But SCTP has to
>    solve the authorization issue anyway because you
>    may not use IPsec with SCTP always.
>    
> => I am talking about authorization of additional
> peer addresses
> in IKE/IPsec.
> 
>    > => not in the IKEv2 framework (i.e., NAT-T
> support
>    > for transport mode is an extension).
 
> 
>    But should be less of an issue with "IP-IP"
>    transport mode like tunnels i guess.
> 
> => yes, the IP-IP transport mode is clearly a
> special case.
> (there is a comment by Joe Touch about this in issue
> #7)
>    
>    Issue 7 is about transport mode. You have to
> reopen
>    it for your draft too :-)
>    
> => the issue #7 question is a bit ambiguous but as
> it is from
> a comment of mine, the real issue is about peer
> address change
> for transport mode SAs (so not addressed by my
> draft)
> So can we agree that to reopen the issue #7 is to
> look at
> if/how to update transport mode SAs?
> 
At least that was my understanding :-)

> BTW my opinion is the complexity is too high and the
> current
> solution (reestablish SAs with new addresses) is
> enough
> in the general case.
>    
I am not sure i agree on why this is more complex.

-mohan

> Regards
> 
> [email protected]
> 
> PS: for the tunnel special case (the traffic is
> selected by it is
> in the tunnel, i.e., a particular interface and
> protocol) we have
> two choices:
>  - write a specific document
>  - add it in the transport document (I can provide
> the current
>    version in xml2rfc to a co-author who shall write
> the text).
>