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

From: Francis Dupont <[email-masked]>
Date: Sun, 09 Oct 2005 23:57:18 +0200

I'd still like to get an annex with the ASN.1 version of section 6 SPD
entries... But I have some other comments:

 In 3 page 3:
   The mobile node and the home agent must support the packet formats as

=> s/must/MUST/

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

      configuration of home address as described in Section 8.  When the
      home agent receives a configuration payload with a CFG_REQUEST for
      INTERNAL_IP6_ADDR, it must reply with a valid home address for the
      mobile node.  The home agent could pick a home address from a

=> s/could/can/ ?

      local database or from a DHCPv6 server on the home link.

 In 4.3 page 7:

   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/ ?

 In 4.4 page 8 and at many other places:

   o  The mobile node MUST use its Care-of Address as source address in
      protocol exchanges, when using dynamic keying.

=> s/Care-of Address/care-of address/

   o  If the mobile node has used IKEv2 to establish security
      associations with its home agent, it should follow the procedures
      discussed in Section 11.7.1 and 11.7.3 of the base specification
      [2] to determine whether the IKE endpoints can be moved or if IKE
      SA has to be re-established.

=> s/if IKE SA/if the IKE SA/ ?

   o  If the home agent has used IKEv2 to establish security
      associations with the mobile node, it should follow the procedures
      discussed in Section 10.3.1 and 10.3.2 of the base specification
      [2] to determine whether the IKE endpoints can be moved or if IKE
      SA has to be re-established.

=> s/if IKE SA/if the IKE SA/ ?

 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.

 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.

 In 5.4 page 11 I can't see a trace of the protocol=MH option...

 In 6.1 page 12 I propose to split the paragraph the same way than in
section 5 and to add something about the care-of address.

   The home agent should have named SPD entries per mobile node, based
   on the identity of the mobile node.  The identity of the mobile node
   is stored in the "Name" selector in the SPD [5].  The Home Address
   presented by the mobile node during the IKE negotiation is stored as
   the Remote IP address in the resultant IPsec security associations.
   The home agent MAY also have generic SPD entries to prevent mobility
   header traffic that requires IPsec protection from bypassing the
   IPsec filters.

=> s/Home Address/home address/ , s/Remote/remote/

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

 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/

 In 6.1.3 page 14:

   In the examples shown above, the home address of the mobile node
   might not be available all the time.  When the mobile node acquires a
   new home address, it must add the address to the corresponding SPD
   entries.

   The TSi and TSr payloads in the above examples will contain many
   other selectors apart from home_address_1.  For brevity, they are not
   show here.

=> IMHO a reference to 6.1.1 is far better.

 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

and

         - IF destination = home_address_1 & proto = X &
              source = CN

=> this doesn't make any sense.

 In 6.2 page 15:

   The mobile node initiates an IKEv2 protocol exchange if the required
   security associations are not present.  The default mechanism used
   for mutual authentication is a shared secret between the mobile node
   and the home agent.  The home agent uses the identity of the mobile
   node to identify the corresponding shared secret.  If public key
   based mechanism is available, it should be the preferred mechanism
   for mutual authentication.  The home agent and the mobile node should
   use their private keys to generate the AUTH payload, when a public
   key based mechanism is used.  The mobile node and the home agent
   should use CERTREQ and CERT payloads if the identities need to be
   verified.  If the mobile node is configured with the home agent
   information including the public key that corresponds to the home
   agent, then the mobile node MAY exclude the CERTREQ payload in
   message 3.  Similarly, the home agent MAY exclude the CERTREQ payload
   in message 2, if it is configured with the mobile node information.

=> this paragraph is pretty bad. Here I try another text:

   The mobile node initiates an IKEv2 protocol exchange if the required
   security associations are not present.  A possible mechanism used
   for mutual authentication is a shared secret between the mobile node
   and the home agent.  The home agent uses the identity of the mobile
   node to identify the corresponding shared secret.  When a public key
   based mechanism is available, it should be the preferred mechanism
   for mutual authentication: private keys are used to generate the AUTH
   payload and identities are verified with certificate informations
   transmitted by CERT payloads or configured. If the mobile node is
   configured with the home agent information including its certificate,
   then the mobile node MAY exclude the CERTREQ payload in its IKE_AUTH
   third message.  Similarly, the home agent MAY exclude the CERTREQ payload
   in its IS_SA_INIT second message, if it is configured with the mobile node
   information.

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

   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.

   ...  If a correspondent node that
   is also a mobile node, initiates the return routability exchange,

