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

[Francis Dupont <[e-mail]>]

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

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

   >  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 :-).

   >  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)
etc.

   
   >  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 ?! :-).
   
   >    ...  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...

   >  In 6.1.2 page 13 and 6.1.4 page 15:
   > 
   >                        outer src addr = coa,
   >                        outer dst addr = coa,
   > 
   > => s/coa/[primary_]care-of_address_1/
   
   see my comment above about primary CoA
   
=> at least the abbrev coa is bad and not sound with the context.

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

   >    ...  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.
So the right strict policy is enforced in the examples.
Now why it is a bad idea:
 - it takes time to establish a second SA pair
 - the HA has to find the right IKE SA (if it fails, it will create
   a new IKE session to an unknown CoA). This can't be done using
   the usual way based on the peer address.

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

   > => s/fetched/got back/ ? My concern is the term "fetch" doesn't match the
   > case where the certificate is sent in a CERT payload.
   
   how about "obtained"?
   
=> fine!

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

   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.
   
   >  In 12 pages 21 and 22: I believe some authors have in fact only the
   > editor role, this should be reflected.
   > 
   >  In 12.2 page 22:
   > 
   >    [14]  Sugimoto, S., "PF_KEY Extension as an Interface between Mobile
   >          IPv6 and IPsec/IKE", draft-sugimoto-mip6-pfkey-migrate-01 (work
   >          in progress), September 2005.
   > 
   > => me and Masahide Nakamura are co-authors.
   
   I am using xml2rfc. looks like the bibxml files list only
   one author. should the bibxml files be fixed?
   
=> argh! It seems it is the case but it can be hard to do it in time.

Thanks

[e-mail]

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