Subject: RE: [mobile-ip] BU Authorization method: design team recommendation

From: [email-masked]
Date: Tue, 5 Feb 2002 15:38:47 +0200

Hi Jari,

I've been following the emails for some time, but haven't felt
that could add much to aid in the discussion. However,
I'd at least like to register my feelings about the
design team recommendations.

> 1. The design team recommends a mandatory RR mechanism for
> IPv6 nodes, but with limitations on how long bindings can stay
> alive before they need to be refreshed. This recommendation is
> based on the findings of the security analysis, which point to
> some deficiences in the RR method below the "do no harm"
> principle, to which the limitations provide a reasonable
> answer. The RR mechanism should be placed in the MIPv6
> RFC. Given that RR may not be sufficient in all situations or
> may need to be replaced later with something else, we
> recommend that a secure mechanism for selecting different BU
> authorization methods, using the "bit method" described in the
> URL referenced from section 1, is included in this RFC as
> well.

Could you clarify this?  By the 'bit method', are you essentially
taking about Section 8 in: http://www.piuha.net/~jarkko/publications/mipv6/Residual_Threats.txt ?
Does (1) boil down to Mandatory RR and Optional CGA? I ask
because I still have some concerns about CGA.  CGA may not
protect well for IPv4 mapped address, etc.  Additionally,
I think Erik suggested that CGA may not be well known enough
and that perhaps a CGA BOF be held, so we can sort out all 
of the details.  I would tend to agree.  Or, is (1) suggesting
Mandatory RR + Optional Strong/Stronger method, to be determined
later?
 
> 2. The design team additionally recommends an optional CGA
> mechanism to be standardized in a separate RFC in the MIPv6
> WG, using the above "bit method". This recommendation is based
> on the findings of the security analysis, which point to
> lesser signaling requirements and improved security properties
> of CGA, as well as potential for solving additional, IPv6
> problems. Due to IPR and CPU consumption concerns it seems
> problematic to make CGA a mandatory requirement, however.

I would disagree on this point, CGA is still a relatively
new & novel technique (at least to me) and I'd feel more
comfortable with some more work [translate this to:
draft-roe-mobileip-updateauth-01.txt is not close to being
ready for last call].  Additionally, note my concerns above.

> 3. Regarding issue (i), the design team recommends that the RR
> method should not use a BSA since we already recommend both
> HoA and CoA RR tests to be performed every time a binding is
> refreshed or updated with RR. For CGA, the design team
> recommends that a (simplified) BSA can be used to store the
> Diffie-Hellman value generated as a part of the initial
> binding, since with CGA, only the CoA test needs to be
> performed on every binding refresh.

Can live with this.
 
> 4. Regarding issue (ii), the design team recommends both CoA
> and HoA tests to be performed every time binding is refreshed
> or updated with RR. We also recommend additionally that these
> tests are made using separate requests in order to avoid
> reflection problems with the authorization protocol itself (a
> BU authorization request sent from the CoA should not be
> answered to the HoA). This essentially leads to a five message
> exchange that lasts 1.5 RTTs since because two pairs of the
> messages can occur in parallel:
> 
> 1a. MN(HoA)--->HA--->CN
> 1b. MN(CoA)--------->CN
> 2a. CN-------->HA--->MN(HoA)
> 2b. CN-------------->MN(CoA)
> 3.  MN(CoA)--------->CN

Can live with this.
 
> 5. In order to guarantee security of the above exchange, the
> HA-MN tunnel should be encrypted for the RR messages (but not
> necessarily for other messages on this tunnel). Note that
> there aren't similar scalability problems with this as there
> are with MN-CN security, since the home agents and mobile
> nodes must have an existing relationship anyway. This could be
> done e.g. using IPsec ESP with pre-shared keys.

Can live with this.
 
> 6. For CGA, the design team recommends that 1a/2a can be
> omitted for all but the initial exchange and periodic tests
> every few hours or perhaps once a day.

