Subject: [mobile-ip] Unresolved issue #1: Suboptions needed?

From: Jari Arkko <[email-masked]>
Date: Tue, 09 Apr 2002 19:02:34 +0300

The design team is trying to resolve all remaining issues
in the MIPv6 specification. A series of e-mails will be sent
to the list that explain the issue and the proposed resolution.
The resolutions go to draft-17 if there is no big controversy about
it. As these issues are expected to be smaller than the major design
decisions taken earlier this year it is perhaps sufficient to respond
to these mails only if you don't agree with the proposal i.e. silence
means consensus.

The current issue list is at

   http://www.piuha.net/~jarkko/publications/mipv6/MIPv6-Issues.html

I'll be completing the issue list over the next few days. I have
also tried to include a few issues that we have talked about in the
mailing list and appear to have a consensus on already for the purposes
of keeping track of things.

And now to the first issue.

Background: Draft 16 moved BUs and other messages away from
the IPv6 DO header. Earlier drafts had suboptions such as the
Alternate Care-of Address suboption which in draft 16 are now
under the messages. A single option remains in draft 16, the HAO.
Draft 16 still retains the possibility to have 'suboptions'
in this option.

Question: Does it make sense to keep suboptions just for HAO?
There are currently no suboptions in HAO. Most of the uses for
what used to be called suboptions can now be handled using a
similar mechanism inside the Mobility Header.

Proposal: Remove suboptions from Draft 17.

---

From: Jari Arkko <[email-masked]>
Date: Tue, 09 Apr 2002 19:20:44 +0300

There seems to be consensus about this but I'll send an
issue item about this just to document what's going on.

Background: Draft 16 included a requirement that HAs must
keep BU sequence numbers in non-volatile storage to prevent
replays. Folks on the list questioned this in two ways: First,
draft 15 already had a resynchronization procedure (which didn't
provide replay protection but allowed loss of state). Second,
building a replay protection scheme to manually keyed IPsec
was seen as a bad alternative to using a key management protocol
or building better replay protection to manually keyed IPsec.
Note also that MIPv6 must provide ordering support since IPsec
replay protection doesn't guarantee ordering, just prevents
replays. Therefore, the Sequence# field is needed in the BUs
in any case.

Question: Pick one for replay protection:
1. Require IPsec + IKE. No replay problem.
2. Require at least IPsec, but keep IKE as optional. Don't add
    any features for replay protection. Folks who don't use IKE
    will suffer from the replay vulnerability.
3. Require at least IPsec, optional IKE but add an application
    layer feature for replay protection to prevent replays if
    you happened to not have IKE. This was the draft 16 approach.
4. Require at least IPSec and a TBD light weight key management
    scheme, perhaps optional IKE in some cases. No application
    layer features. Replay protection works perfectly for everyone.

Proposal: Solution 2, but described in a way that makes it
clear to implementers that replay attacks become possible only
if manual keying is used and state loss can happen. Don't state
any specific key management mechanism.

Text. Text in 4.5.4:
IPsec can provide replay protection only when dynamic
security association establishment is used. This may not always be
possible, and manual keying would be preferred in some cases. IPsec
also does not guarantee correct ordering of packets, only that they
have not been replayed. Because of this, Mobile IPv6 provides its own
mechanism inside the Binding Update and Acknowledgement messages. A
sequence number field is used to ensure correct ordering. If the
mobile node reboots and forgets its current sequence number, the home
agent uses the status value 141 (Sequence number out of window, see
Section X.X) to inform the mobile node of the use of an
improper sequence number.

Note that the the sequence number mechanism provides also a weak form
of replay protection. However, if a home agent reboots and loses its
state regarding the sequence numbers, replay attacks become possible.
If the home agent is vulnerable to this, the use of a key management
mechanism together with IPsec can be used to prevent replay attacks.

A sliding window scheme is used for the sequence numbers. Therefore
the protection against replays and reordering attacks without a key
management mechanism works when the attacker remembers up to a maximum
of 2**15 Binding Updates.

---

From: "Jean-Michel COMBES" <[email-masked]>
Date: Tue, 9 Apr 2002 19:19:32 +0200

Hi Jari,

very nice idea !!!!!!! Good work too :-)

BTW, just a comment : would it be possible to indicate for each issue (even
if the issue is closed, ie. accepted/rejected) what is the context/problem
and how is it resolved ?
It is just to avoid to see again the same problem in one or two years  ...

Best regards.

JMC.

France Telecom R&D - DTL/SSR
Jean-Michel COMBES, Internet/Intranet Security
E-Mail : [email-masked]
Phone +33 (0)1 45 29 45 94, Fax +33 (0)1 45 29 65 19
PGP fingerprint : 07C6 37BF 4DE5 1CE1 EEB1 1F13 5D75 9E33 CFA7 0214

