Subject: [mobile-ip] Comments on security requirements draft

From: Charlie Perkins <[email-masked]>
Date: Tue, 16 Oct 2001 13:14:56 -0700

Hello,

Here are some comments on the recent revision of the security
requirements document.

==============================================================
Document Structure
==============================================================

I think that the document needs to be restructured.
The main body of the document identifies security
issues, explains why there might be a vulnerability,
sometimes almost wholly unrelated to Mobile IPv6.
In most, but not all cases, an issue is described
by presenting a scenario, a threat, an effect,
a requirement, and in at least one case a "reaction".

I would rather see the following:
- Each threat/vulnerability/issue should be clearly
  identified and have its own name and subsection.
  This way, it would also appear in the table of contents
- Threats that are not specific to Mobile IPv6 should
  typically be put in the appendix, unless they are
  important for understanding something that IS specific.
- The "scenario/threat/effect/requirement" structure
  could easily be abandoned.  Each named issue, with
  the name in the subsection title, should be described.
  Maybe an occasional scenario would help.  Maybe some
  issues would need multiple scenarios.  Maybe some
  issues would be obvious and no scenarios needed.
  Possible suggestion: one paragraph for the issue,
  one short paragraph for the resulting requirement.

The table at the beginning of section 6 is, I think,
useless, at least in its current form.  I tried to imagine
using it while I was reading the document, and I could not
do so.  Maybe a different set of "axes" might cause some
sort of tabulation to be useful.  For instance:
- threats against MN/CN/HA/?/ as the rows ...?

As it is now, I think the table should be deleted.
Besides, it hasn't been updated to match the rest of
the document anyway.

I also think that the document needs a more coherent
"theme".  As it is, one can assort the "threats" in
the document into one of three classifications:

1. Problems that are not directly related to the design
   problems to be solved by Mobile IPv6.
2. Problems that have already been solved by Mobile IPv6.
3. Problems that need further attention and discussion.

So, for instance, describing threats that are really
relevant to Duplicate Address Detection might not be
appropriate for discussion on this document, even though
Mobile IPv6 presumes that nodes are able to use Duplicate
Address Detection(*).  Another possibility would be to collect
together all such discussion points into a preliminary
section (perhaps after the introduction) so that people
reading the document would better understand the overall
security vulnerabilities of IPv6 address autoconfiguration.
That might help avoid confusion during the discussion on
things that need to be considered specifically within the
Mobile IP working group.

(*) I picked this as an example specifically because it
    does not appear in the document, and thus hopefully
    could not obscure my point.  The threats that I feel
    are similarly extraneous include A.2, B.2, D.2.4
    (not meant to be exhaustive).

===============================================================

The title is wrong, and intimidating.  The first clause should
be deleted.  The second clause captures what I thought was
the point of the document quite well, and stands on its own
as a reasonable title.

Use of the word "introduce" means that the threat did not
exist before Mobile IPv6, and that the threat does exist
now.  This is clearly wrong, because mostly Mobile IPv6
does not introduce or even enable the threats that are
described.  Most often, the discussion centers around the
threat introduced by "remote redirection", terminology
predating even Mobile IPv4 (see RFC 2002).  Mobile IPv6 does
not enable this threat, and certainly does not introduce it.
Every use of the word "introduce" should be carefully
considered in this light.  I checked on this, and it's
not just in the existing title where the mistake is made.

However, it is entirely appropriate to list that threat as
justification for a security requirement.  This version of
the document does properly point out that Mobile IPv6 does
meet the relevant security requirement.  Understanding the
threat, and the subsequent need for the requirement, is a
valid and important topic for this document.  Describing that
threat as something introduced or enabled by Mobile IPv6 is
not valid or appropriate or true.

============================================================

There are too many variations on the exact same theme of
what happens when Binding Updates would be accepted without
authentication.  In Mobile IPv6, that cannot happen anyway.
But even working under the assumption that the threat should
be clearly described so that all readers can understand,
the current document muddies the issue by claiming so
many variations on it.  To take an absurd example, consider
what would happen if we added the following sections