=>

   ...  If a correspondent node, that
   is also a mobile node, initiates a return routability exchange,

   When PKI based authentication is used between the mobile node and the
   Home Agent, the identity presented by the mobile node in the IDi
   payload must correspond to the identity in the certificate fetched by
   the Home Agent.

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

   If the mobile node had used its home address in the IDi field,

=> s/If/When/ s/had used/uses/

   implementations are required to match the source address in the outer
   most IP header with the IP address in the IDi field [9].  This
   verification step, however, should be configurable [9].  With Mobile
   IPv6, this verification step will always fail because the source
   address in the outer most IP header is the care-of address and the IP

=> s/outer most// (this is about IKE messages which have no reason to
be encapsulated)

   address in the IDi field is the home address.  Therefore, this
   verification step should be skipped.

=> s/should be skipped/must be disabled/ (MUST?)

 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.

   be initiated to re-establish the IKE SA.

=> s/the/a new/ ?

 In 7 page 19: I don't think it is a good idea to rely on [8].

 In 9 page 20:

   ...  The home agent MAY store the
   assigned home address in the SPD entries created for the mobile node.

=> I'd like to know how this can work if it doesn't store it (:-).

   The use of EAP for authenticating the mobile node to the home agent
   is described in Section 7.  This document recommends that if the EAP

=> "recommends" seems a bit strong.

   method used, supports mutual authentication, then EAP itself be used

=> syntax...

   for authenticating the home agent to the mobile node also.  This runs
   contrary to the recommendation in [4].

=> my concern is that I prefer the recommendation in [4]... and I can't
see why this recommendation should be bad here. Perhaps this is again
the wrong idea a mobile can't perform public key computations? I strongly
suggest to put this EAP extension consideration into another document
(a bootstrapping one for instance).

 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.

Regards

[email-masked]

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

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 18 Oct 2005 08:11:25 -0700

hi Francis,

thanks for the second review.

>  - coarse granularity: any protocol (here).

ok. but did you want to see some text. or?

> => s/optional/when possible/ ?

its optional because the binding updates have a sequence
number which provides replay protection.

> from time to time and it makes the code for tracking and updating SPD/SAD

I dont think I understand. are you saying the MN should
use its primary CoA and not any CoA? what if the monami6
WG extends MIPv6 registrations to include multiple CoAs?
I would like to support that with just one SA.

> so there are twice the right number of SPD-S entries. I propose to copy

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?

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

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

> => s/coa/[primary_]care-of_address_1/

see my comment above about primary CoA

>          - IF source = home_address_1 & destination = any & proto = any

how do you distinguish between payload traffic sent to the HA
and to the CN?

>    in its IS_SA_INIT second message, if it is configured with the mobile node

okay. here is the modified text.

    The mobile node initiates an IKEv2 protocol exchange if the required
    security associations are not present.  A possible mechanism used for
    mutual authentication is a shared secret between the mobile node and
    the home agent.  The home agent uses the identity of the mobile node
    to identify the corresponding shared secret.  When a public key based
    mechanism is available, it should be the preferred mechanism for
    mutual authentication: private keys are used to generate the AUTH
    payload and identities are verified with certificate information
    transmitted by CERT payloads.  If the mobile node is configured with
    the home agent information including the public key that corresponds
    to the home agent, then the mobile node MAY exclude the CERTREQ
    payload in its IKE_AUTH third message.  Similarly, the home agent MAY
    exclude the CERTREQ payload in its IKE_SA_INIT second message if it
    is configured with the mobile node information.

> => s/MAY/SHOULD/ because I believe it is a very bad idea to have two

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.

>    optionally payload traffic, and Mobile Prefix Discovery messages.

whats the difference?

> case where the certificate is sent in a CERT payload.

