Subject: RE: [Mip6] Preconfigured Kbm as working group document

From: "Soliman Hesham" <[email-masked]>
Date: Wed, 10 Mar 2004 22:02:23 -0500

Hi Vijay,

 > >    A correspondent node and a mobile node MAY use a preconfigured
 > >    binding management key (Kbm) to manage the authentication
 > >    requirements for binding cache management messages.  
 > Such keys must
 > >    be handled carefully to avoid inadvertent exposure to 
 > the threats
 > >    outlined in [2].
 > 
 > >    A mobile node MUST use a different binding management key (Kbm)
 > >    for each node in its Binding Update List.  This ensures that the
 > >    sender of a Binding Update can always be uniquely 
 > determined.  This
 > >    is necessary, as this authorization method does not provide any
 > >    guarantee that the given care-of address is legitimate.
 > 
 > >    For the same
 > >    reason, this method SHOULD only be applied between 
 > nodes that are
 > >    under the same administration.  The return routability 
 > procedure is
 > >    RECOMMENDED for all general use and MUST be the 
 > default, unless the
 > >    user explicitly overrides this by entering a key for a 
 > particular
 > >    peer.
 > 
 > if the CN does not trust the MN not to misbehave, then it
 > shouldnt use this mechanism. it should use return routability.

=> I read this section, but I think your conclusion
is not clear and is not reflected by the text. For instance,
being under the same administration does not imply "trust"
(which is conditional in itself). A public access network
may be under the same administration but operators don't
typically trust subscribers to always do the right thing, 
especially when you consider anonymous subscriptions ..etc.

 > 
 > > - Why does the draft say that if nonces exist the "MAY be
 > > ignored" ? shouldn't they just be ignored? under what circumstances
 > > are the nonces acceptable?
 > 
 > the actual text says
 > 
 > > The Nonce Indices option SHOULD NOT
 > >    be present.  If it is present, the nonce indices supplied MAY be
 > >    ignored
 > 
 > do you want the packet dropped and an ICMP error generated?

=> This seems like an appropriate reply, unless there 
is a reason that a packet can be accepted with nonce
indices. 

 > ps: the draft is available at 
 > http://people.nokia.net/charliep/txt/mobilev6/precfg.txt

=> It's on the IETF web page as well.

Hesham

 > 
 > > 
 > > Thanks,
 > > Hesham
 > > 
 > >  > -----Original Message-----
 > >  > From: [email-masked] 
 > [mailto:[email-masked]]On Behalf Of
 > >  > Charles E. Perkins
 > >  > Sent: Wednesday, March 10, 2004 5:23 PM
 > >  > To: Mobile IPv6 Mailing List
 > >  > Cc: Basavaraj Patil (NTC/Dallas); Gopal Dommety
 > >  > Subject: [Mip6] Preconfigured Kbm as working group document
 > >  > 
 > >  > 
 > >  > 
 > >  > Hello folks,
 > >  > 
 > >  > I would like to request that the following document
 > >  > be considered as a working group document:
 > >  >    "Preconfigured Binding Management Keys for Mobile IPv6"
 > >  > 	  draft-perkins-mip6-precfgKbm-00.txt
 > >  > 
 > >  > This short document was discussed at the recent
 > >  > IETF meeting, and the basic idea has been discussed
 > >  > sporadically several times in the past.
 > >  > 
 > >  > Regards,
 > >  > Charlie P.
 > >  > 
 > >  > _______________________________________________
 > >  > Mip6 mailing list
 > >  > [email-masked]
 > >  > https://www.ietf.org/mailman/listinfo/mip6
 > >  > 
 > > 
 > > _______________________________________________
 > > Mip6 mailing list
 > > [email-masked]
 > > https://www.ietf.org/mailman/listinfo/mip6
 > 

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

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 10 Mar 2004 19:24:17 -0800

> is not clear and is not reflected by the text. 

I think the security considerations section is pretty clear. it
says when in doubt dont this mechanism. return routability is
the default mechanism and the one that is applicable for general
use.

> is a reason that a packet can be accepted with nonce

okay.

> => It's on the IETF web page as well.

I thought it was not available on the IETF website (it had expired
in October). I should have checked.

Vijay

---

From: Jari Arkko <[email-masked]>
Date: Thu, 11 Mar 2004 08:58:32 +0200

I don't have anything against the preconfigured kbm draft.
However, I think it would be appropriate to discuss priorities
a little bit.

Is the primary purpose of the preconfigured kbm to improve the
latency and reduce signaling associated with RR? Or something
else?

I'm asking because latency/signaling reduction might be solved
by one of the optimized RR proposals. We're not there quite yet,
probably some revision rounds are needed before any of the
current proposals can really be considered for WG items. But
assuming we get there, such mechanisms would be much more
generally applicable than the preconfigured kbm approach.

--Jari

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 11 Mar 2004 20:55:04 -0800

Hello Jari,

Jari Arkko wrote:

> latency and reduce signaling associated with RR?

Yes, that's it.

> by one of the optimized RR proposals.      .....
>     .....              such mechanisms would be much more

They will be more generally applicable, but generality is not the
point of my draft.  Simplicity and performance and the fact that
the code already exists in most cases, is the point of my draft.
It's basically good-tasting fruit that is hanging so low that it is
almost falling off the branch if we would just extend our hand
to catch it.

Regards,
Charlie P.

---

From: Pekka Nikander <[email-masked]>
Date: Fri, 12 Mar 2004 14:59:38 +0200

Charlie,

> almost falling off the branch if we would just extend our hand

The draft is simple, indeed.  Actually, a little bit too
simple to my taste.  For example, it is not quite so clear
about omitting the RR procedure.  That is, such an omission
is more implied than clearly spelled out.