Decision on this should be held off, note my concerns above.

John

---

From: Jari Arkko <[email-masked]>
Date: Tue, 05 Feb 2002 16:11:50 +0200

Hi John,

>However,

Excellent, that's what we need!

> taking about Section 8 in: 
> http://www.piuha.net/~jarkko/publications/mipv6/Residual_Threats.txt ?

Yes. First bullet item in section 8.

> Does (1) boil down to Mandatory RR and Optional CGA?

Not exactly. (1) suggests mandatory RR plus optional/later
method X, for which we already should design the selection
mechanism. But for (1), we don't need to decide that X=CGA.

> CGA may not
> of the details.  I would tend to agree. 

My personal opinion on this is that we should keep
work specific to a problem in the WG handling
that problem. I don't believe we have full understanding
of what CGA could do for IPv6 control signaling,
for instance, nor do we fully understand other possible
solutions. Therefore, I'd rather recommend a IPv6
control signaling BOF than a CGA BOF.

As to the use of RR or CGA in MIPv6, I believe that
should be dealt in this WG.

> ready for last call].

I'm in full agreement that we don't have last call -quality
text. [However, that unfortunately applies in part also to
RR techniques, see e.g. draft-roe-mobileip-updateauth-01.txt.]

In conclusion I'm in agreement with you that some
further work is needed. Maybe even more work for CGA
than for RR. In any case, we are suggesting separate
RFCs for base MIPv6 + RR and for CGA. Would this address
your concern on the additional work needed? The work
for RR would have to be done to the last details very
soon, while CGA RFC would not necessarily need to be
last called at the same time.

> > 3. Regarding issue (i), the design team recommends that the RR

Ok. Hmm... when you say "can live with this", can you
give some indication of why its only "live with" and
not "agree"?

> > 4. Regarding issue (ii), the design team recommends both CoA

Ok.

> > 5. In order to guarantee security of the above exchange, the

Ok.

> Decision on this should be held off, note my concerns above.

What we tried to do on this one is to evaluate the security
differences between various cases, and basically the same
results that in our opinion indicate the repetition of 1a/2a,
also point to leaving out 1a/2a from CGA in the mentioned
case.

Do you have a specific comment on the analysis and do
you disagree with the relevant part regarding HoA test?

Jari

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 5 Feb 2002 15:40:47 +0100 (CET)

> http://www.piuha.net/~jarkko/publications/mipv6/Residual_Threats.txt ? Does
> (1) boil down to Mandatory RR and Optional CGA? I ask because I still have
> some concerns about CGA.  CGA may not protect well for IPv4 mapped address,
> etc.  Additionally, I think Erik suggested that CGA may not be well known
> enough and that perhaps a CGA BOF be held, so we can sort out all 

Agreeing with what Jari Arkko said but adding an example of how this could play
out in detail. We get a bit reserved in the low-order 64 bits of an IPv6
address. A reasonable bit might be the 'group/individual' bit. This probably
means that RFC 3041 and perhaps other specs need to be tweaked to make it clear
that the 'reserved' bit must not be used when forming IPv6 addresses per those
specifications.

The MIPv6 specification says that if theabove  reserved bit is set in 
a home address then route optimization using RR MUST NOT be used
(and also says something about CGA being further studied to be possibly used
to route optimize for home addresses that has this bit set).

The above two should be done in parallel.
After this folks can work out details about CGA for MIPv6 (as well as exploring
CGA for other IP-level authorization issues).

   Erik

---

From: Alexandru Petrescu <[email-masked]>
Date: 05 Feb 2002 18:22:38 +0100

[email-masked] writes:
> CGA may not protect well for IPv4 mapped address, etc.

Just a note on the "et caetera".  It's a whole class of addresses that
are reserved and that start with 3 bits zero of which I don't know
much, just that they are not required to use 64 as the length of the
interface ID.  So putting 64 bits limits on these addresses is finding
him/herself somehow "in the dark".  Just a note.

Alex