Subject: [mobile-ip] Re: Question about draft-ietf-mobileip-mipv6-ha-ipsec-02 (pre).txt

From: Jari Arkko <[email-masked]>
Date: Sun, 19 Jan 2003 23:49:41 +0200

Bernard,

Thanks for your very useful comments. I'm sending the reply
to the list so others can see the discussion as well.

> I was reading through this, and find the draft very helpful. However, I
> have some questions :)
> 
> Section 5.2, Step 2:
> 
> In the case where the MN has just moved and is attempting to update the HA
> with its new binding, it sends the BU as specified in Section 5.1.
> 
> However on receiving the BU packet, it would seem to me that the HA would
> be unable to process the Home Address Option, in Step 2, because there is no
> binding cache entry linking the CoA to the HoA, since the MN has just
> moved. That Binding Cache entry will not exist until after Step 5. Or is
> the Binding Cache entry not checked for IPsec packets, since it is assumed
> that ESP processing will catch forgeries?

Good question. The base specification states in

   http://www.piuha.net/~jarkko/publications/mipv6/drafts/mobilev6.html#rxing-hao

   "These tests MUST NOT be done for packets that contain a Binding
    Update and a Home Address option."

that Binding Updates are exempt from the rule which requires the
existence of a BCE before HAO can be accepted. However, the rule
doesn't talk about the case where IPsec hide what kind of packet
is inside.

I'd like to modify the exemption so that it applies to both cleartext
Binding Updates as well as encrypted Binding Updates... and this
requires the stack to remember that it needs to check this after
decryption. Can someone verify that this is OK? Interestingly, a
couple of revs ago we had a feature which allowed any IPsec
packet to use HAO.

Anyway, here's the suggested text: "These tests MUST NOT be done
for packets that contain a Home Address option and a Binding
Update (either in cleartext or inside IPsec encapsulation)."

> Section 5.17, Step 1
> 
> Here the ID_FQDN payload is used, presumably with IKEv1 Aggressive Mode,
> so that the HA can map the ID payload to a key and authenticate the Phase
> 1 SA. Note that the infamous group pre-shared key problem with
> dynamically assigned addresses in MM is apparently fixed in IKEv2, so
> perhaps "IKE" should be "IKEv1" within the draft so this is clear.

I have added a statement to this effect in the beginning of the
draft and in section 3.4. Overall, I'd like to use IKEv2 but the
way things are going, it could still be a while...

> For phase 2, the IDci contains the HoA. RFC 2409, Section 5.5 states:
> 
>    If ISAKMP is acting
>    as a client negotiator on behalf of another party, the identities of
>    the parties MUST be passed as IDci and then IDcr.  Local policy will
>    dictate whether the proposals are acceptable for the identities
>    specified.
> 
> So there is an implicit assumption that "local policy" exists which allows
> the HA to determine whether the IDci in Phase 2 is allowable, given the
> IDci in Phase 1; in otherwords, a mapping between the ID_FQDN and the HoA.
> Is this right?

Yes.

> If so, then perhaps some text might be appropriate stating
> how this mapping is maintained and the security requirements for it. For
> example, it would not be ok for the HA to allow any IDci to correspond to
> an Initiator authenticated with a given ID_FQDN. Might the mapping be
> maintained in DNS (statically or dynamically) and securely verified via
> DNSSEC or DNS TSIG?

Indeed. Yes, this needs to be documented. This text already exists
in section 3.4:

    "When dynamic keying is used, the security policy database
     entries MUST unequivocally identify the IKE phase 1
     credentials which can be used to create security
     associations for a particular home address."

I think this covers the part about "allow any IDci". I'm somewhat
unsure how much further I should go. Secure DNS might be nice way
of doing it. There's probably some other ways too, maybe something
around AAA, probably IPsec policy distribution could be used too.
For the moment I'll add the following explanations:

    "This mapping may be maintained, for instance, as a locally
     administered table in the home agent. If the phase 1 identity
     is a FQDN, secure forms of DNS may also be used."

Question: is there a particular form of secure DNS that exists
as an RFC, is known to work, and would be suitable for this
purpose? If yes, I could add the text. If no, I'd like to leave
that as a subject for a future extension draft.