how about "obtained"?

> => s/should be skipped/must be disabled/ (MUST?)

changed it to "MUST be disabled".

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

> (a bootstrapping one for instance).

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.

> => 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?

Vijay

---

From: Francis Dupont <[email-masked]>
Date: Fri, 21 Oct 2005 10:48:42 +0200

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

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

   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

=> this will be the job of the monami6 WG to produce the proper guidelines.

=> I agree (I even suggested this with the multiple MR document as you'll
be able to see when it will be published :-).

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

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

   
=> so you can see how to make the text clearer...

   
=> at least the abbrev coa is bad and not sound with the context.

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

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

   whats the difference?
   
=> X and Y and Z != (X or Z) and Y...
RR (X) and payload (Z) are alternatives.

   how about "obtained"?
   
=> fine!

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

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

   
=> argh! It seems it is the case but it can be hard to do it in time.

Thanks

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 21 Oct 2005 05:15:44 -0700

> we recommend a subset of possible profiles).

can you suggest some text here?

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

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

>            Then use SA SA1 (OUT) and SA2 (IN)

okay

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

> => 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 tunnel mode for inner protocol, proto = 41 in transport mode for outer

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

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

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

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

> to the current IKEv2/2401bis and not rely on still in discussion extensions.

lets see what the IESG says about this.

Vijay

---

From: Francis Dupont <[email-masked]>
Date: Fri, 21 Oct 2005 18:37:01 +0200

=> I'll do a second pass ASAP...

   
=> two messages... not so a long time! The BU sequence number is *not*
an anti-replay feature at all. Please trust me.

   
=> to mess the any CoA/primary CoA issue won't help monami6 WG at all:
this can change the choice between the primary CoA and the extra CoA
in a choice between a CoA in the whole set of possible CoA, so anything
based on addresses will fail from time to time.
I insist!

   
=> no, X and 'any' are not equivalent. And here the selection must include
the HoT/HoTI MH type (so proto must include MH, i.e., X=MH or 'any').

   how about
   
       The TSi and
   
=> good (so the idea is now cleary that unbounded sharing is allowed).

   how about the following?
   
           mobile node SPD-S:
   
           home agent SPD-S:
   
=> better. I still don't understand the X, prefer expanded coa abbrev
and have a proposal for the transport mode over tunnel.

   
=> there was no real objection but I agree this interpretation is not
yet in the documents (but here I believe we can forward without waiting
for a new 2401bis).
About the one SA pair, IMHO the main benefit of the fine grain selectors
is they make possible to put the IKE daemon on the HA is the "passive"
mode, i.e., it is never an initiator. This was not true (and is still not
true with coarse grain selectors) before because of the MN-MN case.

   
=> argh! I can see where we disagree: I assume than payload means
all payloads. I have not the time now but we should get the original
text to see who is right... Of course the other TSx stuff applies here.

   
=> a dangerous way to solve our problems... (:-).

Thanks

---

From: Francis Dupont <[email-masked]>
Date: Sat, 22 Oct 2005 12:13:44 +0200

=> as the issue is a bit complex and is related to 5.4 and 6.1.4 I'll try
to propose a complete text in another message.

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

   >    >    Prefix Discovery messages and optionally payload traffic.

=> I withdraw my proposal.

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

Thanks

---

From: Vijay Devarapalli <[email-masked]>
Date: Sun, 23 Oct 2005 20:52:44 -0700

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

> (PS: note the uppercase in Acknowledgement)

okay.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Sun, 23 Oct 2005 21:15:30 -0700

> text to see who is right... Of course the other TSx stuff applies here.

right. I now see why we were disagreeing. payload means
regular traffic. not IPsec payload. for IPsec everything
that is protected by IPsec becomes payload for IPsec.

Vijay

---

From: Francis Dupont <[email-masked]>
Date: Mon, 24 Oct 2005 08:58:47 +0200

=> this is solved by my section about granularity (where either the 'any'
payload DB entries cover MIPv6 or there are specific prioritary DB entries
for MIPv6 (which is the proper way to implement all traffic excluding MIPv6)).

Thanks

PS: all the points should be closed.