Section Q.1:  What happens to SNMP if Binding Updates are
              not authenticated
Section Q.2:  What happens to IPv6 Encapsulation if Binding
              Updates are not authenticated
Section Q.3:  What happens to e-mail if ...
...
Section Q.9:  What happens to telnet if ...
Section Q.9.A:  What happens to telnet within the Home
                Domain if ...
Section Q.9.B:  What happens to telnet within another
                Domain if ...
Section Q.9.C:  What if the mobile node is a telnet _server_
                instead of a telnet _client_ if ...

Nobody needs to read through all that, and it does not
help.  What's important is that the Binding Updates need
to be authenticated, and it's always for exactly the same
reason.  Building it up into a bigger threat by allocating
so many different sections for the same problem is not
helping, in my opinion.

Plus, every time it is mentioned, it MUST be made very
clear that the threat DOES NOT EXIST in current (or past!)
Mobile IPv6 specification revisions.  Otherwise I fear
we will be diverted towards chasing problems that are not
there.

=============================================================

Section (2): the terminology entries shouldn't be numbered,
             and the terms should have white space or
             a new line separating them from the definitions

=============================================================

The threat of malicious, unauthenticated remote redirection is
the same, whether it happens at the home agent or a correspondent
node.  The only difference is that it might happen more often
at the home agent than at any particular correspondent node.
Thus, the discussion in section (3) should be reformulated to
avoid having separate classification.

Likewise, the introductory part of section (4) needs to be
substantially revamped.  Editorial: replace "covered" by
"eliminated".

============================================================

The classification in section (5) is not systematically
used in the rest of the document.  It is indeed helpful to
analyze each possible attack to see whether it can be
mounted at the various places mentioned.  The claim at
the end of the section is not really borne out in the
rest of the document, since denial of service attacks are
usually not considered under all four listed possibilities.

=============================================================

The table in section 6 should probably be deleted.  But, if
it is retained, then it should all appear on one page.
One of the column separators needs to be aligned.  A.4 is
missing.  D.1 is not described.  The attacks need to be
named instead of numbered.  I don't expect many people to
really flip back and forth through the document in order to
make use of the table, but maybe that's because I don't
understand what people would use the table for.

Replace "other's" by "others".

I think that 6.1.2 could safely be deleted, along with B.1.
B.3 should be put in the appendix.  The words "low cost"
are not needed.

Requirement B.4: replace "ensure it trusts the sender of"
by "authenticate".

Section 6.4 and elsewhere: replace "it's" by "its".
In Threat D.1: delete "easily", or else put in "if
authentication is not required".
In Effect D.1: replace "agains" by "against".  Plus,
the effect is not at all clear to me.

For threat D.2, it needs to be explained why this
flooding attack is at all different from any other
flooding attack.  Otherwise, the point seems irrelevant
to me.  Any control message can be utilized as the
data for a flooding attack -- or, for that matter,
any application directive or even vanilla data packet.
A difficulty might arise if the mobile node has to do
a lot of work to fulfill the request.

Effect D.2: (3) has the first two words of the second
sentence capitalized.  Plus, it doesn't seem relevant
anyway to the point about sending Binding Requests.
Same for points (1) and (2), actually.

Threat D.3 could be deleted without loss.

Effect E.1 and elsewhere: "masquerade" is spelled
           incorrectly as "masquarade".

Attack F.1 doesn't add anything to the discussion,
it seems to me.

Something is wrong between "Result H.1" and "Threat H.2".
The last sentence of that paragraph should perhaps be
deleted?

There are two "Threat H.2"s, not much different in content.

Requirement H.3: This is under debate on the mailing list
                 just now, but if it appears in the final
                 revision (and I hope it does not) one of
                 the capitalized specifiers would have to
                 be deleted.

===========================================================

Requirements:

There is nothing in the document to support the need for
identify verification.

Trivial editorial moot point: "MUST not" should be "MUST NOT",
except that in this case the construction shouldn't be there
anyway.  But the same problem does occur elsewhere in the
document.

7.1/D.2  Replace "for e.g" by "for instance".

7.1/5    Replace "SHOULD not" by "SHOULD NOT".  Besides, this
         item is also under current discussion.

7.2/9    This is not supported within the text, and furthermore
         it should be enough for mobile nodes to follow a
         mandated backoff algorithm.

===============================================================
  
Appendix B: The parenthesized clause can be deleted without
            harm, and the next sentence mentions a
            "specific condition", but I could not figure out
            what the condition was.

Question 2: The Binding Cache is specified to be handled as
            a cache, with any reasonable cache replacement
            policy.  LRU is good.  FIFO would not be as good.

Comment 2: Please insert "some" before "wireless" in the first
           sentence.  There are more instances of "it's" that
           should be "its" here.

===============================================================

Lastly, I hope that the process of identifying whether we
have satisfied the security requirements laid out in this
document can proceed right away, without having to wait for
the document to be completed.  I think the process of creating
the document has made people aware of the issues, and that we
could try to make some progress with the other documents.

Regards,
Charlie P.

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 16 Oct 2001 22:42:13 +0200 (CEST)

Charlie,

>     (not meant to be exhaustive).

A.2 is about the effect on ICMP errors in the binding cache.
MIPv6 introduces the notion of a binding cache thus this sure seems to
be MIPv6 specific.

D.2.4 is about flooding Binding Requests, and BRs is part of MIPv6.

B.2 states that it isn't MIPv6 specific, but I think it makes
sense to include it in the document since it points out that there
are other unaddressed threats that allow for attackers on the MN's link
to redirect or black-hole traffic. Thus having this attack discussed
helps point out that MIPv6 doesn't necessarily need to address new attacks
made possible by MIPv6 when the attacker is constrained to being on the same
link.

So which are the other ones you think don't belong?

  Erik

---

From: Charlie Perkins <[email-masked]>
Date: Tue, 16 Oct 2001 13:57:26 -0700

Hello Erik,

That was fast!

> MIPv6 introduces the notion of a binding cache thus this sure seems to

In that sense, I agree with you.  But the more general problem is
that ICMP Unreachable would be likely to cause applications to
be disrupted, networks to be unreachable, and other similarly
bad effects, all without authentication.  So I was thinking that the
described threat was a minor sub-part of a much more general
problem with ICMP.  In other words, it's the unauthenticated
ICMP that's the problem, not that it has some associated effect
on Binding Cache entries.

I'm not suggesting that we have to authenticate ICMP messages.

> D.2.4 is about flooding Binding Requests, and BRs is part of MIPv6.

But the problem is with flooding, and the fact that the water is flavored
with "Binding Request" bits doesn't matter much as far as I could tell.

> made possible by MIPv6 when the attacker is constrained to being on the same

O.K.  I would again suggest that all such descriptive text belongs in
a preliminary section on background, or else an appendix, and should
be clearly separated out from the more directly relevant security
discussions.

> So which are the other ones you think don't belong?

Can I take a rain check on this invitation?  I'll try to get back to
it, depending on subsequent discussion.

Regards,
Charlie P.

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 17 Oct 2001 00:23:06 +0200 (CEST)

> I'm not suggesting that we have to authenticate ICMP messages.

Yes, but the purpose of the document is to explain threats so that 
protocol designers can take the threats into account.

And typically (as required by RFC 1122) ICMP destination unreachable messages
must not terminate TCP connections - instead they are just recorded so
that in case the TCP connection times out the appropriate error is
returned to the application.

> with "Binding Request" bits doesn't matter much as far as I could tell.

Again, purpose if for designers of MIPv6 security mechanisms to understand
the threats.

For instance, if there is a design that causes the reception of any BR to
have the MN do some expensive computation or send multiple packets,
then that would be a source of concern.