> Step 4
> 
> "Nevertheless, where the problem appears, the preferred solution is to
> replace the firewalls or routers with equipment that can properly support
> fragments."
> 
> Filtering fragments successfully in both directions is very hard on an
> intermediate box, since it requires the router/fw to reassemble the fragments
> prior to being able to apply the access list. Reassembly buffers must be
> allocated, and this typically implies slow path processing if it can be
> done at all. Do you know of any routers that can do this in fast path?

As you can see, this is modelled a bit like what you did in IP Storage,
but I cut down the list of other options.

I'm not sure I care if these packets go through the fast path or not,
but I agree that getting proper support can be problematic. Let me
change s/the preferred/one/. I think the out of band cert installation
in this particular scenario should be relatively straightforward.

(By the way, given that this particular problem seems to be one
of the key issues when discussing e.g. TLS vs. IPsec choice for
many protocols, why haven't IKEv2 folks done anything to it? As
far as I know, transport is still UDP. Or have they invented other
way to transport certs?)

> Section 5.19, step 9
> 
> Assuming that the MN can send its BU to the HA as described in Section
> 5.2 and have it processed correctly, then the HA will now have a binding
> cache entry linking the new CoA to the HoA, correct?

Yes.

> If so, then why can't the MN subsequently include a Home Address Option
> within the IKE packets it sends to the HA? This could allow the MN to set
> up an IKE phase 1 SA from the HoA to the HA, no?
> 
> I guess what I am asking is whether the following steps could work:
> 
> a. IKE phase 1 and 2 setup, using CoA as the MN address in source and
> dest.
> b. IPsec protected BU exchange between MN and HA.
> c. IKE phase 1 and 2 setup, using CoA as the MN address in source and
> dest., but including a Home Address Option.
> 
> This sequence yields Phase 1 and Phase 2 SAs that do not need to be moved.

Interesting idea. Sound very appealing -- the only drawback that I
can find at the moment is that the start up requires two runs of IKE
instead of one. But that's when the mobile node starts up, not on
every movement.

(I'll skip this new scheme for drafts 20 & 02, however, unless I hear
otherwise...)

Jari

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 19 Jan 2003 14:16:53 -0800 (PST)

> doesn't talk about the case where IPsec hide what kind of packet

The rule makes sense to me in this specific case, because the packet is
authenticated and integrity protected with IPsec, and the MH is covered.
So if the HAO is forged, it will be detected when the hashes are checked
(AH would detect IP header forgery; AH or ESP would detect that the BU
fields didn't match the IP headers, right?)

However, I am not sure this is right if the BU and HAO are not integrity
protected. For example, if and when we allow "piggybacked" BUs, one could
imagine IKEv? initiation occurring with a piggybacked BU and HAO. Unless
the IKE hash was to cover the BU and HAO, a forgery would not be
detectable.

> decryption.

For optimized operation, it's usually preferrable to allow each step to
occur based on the data available at the time. MH processing occurs prior
to IPsec processing, typically. So the BU and HoA would not be visible
when the processing was done.

> Can someone verify that this is OK? Interestingly, a

What was the reason that the feature was removed? Since IPsec ESP/AH will
check the hashes on reception, an IPsec exception wouldn't
create any security problems, would it? On the face, it seems like a
cleaner way of dealing with this issue.

> way things are going, it could still be a while...

Sure. But it probably makes sense to state the requirements in a way that
they can be applied to IKEv2 if and when it is done. So rather than saying
"MUST use Aggressive Mode" you might say "SHOULD NOT use IKEv1 MM with
pre-shared keys, since this forces use of group pre-shared keys when the
CoA is dynamically assigned." That would leave room for use of
either IKEv1 AM or IKEv2 MM which doesn't have that problem.

> that as a subject for a future extension draft.

Since the HA and home domain DNS server can be assumed to have a trust
relationship, DNS TSIG (RFC 2845) might make sense. This can be used to
secure dynamic update as well as other DNS queries.

> in this particular scenario should be relatively straightforward.

Yes, that's a good change. I'm sorry to say that IKEv2 is not yet paying
enough attention to this problem. The joke is that "IKEv1 is a security
protocol with no truly functional authentication modes."

The fragmentation issues has come up in several cert deployments I've been
involved with. People start out with a desire for short cert chains, but
hierarchy is often needed for administrative flexibility -- as are
additional cert OIDs. So the cert payloads tend to grow as things
progress from initial testing to full scale deployment.
Once the packets go over the MTU size, IKEv1 stops working. Ouch.

As with the IKE MM group pre-shared key problem, about all we can do
is put in text to make people aware, and pray that it is fixed in IKEv2 :)

