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

[Vijay Devarapalli <[e-mail]>]

Francis Dupont wrote:
>  In your previous mail you wrote:
> 
>    >  In 4.1 page 4:
>    > 
>    >    o  ESP encapsulation of the payload packets tunneled between the
>    >       mobile node and the home agent MAY be supported and used.
>    > 
>    > => I believe the document should restrict choices to only three options:
>    >  - fine granularity: selector on MH types
>    >  - medium granularity/RFC 3776 compatibility: selector on protocol = MH
>    >  - coarse granularity: any protocol (here).
>    
>    ok. but did you want to see some text. or?
>    
> => yes, I believe it is important to have some text because readers
> should both understand they have some choices (note some are needed
> for compatibility with current implementations, for instance coarse
> grain only selectors for forwarded traffic) but not too many (i.e.,
> we recommend a subset of possible profiles).

can you suggest some text here?

>    > 
>    >    o  When securing Binding Updates, Binding Acknowledgements, and
>    >       prefix discovery, both the mobile nodes and the home agents MUST
>    >       support and SHOULD use the Encapsulating Security Payload (ESP)
>    >       [6] header in transport mode and MUST use a non-null payload
>    >       authentication algorithm to provide data origin authentication,
>    >       connectionless integrity and optional anti-replay protection.
>    > 
>    > => s/optional/when possible/ ?
>    
>    its optional because the binding updates have a sequence
>    number which provides replay protection.
>    
> => no, this sequence number provides sequencing but no replay protection
> as it can round up. I strongly disagree here: the IPsec anti-replay
> protection is necessary and it was not made mandatory only because it
> is not always possible. So I maintain my proposal.

from what I remember, it was made optional because there is
replay protection through BU sequence number. so I have to
disagree. its a 32 bit sequence number. takes a long time
to wrap around.


>    >  In 5 page 8:
>    > 
>    >    This section describes the SPD and SAD entries that can be used to
>    > 
>    > => I propose to add something explaining here and in section 6 that
>    > the care-of address is the primary care-of address. BTW this is required
>    > from time to time and it makes the code for tracking and updating SPD/SAD
>    > far easier to write.
>    
>    I dont think I understand. are you saying the MN should
>    use its primary CoA and not any CoA?
> 
> => yes, IMHO the level for using the primary CoA in place of any CoA
> is in some cases MUST and in all cases at least a SHOULD. The RFC 3775
> is a bit lax about this (it uses "the CoA" for instance) but here I propose
> to be clear.
> 
>    what if the monami6
>    WG extends MIPv6 registrations to include multiple CoAs?
> 
> => this will be the job of the monami6 WG to produce the proper guidelines.
> 
>    I would like to support that with just one SA.
>    
> => I agree (I even suggested this with the multiple MR document as you'll
> be able to see when it will be published :-).

I prefer the looser text so that others can extend it to
support multiple CoAs. otherwise monami6 WG has to
specifically say "RFC 3775 says blah blah.. but.. but we
have to relax the blah blah.. requirement".

> 
>    >  In 5.1, 5.2 and 5.3 pages 9, 10 and 11: SPD-S entries work both ways
>    > so there are twice the right number of SPD-S entries. I propose to copy
>    > the section 6 stuff.
>    
>    not if we want to enforce the case where only the MN sends
>    BU and not BAck to the HA and the HA sends BAck only. right?
>    
> => no, the section 6 does this so there is no reason to have twice
> entries in 5.x. As I explain later one good SPD-S entry does the
> right job in both direction without mixing MH types.
> I propose to change:
>         mobile node SPD-S:
>           - IF source = home_address_1 & destination = home_agent_1 &
>                proto = MH & mh_type = BU
>             Then use SA SA1
> 
>           - IF source = home_agent_1 & destination = home_address_1 &
>                proto = MH & mh_type = BAck
>             Then use SA SA2
> 
> into:
>       mobile node SPD-S:
>          - IF source = home_address_1 & destination = home_agent_1 &
>               proto = MH & local_mh_type = BU & remote_mh_type = BAck
>            Then use SA SA1 (OUT) and SA2 (IN)

okay