> be clearly separated out from the more directly relevant security

I'm not too concerned by the organization of the document 
at this point in time - the actual content like making sure that the
threats cover the bases and that the requirement are related to reality
is more important.

But to me it makes sense to list all the threats that have
been considered in and around mobile IPv6 in one place whether or not
that threat results in specific requirements for mobile ipv6.

  Erik

---

From: Charlie Perkins <[email-masked]>
Date: Tue, 16 Oct 2001 16:32:39 -0700

Hello again Erik,

> threats cover the bases and that the requirement are related to reality

Content is important first and foremost, but the organization of the
document seems to be crucial for getting the best results.  It's not a choice
"either/or".  Both are crucial.

Here is another proposal.

We can identify the kinds of attacks that need to be prevented.
- Flooding
- DDoS
- Remote Redirection
- ICMP effects
- ... others

For each kind, have a major section.
For each way that there might be some danger of such an
attack, have subsections.  Each subsection could be entitled:
"<Kind of Attack>:<Method>", where, for "Flooding" (to use
the example in our previous notes), <Method> might be
Abusing Binding Updates.

Another useful organization would be to have major sections
according to the Mobile IPv6 functionality involved.
But I think it would be better to have the sections according
to the attacks, and then have a later section that cross-references
the attacks according to the Mobile IPv6 functionality.  In fact,
maybe the "ICMP effects" from my earlier list would belong
in this later section.

So, for instance, this later section might look like:
- Binding Update
  = remote redirection if missing authentication (bad!)
  = flooding would be bad if CN/HA has to authenticate too much
- Binding Acknowledgement
  = bad if missing authentication
  = flooding would be bad if MN has to authenticate too miuch
- Binding Request
  = flooding would be bad if MN does too much work
- ...

Of course, I am just making this up, but I think such an organization
would be far more useful than the current document.  And, it would
seem to address your concerns also.

Regards,
Charlie P.

---

From: Pekka Savola <[email-masked]>
Date: Wed, 17 Oct 2001 13:04:30 +0300 (EEST)

I'll comment on two issues only, both are rather generic.

> not just in the existing title where the mistake is made.

(a more general comment)

I've noted that a few people here have a dangerous way of thinking
(perhaps unbeknownst to them), that it is enough to specify how Mobile
IPv6, _as specified_, can be secured.  That is, HA<->MN, MN<->CN etc. are
secure.

There is a lot more to it.

MIPv6 introduces Home Address option, takes Routing Header into very 
widespread use, assumes a lot about Binding Updates, specifies new ICMP 
types, etc.

In my book, it's also the (at least a major part of the) responsibility of
mobile-ip wg to see that these enhancements to the core protocols are
secure and proper.

The latter is a reason I tried to raise awareness with my rh-ha-security
draft.
 
> we will be diverted towards chasing problems that are not

How do you expect the implementors to handle this?  To make MIPv6 useful,
binding updates are pretty much needed (or are they?).  They must be
authenticated by the spec.  In practise authentication cannot be done, and
thus no binding updates are possible in general case.

We've seen previously that this may lead to "hmm.. we're just testing now,
and there isn't so much harm to it.. I'll just ignore that point of the
spec, and accept unauthenticated BU's for now.. after all, we have
deadlines to meet, and we'd like to get MIPv6 out very soon for the good
of the everyone.  We can worry about BU's later."

Ie. it's good to remind of these issues lest we'd adapt too weak security 
measures to cope for the lack of scalability of IKE.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

---

From: Alexandru Petrescu <[email-masked]>
Date: 17 Oct 2001 14:03:09 +0200

Charlie Perkins <[email-masked]> writes:
> Requirement B.4: replace "ensure it trusts the sender of" by
> "authenticate".

Hi Charlie,