> far as I know, transport is still UDP. Or have they invented other

It occurs to me that perhaps some of the WGs should get together and
present some "feedback" to IPsec WG on this and other issues. TCP is not a
great option for IKE because of the additional vulnerabilities that it
would introduce (forged RST, sequence space attacks, etc.), although we
did decide to support it in PIC (which used the ISAKMP packet format), to
avoid the cert fragementation problem. But I do agree that IKEv2 should
attempt to solve the problem.

> instead of one. But that's when the mobile node starts up, not on

Right. After an IKE Phase 1 SA is set up from the HoA, then after that,
only an IPsec protected BU exchange is needed between MN and HA. By the
rule we discussed earlier, this can be sourced from the CoA with a HAO.

> (I'll skip this new scheme for drafts 20 & 02, however, unless I hear

Some more thinking about the implications of this and other approaches
probably is required.

---

From: Jari Arkko <[email-masked]>
Date: Mon, 20 Jan 2003 09:42:21 +0200

Yes.

> the IKE hash was to cover the BU and HAO, a forgery would not be

I agree, but I think we already do require that a non-null integrity
algorithm is used.

> cleaner way of dealing with this issue.

We used for enabling an additioanal mode of communication with
the correspondent nodes. However, the draft lacked details on
how to do it on the sender side, and we eventually dropped it.
But I think the home agent communications are different, and
we already have explicit rules that show how to construct the
home agent binding updates. I'll change the text to say that
the tests are not done for IPsec packets (and we're still
not specifying how mobile nodes would take advantage of this
when communicating with correspondent nodes).

> either IKEv1 AM or IKEv2 MM which doesn't have that problem.

Done.

> secure dynamic update as well as other DNS queries.

Ok, I added a reference to that.

> did decide to support it in PIC (which used the ISAKMP packet format), to

I see.

> attempt to solve the problem.

Good idea about the feedback to the IPsec WG.

Jari

---

From: Francis Dupont <[email-masked]>
Date: Mon, 20 Jan 2003 11:10:33 +0100

> that ESP processing will catch forgeries?
   
=> IPsec processing will catch forgeries.

   
   
=> as BUs must be protected by IPsec this is not useful.

   that Binding Updates are exempt from the rule which requires the
   existence of a BCE before HAO can be accepted.

=> no, a verification is required and the BCE check is only one way
to provide the verification.

   However, the rule doesn't talk about the case where IPsec hide what
   kind of packet is inside.
   
=> so the verification should be done when the upper layer header is
reached.

=> you should put the IPsec verification back, and not for any IPsec
packet but only for IPsec packets which include a proof of the identity
of the MN (this is the common case but not the only case).

Please stop to go backward. If the next MIpv6 draft has no provision
for an IPsec world, I'll object at the last call.

   
   Yes.
   
=> I proposed for IKEv2 a new wording with the term authorization for
the "local policy". This (aka the "proxy mode" should be clearer and
more supported).

   
=> the term authorization should be present, for instance:

       "When dynamic keying is used, the security policy database
        entries MUST unequivocally identify the IKE phase 1
        credentials which can be used to authorize the
        creation of security associations for a particular home address."

=> yes, this is an IPsec policy stuff and this is out of the scope
of this WG.

   

=> RFC 2535 but it is currently revised (it is not deployable),
so IMHO we should not enter into this level of details.

=> IMHO this WG should avoid to spread its scope to the whole IETF (:-).

=> the key issue of TLS vs. IPsec is TLS over TLS can be easily attacked
below the TLS level, for instance by the TCP reset attack, and UDP over
TLS is not available. So for a good security IPsec is the only solution...

   > up an IKE phase 1 SA from the HoA to the HA, no?

=> it could but this is not useful! Note this is true only for the HA.

   > This sequence yields Phase 1 and Phase 2 SAs that do not need to be moved.
   
=> but this second IKE SA can be used only for the BU/BA SAs...
An IKE SA is still needed for the tunnel SAs and it must be run with
the CoA address, so the only win (?) is to get two IKE SAs.

=> with IKEv1 the IPsec SAs are not flushed when the IKE SA is deleted
(so there is a lot of hairy issues about dead peer detection). The simple
solution is to put a very long lifetime to the BU/BA SAs so they can
be used across a lot of movements...

Regards

[email-masked]

---

From: Jari Arkko <[email-masked]>
Date: Mon, 20 Jan 2003 12:24:03 +0200

> => as BUs must be protected by IPsec this is not useful.

Not all of them. Remember correspondent nodes. Anyway, I
would think the latest text that I sent in the next e-mail
to Bernard is better, or? If you have a suggestion about
the text that we should use for "only for IPsec packets
which include a proof of the identity" please send it...

>         creation of security associations for a particular home address."

Done, thanks.

> => IMHO this WG should avoid to spread its scope to the whole IETF (:-).

Yes, so that's why I now explicitly say that its outside the
scope of this specification to discuss what methods are used
to do this authorization, though I point out a few examples.
Ok?

Jari

---

From: Francis Dupont <[email-masked]>
Date: Mon, 20 Jan 2003 11:35:51 +0100

=> "authenticated" here includes a proof of the identity of the MN
(if the packet is forged by another node, this node doesn't know the
shared secret between the MN and the HA.) and a verification way of the HAO
(If the MN puts a forged address in the HAO, the selector check will fail).
Note this relies on a proper setup of SAs.

=> the HAO doesn't need to be protected. But the Home Address needs
protection so or the HAO is protected (AH), or the HoA is repeated in
the (always protected) BU.

=> the problem of piggybacked BUs is in IPsec selectors.

=> the IKE hash doesn't cover something outside the IKE payload.
In this case as the IKE messages are *never* protected by IPsec
(they use the special "bypass" policy), the piggybacked BU is not
protected and must be ignored.

   > couple of revs ago we had a feature which allowed any IPsec
   
   What was the reason that the feature was removed?

=> I can't answer and stay polite!

   Since IPsec ESP/AH will
   
=> and to deal with an IPsec world (i.e., a world where IPsec protection
is available between two random nodes).

=> no, DNS TSIG is for transaction protection. What is needed here is
a data protection, i.e., a verificable SIG for the RRset which encodes
the binding between the IKE phase 1 identity of the MN and its HoA,
an AAAA RR for instance.

=> this is a thread about "revised identity" but it is not yet included
in the IKEv2 draft.

Regards

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 20 Jan 2003 04:59:16 -0800 (PST)

> I agree, but I think we already do require that a non-null integrity

OK.

> when communicating with correspondent nodes).