---

From: Francis Dupont <[email-masked]>
Date: Tue, 09 Apr 2002 19:23:33 +0200

=> AGREE

[email-masked]

---

From: Jari Arkko <[email-masked]>
Date: Tue, 09 Apr 2002 19:28:13 +0300

> It is just to avoid to see again the same problem in one or two years  ...

The intention is to update the descriptions (the issue<n>.txt files)
as we decide something, whatever that decision is.

Jari

---

From: Michael Thomas <[email-masked]>
Date: Tue, 9 Apr 2002 10:33:32 -0700 (PDT)

Agree.

		Mike

---

From: "Jean-Michel COMBES" <[email-masked]>
Date: Tue, 9 Apr 2002 19:38:37 +0200

agree

Text. Text in 4.5.4:

---

From: Jari Arkko <[email-masked]>
Date: Tue, 09 Apr 2002 19:59:11 +0300

Background: Binding acks and requests could be
spoofed, potentially leading the MN to lose understanding
of what the status of its BCE on the CN is or to create
unnecessary bindings.

On the other hand, not very powerful
mechanisms are available to authenticate the CN. Current
RR does not authenticate CN at all; the BAs could come from
anywhere in the Internet. Also, there are other attacks against
RO that we can't protect against and that cause correct
but useless bindings.

Question: Should we have some protection for BAs and BRs? Are
there any situations any more where a BR is required without
a BCE being established earlier?

Proposal: A simple cookie scheme allows us to verify that
the replies come from the path towards the CN. This appears
to close some potential attacks at very little cost; CNs
don't become more stateful and no additional messages are needed.

Text: Updated RR description below.

The RR signaling happens as follows:

     1a. MN(HoA) -> CN: HoTI(HoA, C0)
     1b. MN(CoA) -> CN: CoTI(CoA, C1)
     2a. CN -> MN(HoA): HoT(C0, K0, j)
     2b. CN -> MN(CoA): CoT(C1, K1, i)
     3. MN(CoA) -> CN: BU(HoA, CoA, C2, MAC, j, i)
     4. CN -> MN(CoA): BA(MAC)
     5. CN -> MN(HoA): BR(MAC)

Here the notation Node1 -> Node2: Message(Par1, ...)
denotes Node1 sending a message
Message to Node2.
The message has parameters Par1, ... An address following the
node name Node1(Address) implies that the given address of the
node is used.  A home address implies the message is routed through
the home agent and a care-of address implies the message is routed
directly.

Messages 1a and 1b are sent simultaneously, as are messages 2a and 2b.
Message 3 actually creates a binding, and message 4 is optional.
Message 5 is also optional and is sent later when the binding is about
to expire. Due to the simultaneous sending of messages, the Return
Routability procedure completes in 1.5 roundtrips excluding the
acknowledgement message.

The messages are described in more detail
below:

1a. HoTI (Home Test Init) Message:

     When a mobile nodes wants to perform route optimization it sends a
     HoTI message to the correspondent node in order to initiate the return
     routability verification for the Home Address.

         MN(HoA) -> CN: HoA, C0

     This message tells the mobile node's home address to the correspondent
     node. The mobile node also sends along cookie C0 that the
     correspondent node must return later, along with its own cookie that
     it generates based on the home address. The HoTI message is reverse
     tunneled through the Home Agent.

1b. CoTI (Care-of Test Init) Message:

     When a mobile nodes wants to perform route optimization
     it sends a CoTI message to the correspondent node in order to
     initiate the return routability verification for the care-of Address.

         MN(CoA) -> CN: CoA, C1

     The second message is sent in parallel with the first one. It tells
     the correspondent node the mobile node's care-of address. The mobile
     node also sends along cookie C1 that the correspondent node must
     return later, along with its own cookie that it generates based on the
     care-of address. The CoTI message is sent directly to the
     correspondent node.

2a. HoT (Home Test) Message:

     This message is sent in response to a HoTI message.

         CN -> MN(HoA): C0, K0, j

     When the correspondent node receives the HoTI message, it
     generates a cookie K0 as follows:

         K0 = MAC_Kcn(HoA | Nj)

     The cookie and the value j are sent to the mobile node via the Home
     Agent; it is an assumption of the protocol that the home agent -
     mobile node route is secure. K0 also acts as a challenge to test that
     the mobile can receive messages sent to its home address. Kcn is used
     in the production of K0 in order to allow the correspondent node to
     verify that the cookies used later really came from itself, without
     forcing the correspondent node to remember a list of all cookies it
     has handed out.

     Cookie C0 from the mobile node is returned as well in the HoT message,
     to ensure that the message comes from someone on the path towards the
     correspondent node.

     The index j is carried along in the protocol to allow the CN
     to later efficiently find the nonce value Nj that it used in
     creating this cookie.

     The notation used here is as follows. MAC\_K(m) denotes a message
     authentication code computed on message m with key K. H(m) denotes a
     hash of message m. HMAC SHA1 function~\cite{rfc2104}\cite{fips1801} is
     used to compute the message authentication code, and SHA1
     function~\cite{fips1801} is used to compute the hash. The final ``0''
     inside the MAC function is a 32-bit integer used to distinguish
     home and care-of cookies from each other.