I think the way it's currently formulated it allows for more than
crypto solutions.  If Binding Acks must be "authenticated" then some
authentication data exchange should take place between sender and
receiver.  On the other hand, if receiver of Binding Acks only
"trusts" the sender, then receiver might rely on other things than
crypto (for example return routability) to "trust" the sender.  Maybe
"trust" is too strong of a word, then something else.

If needed, I can give two different solutions each one satisfying one
of the versions of this requirement.

Just an oppinion, thanks for your remark,

Alex

---

From: Charlie Perkins <[email-masked]>
Date: Wed, 17 Oct 2001 08:09:00 -0700

Hello Pekka,

Some clarifications/comments below...

> IPv6, _as specified_, can be secured.  That is, HA<->MN, MN<->CN etc. are

I think the point would be to point out the areas for concern, and
point out Mobile IPv6 features should be designed to avoid problems.
My specific issue that I raised was with the wording, used several
times within the draft, that indicated to a fresh reader that Mobile IPv6
"introduces" problems enabling remote redirection attacks.

> There is a lot more to it.

But my remark was specific to that issue.  I do not claim that is the
only issue.

> mobile-ip wg to see that these enhancements to the core protocols are

Your book seems to be a lot like my book in this respect.

> How do you expect the implementors to handle this?

Pretty much the way they did handle it.  Our implementations
have handled it in ways that weren't too beautiful for configuring
security associations, but the protocol was right and the authentication
was done correctly.

>                                                                      To make
> MIPv6 useful,
> binding updates are pretty much needed (or are they?).

They are needed, unequivocably.  The only way you could argue
otherwise is for the case when someone is building a system in which
the mobile nodes cannot send packets to arbitrary IPv6 correspondent
nodes.  I think such systems would be very rare.

> They must be

In practice, authentication can be done, but the ways of setting up
security associations are currently not scalable.  That is a much different
statement, and I think it is a good idea to keep track of the difference.

> of the everyone.  We can worry about BU's later."

Maybe there are examples in other working groups, but I would
be surprised if anyone following the discussion over the last two
years in this working grop would come to that conclusion.  Plus,
it would be almost impossible to imagine vendors with roaming
agreements believing such a thing.

What I had expected was that after the base protocol was done,
there would be room for people to develop follow-on security
protocols to address the scalability issues.  Plus there would be
a lot of usefulness for initial deployments that would work even
suffering the disadvantages of triangle routing -- witness Mobile IPv4.
The additional security protocols for key exchange would then
look like scalability upgrades, and over time more and more of
the original correspondent nodes would have gotten upgraded.

> measures to cope for the lack of scalability of IKE.

I still think that would have been a better idea to issue Mobile IPv6 as a
Proposed Standard with non-scalable key exchange, rather than to have
this long delay (no secret).  One result has been to put at least an equally
long delay in the process of adopting Mobile IPv6 as part of the mobility
management solution for 3G telephony.  But that doesn't mean I am going
to sit around complaining about it.  Instead, I hope to be part of the
solution
towards designing a scalable answer for establishing the appropriate security
associations.

Regards,
Charlie P.

---

From: Michael Thomas <[email-masked]>
Date: Wed, 17 Oct 2001 09:07:24 -0700 (PDT)

> thus no binding updates are possible in general case.

   Right. This is unhelpful at best, and an
   equivocation at worst. Trying to play spin
   control on the draft serves no purpose.

	   Mike

---

From: Pekka Savola <[email-masked]>
Date: Wed, 17 Oct 2001 22:11:42 +0300 (EEST)

> Some clarifications/comments below...

Thanks.  We seem to be very much in agreement.  One comment below.

> > of the everyone.  We can worry about BU's later."
[snip]
> the original correspondent nodes would have gotten upgraded.

I see a potential problem with this approach: if, when developing these
follow-on security protocols, we found out we have to change X, Y and Z in
the MIPv6 standard (which may or may not be doable backwards-compatibly),
we'd be "locked" to the design we chose earlier, or have to develop
MIPv6.2.

If more or less significant changes will be required, in the end, it
should be easier to do them now.