What comes to the taste of this fruit, I admit that the initial
taste is very tempting.  However, I am a bit worried about the
potential aftertaste.  That is, I'm afraid that after a couple
of years this fruit may get a taste that resembles a well known
meat product sold in small tins.

This is actually a more generic issue.  I am worried about any
new protocol that has potential reflection/amplification
vulnerabilities and does not have adequate scalable protections.
Such protocols are prone to cause nasty DoS problems, which
from the economic point of view are the network level equivalent
of spam.  But you know that well enough.

I would suggest that you first produce a strong enough
applicability statement, clearly spelling out where the draft
would be applicable and what are the potential consequences
if a large number of CNs accept preconfigured Kbms with
an MN that turns out to be untrustworthy.  For example, if there
are strong enough assurances about real life traceability of
any such MN, then using this kind of optimisation may be ok.
However, if such assurances cannot be reached, I would consider
this pretty risky, at least if used in the Internet.

We have to remember that, in reflection attacks that take place
in the Internet, the victims are nodes that do not take part
into the mechanism.  To add more emotion to the argument (perhaps
wrongly), I'd say that we must protect the innocent.

--Pekka N.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 12 Mar 2004 09:04:01 -0800

Hello Pekka,

> is more implied than clearly spelled out.

I think, in general, that it's a mistake for
protocol specifications to spend a lot of
time detailing what is omitted.  For instance,
I don't specify that the correspondent node
does NOT have to be a DHCP relay, or a SIP proxy,
just to put it to extreme cases.

Worse yet, once a particular omission is identified,
then people reasonably start to ask why the other
omissions were not identified.  Maybe they should
have been considered after all, right???  _not_

In this case, simplicity is quite appropriate.

> meat product sold in small tins.

Well, it's not spam.  And, moreover, we already have
the experience to know that it works.  Otherwise, there
would be trouble already with Mobile IPv4 and the way
home agents are configured.

> vulnerabilities and does not have adequate scalable protections.

This is not a new protocol.  This is a way to establish a
security association between nodes that satisfy certain
stringent conditions.  There is no protocol.  In fact,
the technique suggested is, practically speaking, far
more secure than return routability.

> of spam.  But you know that well enough.

If I knew who was sending me spam, my problems would
immediately be improved drastically.

> an MN that turns out to be untrustworthy.

You are asking me to state what would happen if the
specification were not followed.  That leads to a tarpit
I intend to avoid.  The use case is clear, and anyone
who has used the protocol knows it immediately.

> wrongly), I'd say that we must protect the innocent.

While I agree with your statement, it does not apply
to the discussion.  The mobile node is always clearly
known to the correspondent node, and if your trusted
co-worker causes you to bomb the White House with IPv6
packets, you know where to go for redress.

Regards,
Charlie P.

---

From: Pekka Nikander <[email-masked]>
Date: Fri, 12 Mar 2004 20:49:41 +0200

Charlie,

>> applicability statement...
>

I completely agree with you that so is the case as long
as the system is used within a small group of users.
A single administrative domain may _not_ be such a small
group of users, even though I agree that it usually is.

Hence, I still call for a stronger applicability statement
and a stronger security considerations sections.  But perhaps
they could be added as a part of the WG process, if you feel
uncomfortable with adding them as an author.

--Pekka N.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 12 Mar 2004 11:06:14 -0800

Hello Pekka,

Pekka Nikander wrote:

> and a stronger security considerations sections. 

I would be quite happy to add the stronger statements,
and I would be even happier if you would supply the
text that would do the trick.  Making these things
clear was the intention of the text I already put in
there, but if more text is needed then let's make it
happen.

Regards,
Charlie P.

---

From: Jari Arkko <[email-masked]>
Date: Fri, 12 Mar 2004 21:23:36 +0200

> there, but if more text is needed then let's make it

Some thoughts below, hope this helps:

I think the difference is between a closed, trusted group
of users such as the employees of my department vs. a large
set of known but not necessarily trusted users. As an example
of the latter, if a major CDMA 2000 operator decided to switch
to MIPv6 RO with preconfigured Kbms for a zillion subscribers,
we might get problems. Yes, you could track the subscribers
down (at least if they are not prepaid), but that would be
generally too late and would not help if their machines were
compromised due to a virus, for instance.

So I think this is more about "trust" than about being "under
the same administration" as you currently mention in the I-D.
Perhaps you could say "under the same administration and trusted",
and then adding some text that warns how subscribers of an
operator generally cannot be trusted this way.

--Jari

---

From: Jari Arkko <[email-masked]>
Date: Sat, 13 Mar 2004 01:25:05 +0200

Charlie,

I know its bad to respond to one's own e-mails, but...
thinking some more about this, I realize that I didn't
give you good advice. The situation isn't all that different
from the home agent, which also doesn't check for correct
care-of address.

So the crucial thing which we need to ensure is that
no one applies this method with a constant Kbm for
lots of mobile nodes, which you already state in your
draft.

I think we may also need to say something about administrative
contacts, something which you would expect from an operator
who runs a home agent service but which may not be obvious
for a correspondent node. I'm not quite sure how to formulate
that requirement, but the idea is that if you get a lot of
problems associated with a given home address through a
correspondent node, you should be able to get to a responsive
network manager of the correspondent node by inspecting e.g.
the whois database. [Note that it isn't enough to contact
the home agent administrator, because you method allows bindings
to be established without any packets passing through the
home agent.]

Other comments on your draft. It may be obvious, but the
draft doesn't exactly say it outloud: Kbm is indexed by
the home address. Also, the replay protection appears
to work only if the BCE is kept alive at all times.
Did you intend to do this, or have another data
structure that keeps some state when the BCE is
not active for a given home address?

--Jari