2b. CoT (Care-of Test) Message:

     This message is sent in response to a CoTI message.

         CN -> MN(CoA): C1, K1, i

     The correspondent also sends a challenge to the mobile's care-of
     address. When the correspondent node receives the CoTI message, it
     generates a cookie K1 as follows:

         K1 = MAC_Kcn(CoA | Ni)

     The cookie and the value i are sent directly to the mobile node. The
     final 1 inside the MAC function is a 32-bit integer, again used for
     distinguishing home and care-of cookies from each other. Cookie C1
     from the mobile node is returned as well, to ensure that the message
     comes from someone on the path towards the correspondent node.

     Again, an index is sent along the cookie in order to identify the used
     nonce Ni. Note that i and j are likely to be the same in HoT and CoT
     messages, except when nonce values happen to have changed between the
     reception of HoT and the CoT messages.

3. BU (Binding Update) Message:

     When the MN has received both the HoT and CoT it has the
     cookies necessary to send the Binding Update.

         MN(CoA) -> CN: HoA, CoA, C2,
                        MAC_Kbu(BU | HoA | CoA | C2),
                        j, i,
                        ...

     The mobile node hashes together the challenges to form a session
     key (Kbu), and then uses this session key to authenticate a binding
     update.

         Kbu = H(K0 | K1)

     The message contains j and i, so that the correspondent knows which
     value of Nj and Ni to use to recompute the session key. "BU" is the
     content of the Binding Update message, excluding (1) the IP header,
     (2) any extension headers between the IP header the Mobility Header,
     and (3) the Authenticator field inside the Binding Update. The result
     of the MAC_Kbu function is used as the Authenticator field in
     the Binding Update. The three dots represent all the remaining (not
     security related) information in the message.

     A cookie C2 is sent along to ensure that the acknowledgement sent
     later will come from someone on the path towards the correspondent
     node. Once the correspondent node has verified the MAC, it can create
     a binding cache entry for the mobile.

4. BA (Binding Acknowledgement) Message:

     The Binding Update is optionally acknowledged by the
     correspondent node.

         CN -> MN(CoA): MAC_Kbu(BA | HoA | CoA | C2),
                        ...

     The correspondent node uses the same key (Kbu) to authenticate a
     binding acknowledgement. "BA" is the content of the Binding
     Acknowledgement message, excluding (1) the IP header, (2) any
     extension headers between the IP header the Mobility Header, and
     (3) the Authenticator field inside the Binding
     Acknowledgement. The result of the MAC_Kbu function is used as the
     Authenticator field in the Binding Acknowledgement. The three dots
     represent all the remaining (not security related) information in
     the message.

5. BR (Binding Request) Message:

     The correspondent node can optionally request a binding to be
     refreshed using the Binding Request message. This message can be
     authenticated using C2 from the Binding Update, and the Kbu that
     was created earlier.

         CN -> MN(HoA): MAC_Kbu(BR | HoA | C2),
                        ...

     "BR" is the content of the Binding Request message, excluding (1)
     the IP header, (2) any extension headers between the IP header the
     Mobility Header, and (3) the Authenticator field inside the
     Binding Request. The result of the MAC_Kbu function is used
     as the Authenticator field in the Binding Request. The three dots
     represent all the remaining (not security related) information in
     the message.

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 09 Apr 2002 13:13:05 -0700

The proposal looks good. AGREE

Vijay

---

From: Francis Dupont <[email-masked]>
Date: Wed, 10 Apr 2002 09:59:40 +0200

Agree

---

From: Francis Dupont <[email-masked]>
Date: Wed, 10 Apr 2002 10:04:00 +0200

the proposal (which seems to be reasonnable) is about BA/BR from a
common CN.

Thanks

---

From: Jari Arkko <[email-masked]>
Date: Wed, 10 Apr 2002 20:27:04 +0300

Francis Dupont wrote:

> Concern: BA from the HA MUST be protected. The text should be clarified:

Agreed. I believe the text was under a section dealing with MN - CN
bindings already, so it is perhaps already ok. Otherwise let me
know.

Jari

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 11 Apr 2002 09:09:53 -0700

> Proposal: Remove suboptions from Draft 17.

Agreed.

Regards,
Charlie P.