Subject: [Mip6] comments on draft-ietf-mip6-ikev2-ipsec-02.txt

From: Francis Dupont <[email-masked]>
Date: Tue, 02 Aug 2005 14:47:18 +0200

4.3 API already exists, cf draft-sugimoto-mip6-pfkey-migrate-00.txt

5.1 & others: please, PLEASE, use the abstract syntax of SPD/SAD!
I consider these sections as not readable until this is done...

6.2: I don't understand why IDi is mandatory: it is not optional at all
in IKEv2 specs. Proposal: remove the MUST, i.e., change the requirement
in a fact!
 BTW, when the home address is used the check against the peer address
(which is the care-of address) has to be disabled. This is discussed
in a pki4ipsec document, I propose to reference it in order to explain
how to deal with the fact the peer address is not the commonly expected one.
 The text about the CREATE_CHILD_SA for RR protection is not clear enough:
there is always one initiator. Usually it is the MN but it can be the HA
when a CN which is mobile begins an RR. This must be explained in order
to avoid "passive" configurations on HAs (note this should only break RR
from outside, so this is not a critical misconfig).
 Last paragraph is ambiguous because it applies only when the whole stuff
is restarted... As in IKEv2 SAs are managed, i.e., IPsec SAs are deleted
when the IKE_SA goes down, I don't believe it is a real case. Perhaps
it applies to previous context and in this case the paragraph should be moved?

6.3: an important detail is forbidden: SPD entries have to be updated
when an endpoint/peer address is changed. In fact, this is even more
critical than to update the SAD entries!

7: we should check but I believe the CERT from the responder/HA is not
optional with EAP authentication, i.e., preshared secret is an alternative
to the standard certificate-based mutual authentication, EAP is an option
of the second. Further text in the I-D seems to say the same thing...
Perhaps we have to choose between IKEv2 ([4]) and EAP/IKEv2 I-D ([8])?
BTW I don't know if there is a real consensus about the second, and
if it could be heavily changed.

[14]: the -01 was published (after this I-D :-)

Regards

[email-masked]

PS: the beginning of the message for people who lost it:
The last two requirements of section 4.2 are confusing because they
are not required by this I-D but by RFC 3775. I propose to add
the references.

I am still strongly against the first 4.3 requirements. In fact today
many security gateways don't support protocol (so ports) in traffic selectors
(because this solves the issue of fragment handling, cf the OPAQUE stuff
in 2401bis). I.e., fine gain selectors are fine but should be made
mandatory, so please downgrade to a SHOULD.

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

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 25 Aug 2005 17:48:59 -0700

> 4.3 API already exists, cf draft-sugimoto-mip6-pfkey-migrate-00.txt

true. but I cant add a normative dependency to this draft.

> in IKEv2 specs. Proposal: remove the MUST, i.e., change the requirement

done.

> how to deal with the fact the peer address is not the commonly expected one.

can you please suggest some text here?

> from outside, so this is not a critical misconfig).

fixed. the new text

    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.  The
    CREATE_CHILD_SA exchanges are protected by the security association
    created during the IKE_AUTH exchange.  If a correspondent node that
    is also a mobile node, initiates the return routability exchange,
    then the Home Agent initiates the CREATE_CHILD_SA exchange to
    negotiate security associations for protecting Return Routabilty
    messages.

> it applies to previous context and in this case the paragraph should be moved?

which paragraph is this? the last paragraph in section 6.2 talks
PKI based authentication.

> Perhaps we have to choose between IKEv2 ([4]) and EAP/IKEv2 I-D ([8])?

well, [8] has no status currently and we may have to remove it.
currently I have it as an optional mechanism, with a informational
reference :). I am open to suggestions.

Vijay

---

From: Francis Dupont <[email-masked]>
Date: Sat, 27 Aug 2005 16:43:05 +0200

In your previous mail you wrote:

   
=> an API is always informational so I don't understand the issue
(PS: the 01 version of this I-D is nearly ready).

   
=> First I quote the pki4ipsec I-D because the issue is a bit complex:

   In addition, implementations MUST be capable of verifying that the
   address contained in the ID is the same as the peer source address,
   contained in the outer most IP header.  If ID is one of the IP
   address types, then implementations MUST perform this verification by
   default.  If this default is enabled, then a mismatch MUST be treated
   as an error and security association setup MUST be aborted.  This
   event SHOULD be auditable.  Implementations MAY provide a
   configuration option to (i.e. local policy configuration can enable)
   skip that verification step, but that option MUST be off by default.
   We include the "option-to-skip-validation" in order to permit better
   interoperability, as today implementations vary greatly in how they
   behave on the topic of verification of source IP.

   If the default for both the verifications above are enabled, then, by
   transitive property, the implementation will also be verifying that
   the peer source IP address matches via a bitwise comparison the
   contents of the iPAddress field in the SubjectAltName extension in
   the certificate.  In addition, implementations MAY allow
   administrators to configure a local policy that explicitly requires
   that the peer source IP address match via a bitwise comparison the
   contents of the iPAddress field in the SubjectAltName extension in
   the certificate.  Implementations SHOULD allow administrators to
   configure a local policy that skips this validation check.

The first part of both is about the cert stuff. IMHO we should simply
reuse the last paragraph of (quoting again the pki4ipsec I-D):

   Implementations MAY use the IP address found in the header of packets
   received from the peer to lookup the policy, but such implementations
   MUST still perform verification of the ID payload.  Although packet
   IP addresses are inherently untrustworthy and must therefore be
   independently verified, it is often useful to use the apparent IP
   address of the peer to locate a general class of policies that will
   be used until the mandatory identity-based policy lookup can be
   performed.

   For instance, if the IP address of the peer is unrecognized, a VPN
   gateway device might load a general "road warrior" policy that
   specifies a particular CA that is trusted to issue certificates which
   contain a valid rfc822Name which can be used by that implementation
   to perform authorization based on access control lists (ACLs) after
   the peer's certificate has been validated.  The rfc822Name can then
   be used to determine the policy that provides specific authorization
   to access resources (such as IP addresses, ports, and so forth).

So if we specialize a bit the text for mobility clients...
The points are:
 - recognized the case as special (i.e., not default)
 - disable the check between the peer address and the ID/cert
 - base the policy on the ID

   > it applies to previous context and in this case the paragraph
   
   which paragraph is this?

=> argh, I can't find it...

Thanks

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 29 Aug 2005 19:11:43 -0700

> (PS: the 01 version of this I-D is nearly ready).

you are right. added a reference to it.

>  - disable the check between the peer address and the ID/cert

how about the following text?

    If the mobile node had used its home address in the IDi field,
    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 careof address and the IP
    address in the IDi field is the home address.  Therefore, this
    verification step should be skipped

>  - base the policy on the ID

we already have some text on this.

    When PKI based authentication is used between the mobile and the Home
    Agent, the identity presented by the mobile node in the IDi payload
    must correspond to the identity in the certificate obtained by the
    Home Agent.  The Home Agent uses the identity presented in the IDi
    payload to lookup the policy and the certificate that corresponds to
    the mobile node.

isn't that sufficient?

Vijay