>    >  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 TSi and
>    >    TSr payloads in the above examples will contain many other selectors
>    >    apart from home_address_1.  For the sake of brevity, they are not
>    >    shown here.
>    > 
>    > => this statement is fully not understandable for me. I don't believe
>    > the idea is to share SAs. Can you explain or remove this?
>    
>    I am just saying that we are not showing the TSi or TSr
>    payload completely in the example configurations. only
>    those values that are relevant for MIPv6.
>    
> => so you can see how to make the text clearer...

how about

    The TSi and
    TSr payloads in the above examples will contain many other selectors
    apart from home_address_1.  For the sake of brevity, we show only
    those values that relevant for Mobile IPv6.

>    >  In 6.1.4 page 15:
>    > 
>    >        mobile node SPD-S:
>    >          - IF interface = IPv6 tunnel to home_agent_1 & proto = X
>    > 
>    > => this is fully wrong. The SPD-S entry is really similar to the 6.1.2,
>    > i.e., should be:
>    > 
>    >        mobile node SPD-S:
>    >          - IF source = home_address_1 & destination = any & proto = any
>    >          etc
>    
>    how do you distinguish between payload traffic sent to the HA
>    and to the CN?
>    
> => so in fact you propose the interface in place of not in the BCE?
> IMHO this is correct as it is fully equivalent but:
>  - SPD-S entries are symmetrical so there is only one for MN and one for the HA
>  - proto is any, not X
>  - the second SPD-S entry for the MN should have the same layout than others
>    (in fact it is the same than the first one as it should be only one entry)
>  - s/coa/.../ as usual
>  - we can say one can use a transport mode over the tunnel as it will give
>    exactly the same layout for packets and the same selection (proto = any
>    in tunnel mode for inner protocol, proto = 41 in transport mode for outer
>    protocol).

how about the following?

        mobile node SPD-S:
          - IF interface = IPv6 tunnel to home_agent_1 & proto = X
            Then use SA ESP tunnel mode
                            IDi = user_1, IDr = home_agent_1,
                            TSi = home_address_1, X, port
                            TSr = any, X, port
                            outer src addr = coa
                            outer dst addr = home_agent_1,
                            inner src addr = home_address_1

        home agent SPD-S:
          - IF interface = IPv6 tunnel to home_address_1 & proto = X
            Then use SA ESP tunnel mode
                            IDi = home_agent_1, IDr = user_1,
                            TSi = any, X, port
                            TSr = home_address_1, X, port
                            outer src addr = home_agent_1,
                            outer dst addr = coa,
                            inner dst addr = home_address_1

> 
>    >    ...  The mobile node
>    >    MAY use a range of selectors that includes the mobility message types
>    >    for Binding Update and Binding Acknowledgement to use the same pair
>    >    of IPsec security association for both messages.
>    > 
>    > => s/MAY/SHOULD/ because I believe it is a very bad idea to have two
>    > SA pairs.
>    
>    why is it a bad idea? without that we cant enforce a policy where
>    we want the HA to send a BAck, but not a BU.
>    
> => you missed the discussion about the selectors for MH:
> remote_mh_type=BAck on the MN means the HA can only send BAck.

hmm... I followed the discussion on the IPsec mailing list.
it seemed like not everybody agreed.

>    >    After the IKE_AUTH exchange completes, the mobile node initiates
>    >    CREATE_CHILD_SA exchanges to negotiate additional security
>    >    associations for protecting Return Routability signaling, Mobile
>    >    Prefix Discovery messages and optionally payload traffic.
>    > 
>    > => I propose:
>    > 
>    >    After the IKE_AUTH exchange completes, the mobile node initiates
>    >    CREATE_CHILD_SA exchanges to negotiate additional security
>    >    associations for protecting Return Routability signaling or
>    >    optionally payload traffic, and Mobile Prefix Discovery messages.
>    
>    whats the difference?
>    
> => X and Y and Z != (X or Z) and Y...
> RR (X) and payload (Z) are alternatives.

the current requirements say the MN must create security
associations to protect RR and MPD messages. payload is
optional. this assumes the payload does not include
RR 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?

> 
>    there are many EAP methods that support mutual authentication.
>    when such EAP methods are used, I dont think the mobile node
>    needs to use public key mechanism to authenticate the home
>    agent.
>    
> => IMHO this discussion is not at the right place: it is not a MIPv6
> issue but an IPsec issue. So my concern is we should restrict ourselves
> to the current IKEv2/2401bis and not rely on still in discussion extensions.

lets see what the IESG says about this.

Vijay


_______________________________________________
Mip6 mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/mip6