Yes. We're talking about the MN-HA BU here.

> > either IKEv1 AM or IKEv2 MM which doesn't have that problem.

OK.

> Good idea about the feedback to the IPsec WG.

Perhaps we should ask for some time on the IPsec WG agenda at IETF 56?

What is interesting is that quite a few of the issues in MIPv6 are being
encountered elsewhere (such as in the IPS security work), although I'm
sure there are some unique ones as well. IKEv2 is proceeding without a
requirements document, and under a very tight deadline (its supposed to be
done in February), so that time is running out.

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 20 Jan 2003 05:25:20 -0800 (PST)

> the binding between the IKE phase 1 identity of the MN and its HoA,

I would agree if the MN and HA are in different administrative domains.
If the MN and HA are in the same administrative domain, then an
HA query for the RR (A/AAAA) binding the MN FQDN to the HoA could be
all be within that same administrative domain -- in fact, the HA could be
configured to send DNS queries to the DNS server authoritative for the
binding. In this situation there are still attacks that could be launched
(e.g. on the .COM RRs), but the transactions are protected and there is
only one hop to a trusted server.

> => this is a thread about "revised identity" but it is not yet included

Any chance it will get in?

---

From: Francis Dupont <[email-masked]>
Date: Mon, 20 Jan 2003 15:54:47 +0100

=> IMHO the "it is so local than no attack is possible" argument is
a bit weak when the data themselves can be intrinsically secured.

=> so why to use TSIG (:-)?

   
=> there is no objection but this is a major change and the target is to
get concensus for the current draft before adding missing parts (legacy
authentication for instance).

Regards

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 20 Jan 2003 06:52:14 -0800 (PST)

> a bit weak when the data themselves can be intrinsically secured.

Sure. An approach such as DNSSEC would definitely be preferred if it is
available.

> => so why to use TSIG (:-)?

