Re: [Mip6] comments about draft-ietf-mip6-ikev2-ipsec-03.txt

Francis Dupont wrote:

>    >    >  In 5.4 page 11 I can't see a trace of the protocol=MH option...
>    >    
>    >    5.4 is about payload traffic. that means protocol = 'any'.
>    >    
>    > => so perhaps we should add a subsection here to explain how to do
>    > the protocol=MH option (which is easier than the "any" because it is
>    > not equivalent to a transport mode applied to a tunnel). Note I have
>    > the same concern about 6.1.4 (where currently proto = X ?! :-).
>    
>    I made a mistake in my earlier mail. it shouldnt have been 'any'.
>    it should have been 'X', which 'X' stands for a particular
>    protocol. perhaps thats enough?
>    
> => the word any was overloaded in RFC 3776 section 3.4, in fact there are
> 3 cases:
>  - X is really an any protocol
>  - X is MH
>  - X stands for all protocols (i.e., 'any')
> This has to be solved in the introduction as the DB entries look similar.

I could add a sentence saying by payload we mean all
traffic excluding MIPv6 signaling messages.

>    >    >  In 6.3 page 18:
>    >    > 
>    >    >    ... on the mobile node
>    >    >    when it receives the Binding acknowledgement sent by the home agent.
>    >    > 
>    >    > => I discussed this with Shinta-san and the endpoint update is performed
>    >    > by the mobile node after it sends the BU, i.e., the MN doesn't wait for
>    >    > the BA. Cf draft-sugimoto-mip6-pfkey-migrate-01.txt 4.1.2 page 7.
>    >    
>    >    I dont mind making the change, but do you think the mobile node
>    >    can start using the new CoA for tunneled packets before it is
>    >    sure the BU has been processed by the HA?
>    >    
>    > => usually it can't use the old CoA... and we can be optimistic.
>    > Note the HA should not check the outer source address (cf RFC 2401(bis))
>    > so if the BU fails the issue will be for returned traffic (CN->HA->MN).
>    
>    I went back and looked at the text. it talks about the IKE SA.
>    data traffic wont be sent over the IKE SA. I guess there is
>    no urgent need to update the IKE SA?
>    
> => The discussion with Shinta-san was about the SPD and SAD update
> but the IKE SA can be updated in fact at the same time. The only
> thing to wait for the BAck gives is the K flag from the HA so
> if the MN but not the HA support the K stuff the IKE SA is not
> updated then reestablished... IMHO this doesn't matter and we
> have clearly a case of overspecification. I can see two ways
> to solve this:
>  - remove the "and on the mobile node"
>  - add in the "and on the mobile node" the alternative.
> I believe the second is a bit better so the text should be:
> 
>    If the mobile node moves and its care-of address changes, the IKEv2
>    SA might not be valid, unless the mobility extensions defined in [13]
>    are implemented by both the mobile node and the home agent.  RFC 3775
>    defines a mechanism based on the successful exchange of Binding
>    Update and Binding Acknowledgement messages.  The IKE SA endpoints
>    are updated on the home agent when it receives the Binding Update
>    from the mobile node's new care-of address and on the mobile node
>    when it sends the Binding Update to the home agent or when it receives
>    the Binding Acknowledgement sent by the home agent.
>    This capability to change IKE endpoints is indicated through setting
>    the Key Management Capability (K) flag [2] in the Binding Update and
>    Binding Acknowledgement messages.  If the mobile node or the home
>    agent does not support this capability, then an IKEv2 exchange MUST
>    be initiated to re-establish the IKE SA.
> 
> (PS: note the uppercase in Acknowledgement)

okay.

Vijay

_______________________________________________
Mip6 mailing list
Mip6@ietf.org
https://www1.ietf.org/mailman/listinfo/mip6