You don't have to. IPsec protection would also work in that case.

Note that the main reason why these things are worth mentioning is that
if they aren't referenced, we're likely to see a lot of "interesting"
proposals for solving these problems later on.

---

From: Bernard Aboba <[email-masked]>
Date: Sat, 25 Jan 2003 04:48:42 -0800 (PST)

> the CoA address, so the only win (?) is to get two IKE SAs.

Why couldn't the IKE exchange used to set up the tunnel SAs also contain
an HAO, if a binding cache entry exists? After all, if the MN were at
home, the source address on these (and other IKE packets) would be the
HoA.

> be used across a lot of movements...

What is the usefulness of this if new IKE SAs have to be brought up on
each move?

---

From: Francis Dupont <[email-masked]>
Date: Sat, 25 Jan 2003 16:26:39 +0100

=> no because the tunnel SAs are built with the peer addresses (aka
the addresses IKE runs over) and the MN address should be the care-of.
If we ask the IPsec WG to introduce a payload for the peer addresses
then the NAT traversal feature will be lost (so I recommend to keep
the current way to get the endpoint tunnel addresses in the peer addresses).

   
=> three cases:
 - IKEv1 : they (new IKE SAs) have not to be brought up on to setup
   the BU/BA SAs.
 - IKEv2 without readdressing: your objection applies but we'd like
   to have one IKE SA for all (BU/BA and tunnel) SAs (and
   readdressing :-).
 - IKEv2 with readdressing: your objection doesn't apply but shows
   a need for a fine readdressing control (i.e., per SA).

I am revising my IPsec/MIPv6 draft (today) and I'll propose (today or
before the end of the month) a readdressing feature for IKEv2 with
support for NAT traversal, multi-homing and mobility (in the IPsec list).

Regards

---

From: Bernard Aboba <[email-masked]>
Date: Sat, 25 Jan 2003 07:55:06 -0800 (PST)

> the current way to get the endpoint tunnel addresses in the peer addresses).

But when the HAO is present then the HA *is* the address that IKE runs
over -- so it's not an IKE issue. I understand why the *inner* address on
some of the packets needs to be the CoA (for the COTI and COT messages),
but that won't be a problem if the right selectors are negotiated. If
there is a NAT between the MN and HA then this will affect all IKE SAs
between the MN and HA, not just the tunnel mode SA, correct? And I don't
see why IKE NAT traversal is broken purely by adding an HAO. Can you
explain?

> support for NAT traversal, multi-homing and mobility (in the IPsec list).

Since IKEv2 will go to WG last call soon, it's fairly important to send a
message to the IPsec WG list ASAP, explaining that IKEv2 is missing
important features. Very few people are reading the IKEv2 draft at this
point, so it's sleep walking through the IETF process.

---

From: Francis Dupont <[email-masked]>
Date: Sat, 25 Jan 2003 19:05:04 +0100

But when the HAO is present then the HA *is* the address that IKE runs
   over -- so it's not an IKE issue.

=> this is an IKE issue because IKE over the home address will build
tunnel SAs with the home address as the endpoint/outer MN address.

   I understand why the *inner* address on
   some of the packets needs to be the CoA (for the COTI and COT messages),
   but that won't be a problem if the right selectors are negotiated.

=> the issue is with the outer address. If it is the home address,
all packets in the tunnel will get a HAO or a RH in spite of they
are already encapsulated.

   If there is a NAT between the MN and HA then this will affect all IKE SAs
   between the MN and HA, not just the tunnel mode SA, correct? And I don't
   see why IKE NAT traversal is broken purely by adding an HAO. Can you
   explain?
   
=> the fact the outer addresses in tunnel mode SAs are the peer addresses
is essential to the NAT traversal feature. So if we propose to change that
we loose the NAT traversal feature (i.e., we have to introduce a new
likely complex mechanism to get it back).

   important features.

=> they are at least two other important features (legacy authentication
and revised identities) not yet included in IKEv2 draft. And the address
auti-configuration stuff which was included has some concerns (DHCP over
IPsec seems to be a better solution)... I don't expect a successful
WG last call soon (unfortunately because IKEv2 is far better than IKEv1).

   Very few people are reading the IKEv2 draft at this
   point, so it's sleep walking through the IETF process.
   
=> I'll try to get a readdressing feature in time but I'll need some
support in the IPsec list...

Thanks