Subject: Re: (CLARIFICATION) Re: [mobile-ip] Routing headers: design team recommendation

From: Francis Dupont <[email-masked]>
Date: Fri, 01 Feb 2002 11:54:47 +0100

>  I have some arguments in favour of the routing basis of this feature:

=> I keep this statement because this is the key one.
   
   The fact that it is a special case of a tunnel clearly argues for
   IPv6_NO_SRC (but there might be other reasons for that being undesirable).
   
=> I agree: both RH and D/Z tunneling are routing devices. The argument
is about ADA: ADA is *not* a routing device (the complexity to mix
RHs (for another purpose) and ADA is a proof), IMHO ADA is a MIPv6
ad hoc device.

   But I don't see how this leads to RH as being a good alternative.
   A destination options header with either a HOA, ADA, or both options
   looks a lot more like Deering/Zill tunneling than HOA, RH, or both.
   
=> symmetric argument...

   NOTE: The above doesn't work with ingress filtering at all hence
   it is completely academic.

=> of course this doesn't work with ingress filtering (uRPF in fact):
ADA is not a routing device.

   But it seems like it would be the conceptually clean way 
   to apply RH in this space.
   
=> matter of taste (what is more important: symmetry or routing device?)
   
   Do people see strong arguments for/against handling the "source HoA" and the
   destination "HoA" using the same mechanism?
   
=> no, there is no strong argument for/against any of the four alternatives.

   Does it make any difference e.g. in IPsec related complexity?
   
=> this comes back to a previous message: for IPsec RH or ADA are the same,
D/Z tunneling has to be investigated, nobody has proposed details about
a new not-final header (similar to ADA which is better).
We should do a summary of arguments in order to be more efficient, but
the first point is to reach a consensus about the #3 approach.

Regards

[email-masked]

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 4 Feb 2002 14:33:47 +0100 (CET)

> RHs (for another purpose) and ADA is a proof), IMHO ADA is a MIPv6

So same question I've been asking Charlie - what would combining RH and
MIPv6 (assuming MIPv6 didn't use RH) actually be useful for?
Mobile routers and/or mobile network?

I do understand that the "nesting" properties of tunneling and destinations
options are different; one could nest multiple deering/zill tunnels with
potentially different nodes adding and removing the nested headers.
One could also see some form of "destination specific nesting" using RH
but one couldn't do source nesting for packets sent in the other direction
since the HAO do not nest.
Is what I call "nesting" (recursive application) close to 
what you mean by "routing device"?

> ADA is not a routing device.

I'm confused - my NOTE was about using a "consumed" routing header
to capture the semantics of the HAO - It was not about ADA.

> the first point is to reach a consensus about the #3 approach.

The chairs already declared consensus on approach #3 (i.e. to define somehing
new for MIPv6). I'm trying to capture a list of pros and cons for
	New RH type
	New (ADA) destination option
	Deering/Zill tunneling
	New extension header

So the purpose of me asking stupid(?) questions is to make sure I understand
the pros and cons that people bring up.

  Erik

---

From: Jari Arkko <[email-masked]>
Date: Mon, 04 Feb 2002 23:00:59 +0200

The MIPv6 security design team is trying to resolve the issues
around the method to use for authorizing binding updates.

This note specifies the design team's motivation and current
position. In order to move forward in an efficient manner it
would be beneficial if responses could make it clear they are
- a clarification (by putting CLARIFICATION: in the Subject
   field)
- an issue with a particular point (by ISSUE:)
- disagreement with the conclusion (by CONCLUSION:)

We would also like folks to state for each of our six separate
recommendations whether they AGREE, CAN TOLERATE, or DISAGREE
with them. In case of DISAGREE, please explain why.

1. INTRODUCTION
===============

To date, various BU authorization methods have been proposed.
Of the proposals that don't assume a separate infrastructure
the properties they rely on are either RR and/or CGA
properties.  An analysis of the security properties of those
general categories of CGA and RR can be found at:

     http://www.piuha.net/~jarkko/publications/mipv6/Residual_Threats.txt

2. ALTERNATIVES
===============

The main alternatives for the actual address ownership authorization
problem are:

(a) Return Routability, RR
(b) RR enhanced with Cryptographically Generated Addresses, CGA

The security properties of these methods have been described
in the URL referenced from section 1. In addition, there are a
few additional properties we would like to bring to the
attention:

- CGA requires additional computational power. It is not
   clear though if this is big enough requirement to be an
   issue, particularly when very constrained nodes could
   refuse RO, and given that it has been demonstrated that
   protocols can be designed where MNs and CNs can offload
   their expensive computations to their HAs.

- Several IPR claims have been made regarding CGA.

In addition to the basic mechanism there are a few additional
issues that we need to decide:

(i)  Whether or not Binding Security Associations (BSAs) are
      used

(ii) What addresses need RR tests (HoA, CoA, or both), and
      what is the correct time to perform the tests, always
      at the time the binding is requested?

3. 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.

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.

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.

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

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.

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.

---

From: Francis Dupont <[email-masked]>
Date: Tue, 05 Feb 2002 12:45:25 +0100

=> each time an advanced routing feature is used with MIPv6.

=> this is the main example but there are others like policy routing,
VPNs, multicast routing, etc. But I agree the main issue of the
home address as an identifier is mobile routers and/or networks.

=> this is an important example of "routing device" but there are others,
for instance multicast routing, which can use very different mechanisms
(i.e. Reverse Path Forwarding check has nothing to do with "nesting").

=> I believe we can remove the last one (new extension header) and we
should wait for HAO if we'd like to really discuss about D/Z tunneling.

=> I believe we already got all arguments about RH and ADA. What we need
is more organization and feed back from other issues (if we'll give up HAO
the situation will be very different).

Regards

---

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

> the situation will be very different).

Has anybody talked about giving up HAO?
Are you referring to the possibility of replacing it with D/Z tunneling?

   Erik

---

From: Michael Thomas <[email-masked]>
Date: Tue, 5 Feb 2002 07:58:41 -0800 (PST)

So, what I don't see here is any specific
recommendation about HA/MN security. I guess that
what the following is recommending is that it use
strong authentication (and not CGA), but it's
still not entirely what the specific proposal is.

	  Mike

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 5 Feb 2002 17:24:12 +0100 (CET)

> still not entirely what the specific proposal is.

Where you looking for something more specific in recommendation #5?

  Erik

---

From: Michael Thomas <[email-masked]>
Date: Tue, 5 Feb 2002 08:42:38 -0800 (PST)

> Where you looking for something more specific in recommendation #5?

   There wasn't consensus on the "eg" part
   below. To be useful, I think the DT needs to
   actually recommend something here. This is the
   single security thing that an operating network
   mipv6 MUST implement and use. Mind you, I'm 
   happy with the example.

	      Mike

---

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

Hi Jari and thanks for the update!  I generally agree with its
orientation, I have remarks, below.  Where I didn't put remarks it's
that either I agree or I don't know.

Jari Arkko <[email-masked]> writes:
> answer.

AGREE.

> The RR mechanism should be placed in the MIPv6 RFC.

AGREE, but as stated looks to me like it would lengthen the draft and
the standardization procedure.  Maybe it should say "RR _hooks_ should
be placed in the MIPv6 rfc", that's shorter than putting whole new RR
message exchanges.

> authorization methods, using the "bit method" described in the URL
> referenced from section 1, is included in this RFC as well.

CAN TOLERATE, but bit method should be presented to ipng and get some
input from them.  Erik already proposed u/g but I guess that is too
much related to Ethernet?

> 2b. CN-------------->MN(CoA)

CAN TOLERATE, this sequence is obviously subject to discussion, as
it's debatable whether there's need to go twice through the HA (even
when RRing both HoA and CoA).  But that can be discussed separately.

Alex

---

From: "Jari Arkko" <[email-masked]>
Date: Tue, 5 Feb 2002 20:01:26 +0200

> be placed in the MIPv6 rfc", that's shorter than putting whole new RR

Fair enough. I think the important part is to realize that MIPv6 functionality
and RR BU Authorization are inseparable logically, and one could not e.g.
advance to RFC status before the other.

> input from them. 

I agree.

> when RRing both HoA and CoA).  But that can be discussed separately.

Yes, the details we can propably take outside this thread. Just as a quick
comment here I would note that the above procedure can be made stateless
in the CN, and has no reflection issues (sending responses to somewhere
else than they came from). That seems to imply an even number of
messages through the HA, or?

Jari

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 5 Feb 2002 22:32:36 +0100 (CET)

> much related to Ethernet?

RFC 2373 relies on the IEEE EUI-64 addressing format (which is a superset
of IEEE 802 aka Ethernet addresses) so this wouldn't add any new 
relationships.

I'm assuming the co-chairs and AD for the WG would figure out how to
do the coordination of this issue.
 
> when RRing both HoA and CoA).  But that can be discussed separately.

There is some text in the residual_threats.txt document which explains the
motivation for this. Basically if a packet has the HoA as a source address
the destination address of the reply to that address should be the HoA, to
avoid creating reflectors that can't be prevented using ingress filtering.

Thus the 1a request needs to be tunneled from the MN to the HA to avoid
ingress filtering dropping it (its source is the HoA)
and the 2a reply will go through the HA since it is addressed to the HoA.

  Erik

---

From: Alexandru Petrescu <[email-masked]>
Date: 06 Feb 2002 10:16:31 +0100

> of IEEE 802 aka Ethernet addresses) so this wouldn't add any new 

IEEE EUI-64 being a superset of IEEE 802 is still not all potential
types of L2's under IPv6.  I bet that most SDO's developping L2's for
current telecom trends will not ask IEEE how to generate their ID's
simply because their vision of a network is different.

True that RFC 2373 relies on EUI-64 (modified) but reserves space for
future addresses that don't necessarily rely on EUI-64 (again, the
0::/3 prefixes).  Or I might have wrong understanding of their
purpose, or wrongly interpreting the text.

Just a thought.

Alex

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 6 Feb 2002 11:20:35 +0100 (CET)

> simply because their vision of a network is different.

They don't need to - they can set the "universal" bit to zero and
use a number which is not from the IEEE space.
But when they do that they need to realize that RFC 3041 generates random
interface IDs in that space.

> purpose, or wrongly interpreting the text.

0::/3 is not intended for such use at all.

   Erik

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 06 Feb 2002 12:19:34 -0800

hi,

first of all, let me commend the design team for their excellent
work (the writeup is great).

Jari Arkko wrote:
> RFC. 

AGREE with the above. 

> Given that RR may not be sufficient in all situations or

DISAGREE. 

As agreed above, RR is the only mandatory protocol that 
needs to be specified in MIPv6. If there is only one 
mandatory mechanism, it does not need any specific 
selection method, eg. the "bit method".

I guess we all agree that "a better BU authorization" 
mechanism is not restricted to CGA alone. Whenever somebody 
specifies a new "BU authorization mechanism" _they_ need to 
specify how it is selected over RR. Perhaps, it would be best 
to avoid any reference to a "better" BU mechanims for now. 

Having a dependency (in MIPv6 doc) on specifying an 
extension in the IP address configuration in order to 
support a mechanism that is not deemed mandatory for MIPv6 
is counter-intuitive and would encumber the progress of 
MIPv6 specification. 

The specific advantages offered by the "bit method" 
themselves need discussion elsewhere (i.e., not coupling 
it with progressing MIPv6 spec).

> problematic to make CGA a mandatory requirement, however.

AGREE. and the "bit method" should be specified in this draft.

> performed on every binding refresh.

CAN TOLERATE (I would have preferred creating BSAs. but I guess
that opens up new attacks. so its fine)

> 2b. CN-------------->MN(CoA)

AGREE

> done e.g. using IPsec ESP with pre-shared keys.

AGREE

> every few hours or perhaps once a day.

AGREE. (but lets take up CGA separately).

regards
Vijay

---

From: "Jari Arkko" <[email-masked]>
Date: Wed, 6 Feb 2002 22:35:19 +0200

Thanks Vijay for your comments! I'll comment briefly the
one point where you had DISAGREE:

> mechanism is not restricted to CGA alone.

Agreed. 

> Whenever somebody 

Ah, I can see now that you just want the bit method moved from
one place to another. This would be logical, but I think what
we worried about was bidding-down attacks. Basically, since
we are not assuming any sort of global trust or pre-established
knowledge, it's pretty hard to know if the the RR request came
from a real node or the man in the middle. Thus, it seems security-wise
very useful or maybe even necessary to know from the addresses
what to do. Otherwise, once deployed RR mechanism might not be possible
to be upgraded anymore, since the resulting security in any case
be RR.

Of course, if you can come up with suggestions in this space
we could discuss them.

[One idea originally presented by Henrik Petander was also floated
in the design team that you could in theory use the bit method to have
two sets of nodes: All RR MNs, and the union of all CGA MNs and
stationary nodes. Thus, it would be evident that BU authorization
can't be tricked to move communications of stationary nodes.
I'm not sure yet if that would work, but it's an idea.]

Jari

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 06 Feb 2002 18:41:20 -0800

hi Jari,

four comments....

> to be upgraded anymore, since the resulting security in any case

1. The "1 bit method" seems to be designed with CGA as the 
only possible strong authorization mechanism for securing BUs.
However you have also agreed that other strong BU authorization
solutions are possible in the future. Has the design team 
looked at other signaling mechanisms to indicate the preferred 
mechanism by an MN or CN? Section 8 in Residual_Threats.txt 
does not have enough info as to why you chose the "bit method" 
over the other methods.

2. Also, please let us know what other RFCs (other dependencies) 
need to be changed to have this 1 bit in the IPv6 address?

3. Assume, I have more than 2 mechanisms for BU authorization 
(RR, RR+DH, RR+CGA, PKI, AAA). How does "1 bit" help here? 
For this, (IMO) the obvious thing would be a set of bits 
in the Binding Update. You dont have to specify this now. We 
can do this later using the reserved bits in the BU.

4. The following is from Residual_Threats.txt

	> - A mechanism for the MN to indicate on-line that it wants to
	>   use CGA and not RR. This assumes the RR attacker can't
	>   prevent the MN from seeing the RR packets. This, however,
	>   seems hard given that the attacker is on the CN-HA path.
	> 

I tried really hard to figure out why the above mechanism
is inferior to the "1 bit" method. If the RR attacker prevents 
the MN from seeing the RR packets, then you have RR itself 
failing. If RR fails, CGA also fails. Am I missing something 
very obvious?

regards
Vijay

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 7 Feb 2002 15:02:39 +0100 (CET)

> it with progressing MIPv6 spec).

Vijay,

We haven't managed to come up with a scheme where CGA can be completely(*)
added later without opening up a "beating down" attack where an attacker
on path between CN and HA could 1) claim to be the MN and 2) cause the
CN to accept a BU protected by just RR.

Thus the idea (which perhaps isn't written up that well) is to do
two things initially:
1) get a bit (or pattern of bits) in the low order 64 bits of IPv6 addresses
   marked as reserved.
2) have the MIPv6 specification say that when the HoA bottom 64 bits has
   this reserved bit/pattern then it MUST NOT accept a BU protected by RR.

If we can do the above, and only the above,
then we can later add CGA (or something else more secure that RR)
by having the MNs who wish to require the more secure scheme set the
bit/pattern in their home address.

Does the above description make more sense than what is in the writeup?

Does is make you change your mind?

  Erik

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 7 Feb 2002 15:32:12 +0100 (CET)

> does not have enough info as to why you chose the "bit method" 

I can see now that the writeup is a bit thin on these issues.
Hopefully this email can help explain at least my views of what went into
the thinking.

> need to be changed to have this 1 bit in the IPv6 address?

Depends what bit pattern we might want to reserve but (for reasons
relating the unknown future) it might make sense to reserve both of
these with the potential for using one or both of the for CGA or something
else in the future.

RFC 2373 defines the details of the format when the universal bit is set.
However, EUI-64 addresses assigned to interfaces never have the group bit
set. Thus I think it makes sense to reserve the combination
	universal = 1, group = 1.
RFC 2373 also talks about links without global identifiers, and this
is used in RFC 2472 (PPP for IPv6) and RFC 3041.
In order to have some spare space for potential future direction
I think it makes sense to also reserve
	universal = 0, group = 1
even though that means that RFC 2472 and RFC 3041 (and implementations of
those?) would need to be modified.

> can do this later using the reserved bits in the BU.

RR+DH seems to incur close to the same processing overhead as RR+CGA
while not providing much more security that just RR. MiTM is still possible.
Perhaps there is a subtle difference (I don't know for sure) that such a DH
MiTM requires seeing packets in both directions (i.e. that unicast routing
is somewhat symmetric between the CN and HA) whereas a RR MiTM does not require
this.

Infrastructure-based mechanisms might make sense in some cases.
I have doubts whether a PKI would ever carry accurate information about
what Home Addresses a given certificate has authority to create binding for.
So personally I think that a PKI can be used in addition to whatever BU
authorization mechanism there is (e.g. RR) to be able to provide corse
level distinction between "known friends" and "others".

I don't personally understand AAA-based authorization of binding updates would
entail and whether it would fit into the architecture of AAA that the AAAwg
is assuming to comment on that.

But up-leveling - the property that "the low-order 64 bits of the address
is allocated according to EUI-64" is currently encoded in the IPv6 address -
it is a property of the address.
The fact that "the low-order 64 bits is a <hmac/hash/prf> of a public key"
is also a property of the address, thus it would make sense to encode this
in the address as well.
The fact that a MN or CN uses AAA (or some other infrastructure) for 
pair-wise authentication and authorization is not a property of an IPv6
address.

> failing. If RR fails, CGA also fails. Am I missing something 

Example: attacker on the path between the CN and the HA.
Attacker can pretend to be the MN since it is on-path. Using the above
mechanism it can get the CN to accept RR-protected BUs even though the MN
actually only wants to allow CGA-protected BUs.

This is different than the bit being securely retrieved from the secure
DNS before the communication started (and if you don't have DNSSEC you
really don't care if you're communicating with the real peer or not :-)
and the CN refusing RR-protected BUs if the  bit is set.

   Erik

---

From: Francis Dupont <[email-masked]>
Date: Thu, 07 Feb 2002 20:52:01 +0100

=> not yet but I don't know what the design team want to do.

=> for instance.

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 07 Feb 2002 14:18:12 -0800

hi Erik,

comments below

> bit/pattern in their home address.

As I said before, my only problem is with this "1 bit method" in
the IPv6 address. when you say "pattern of bits", how many bits can 
you reserve in the IPv6 address to take into account all the stronger 
BU Authorization metods that could be specified in the future? As 
far as I know, I already need 3 bits to select a mechanism among 
5 mechanisms. It would be difficult to justify reserving enough 
bits in the IPv6 host id space so that Mobile IPv6 could select 
from among several BU Authorization mechanisms.

For CGA, maybe the "1 bit method" is the best selection mechanism.
And this should be specified as part of the "CGA for MIPv6" spec.

regards
Vijay

---

From: "Jari T. Malinen" <[email-masked]>
Date: Thu, 07 Feb 2002 15:20:28 -0800

Reading recent texts this came to mind as a comment.
It would be good to explain the bidding down attack
scope a bit more. If the relevant scope is to prevent
bidding down from authorizing BCE with a currently
used method x having higher priority than y, then
it prompts this logic:

Suppose we are using a simple rule in CN which
tags BCE telling how it was authorized and refuses
BUs with lower-priority authorizations during the
lifetime of a BCE but any time accepts authorizations
of the same or higher method. Legitimate MN is never
blocked from regaining the BCE nor can it lose it
when it needs the BCE. When legitimate MN is not
communicating, it should be enough for the CN
to expire unused BCEs injected by RR attacker
for the CN to be able to communicate with the
legitimate MN, and/or always start its sessions
with non RO data packet despite BCE.

When the true MN initiates the RO connection it chooses
a higher method and no RR attacker even from CN-HA path
can change that by RR during the lifetime of the BCE,
since it only accepts CGA or higher. The BCE can only
be refreshed by the higher method run by the original
MN during the time of the BCE being needed. If the attacker
can block those legitimate messages, it can tamper with
forwarding and do more harm even without MIPv6.

Something is obviously missing, can you make it explicit..

BR,

-Jari

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 8 Feb 2002 10:14:25 +0100 (CET)

Vijay,

> I would say RR+DH is a better BU Authorization mechanism over RR,
> but not as good as RR+CGA. So it is still an option over RR and 
> an MN should be able to select this mechanism.

The design team didn't find significant differences but perhaps we didn't
look carefully enough.
Do you have threats that RR+DH can handle that RR can not handle?

> If a MN's home address ever changes, then it gets a new certificate.
> Why wouldnt this work? IMHO, PKI + IKE + IPSec would work for a 
> few domains (eg a corporate network). And this should be the most
> preferred BU Authorization mechanism whereever it is available.

The details of why I think is unworkable in practise is a bit different
depending on the nature of the CA.
If you look at the case of a large commercial CA, how could they possibly
verify that a Home Address is assigned to box "owned" by [email-masked]
(where that string is the name in the certificate)?
Doing this in order to initially list the Home Address in the cert doesn't
seem tractable. Doing it every day when I decide to get an new RFC 3041
address seems even less likely to work.
What about the case when my ISP or company renumbers the prefix on my link -
how does the CA ever find out so that they can revoke that certificate which
now has a stale Home Address?

If the case is that there is a more local CA (e.g. a company or an ISP 
running their own CA) I think there are also hard problems in creating
the initial association between the certificate name and the Home Address
placed in the certificate. But it might be possible to throw people at the
problem (i.e. I would get a phone call asking for verification or
somebody would visit me in person).
But with a more local CA the question is how the trust is
established between a CN using one CA and a MN using another CA.

So I think this is a serious case matching the quote
	In theory there is no difference between theory and practise.
	In practise there is.

> Trust me. It will work. We will soon see AAA-based BU authorization 
> mechanisms. (again wherever possible, this should be more preferred 
> than RR, RR+DH, RR+CGA mechanism). 

I didn't say it could not be built. I'm questioning whether it fits into
the architecture of AAA (that architecture is that clients authenticate
to the infrastructure - and not that the infrastructure helps clients 
authenticate eachother. The latter sounds a lot more like a PKI. While it's
possible to make the AAA become a PKI as well it might not be the optimal
solution). 

I also have concerns about what it would mean
for RFC 3041 temporary style addresses (when a user wants to minimize
the relationship between the IP address used at the moment and
any longer term name associated with the user). I all fairness,
I think all infrastructure-based solutions (e.g. PKI and AAA) 
raise concerns in this area of enabling anonymity.

> Basically the above reinforces, what I had thought. The "1 bit method" 
> is very specific to RR+CGA mechanism. It does not help in any way
> to select the other strong BU Authorization methods. 
>
> I want to emphasize one point again. CGA is good for IPv6 and ND. I am
> not against it. And the "1 bit mechanism" is good for distinguishing a 
> CGA address from another address. But that does not make it the best 
> mechanism to select from a bunch of BU Authorization mechanisms.

I think you are correct on both of those points.

Question is whether that is a good thing or a bad thing.

If there was e.g. a baked spec on how AAA based authorization would work
at an abstract level (no need for packet formats) and with what assumptions
it might be possible to see what type of mechanisms would make 
sense for policy control in that space and how it would interact with
the MIP nodes (MNs and CNs) that are not part of that AAA infrastructure.
But until then at least me personally feel like I'm stumbling in the dark
when it comes to AAA-based authorization of BUs.

  Erik

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 8 Feb 2002 09:53:56 +0100 (CET)

Vijay,

Sorry for not being clear.
By "pattern of bits" as was just hinting that it might not be possible
to get one bit (leaving 63 bits to play with for CGA) but instead get
e.g. universal = 0, group = 0 i.e. leaving 62 bits for CGA to play with.

I think I responded to the "need more bits because there are more
mechanisms" in a later mail my yesterday.

> And this should be specified as part of the "CGA for MIPv6" spec.

Another mail I sent yesterday points out why the bit needs to be specified now
in order to prevent beating down attacks.

   Erik

---

From: "Jari Arkko" <[email-masked]>
Date: Fri, 8 Feb 2002 20:42:02 +0200

> Here is a simple proposal to allow selection of alternative BU authorization
> schemes. Perhaps you folks have already thought about it.. In any case, I would
> appreciate your feedback.

Thanks for your proposal! We should probably include it in a
new version of the writeup. Read on for the analysis...

> The objective is to securely indicate to the CN the MN's intention to
> use a "better BU method". For this, why not include a signed hash covering a
> "selector" byte in the RR messages ? For instance,
> 
> - the MN sends Nonce N1, and an 8-bit integer "selector"
> set to "better BU" mechanism in 1b.
> 
> - the MN sends Nonce N2, and a signed hash of N1, N2, the
> "selector" field and the MN's Public Key in 1a.
> 
> -the CN would verify the hash before accepting the method
> outlined in the "selector" field for BU authorization.
> 
> The selector field can take different values including RR only, RR+DH,
> RR+CGA etc.

This appears to have the following problem: an attacker, if he
is capable of defeating RR, must therefore be on the HA - CN
path. The attacker sends a spoofed 1a/1b with selector set
to "RR". CN believes this, and noone ever needed to break
public key hashes, as it would have been necessary in the case
of a bit in the address indicating that CGA should be used.

Naturally, the attacker would still have to be on the HA - CN
path, with all of its implications. 

Jari

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 08 Feb 2002 11:00:23 -0800

> path. The attacker sends a spoofed 1a/1b with selector set

where exactly is your attacker? if he is on the HA - CN path
he cant see 1b. and the selector goes in 1b. 1b also contains
a nonce, which the attacker cannot guess.

1b is MN (CoA) ------------ CN

unless the attacker is on the CN's link. I thought that was 
something we are not trying to solve.

Vijay

---

From: Rajeev Koodli <[email-masked]>
Date: Fri, 08 Feb 2002 11:02:23 -0800

Hi,

> of a bit in the address indicating that CGA should be used.

I didn't quite follow you here.. If the attacker changed the selector to "RR" while
the MN used RR+X, the hash would not match, right ? Why would the CN believe only
the selector (set to RR) ?

-Rajeev

---

From: "Jari Arkko" <[email-masked]>
Date: Fri, 8 Feb 2002 21:07:20 +0200

> something we are not trying to solve.

Ah yes, but the attacker does not have to wait for the MN to
actually send anything. He can just go ahead and claim CoA
is on the HA - CN path, and just create the necessary signaling
without ever involving the MN at all. It doesn't even have to be
an MN...

Jari

---

From: Rajeev Koodli <[email-masked]>
Date: Fri, 08 Feb 2002 10:03:40 -0800

Hello Erik and Jari,

Regards,

-Rajeev

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 08 Feb 2002 11:25:50 -0800

Jari,

Let me reason things a bit.

When the MN is active and has a active binding at the CN 
created through RR+CGA, an attacker cannot bid down. For
details, see Jari Malinen's mail that was sent out yesterday.

When the MN is active and is initiating RR+CGA as described
in Rajeev's mail, an attacker cannot bid down because
he cant see 1b.

You are saying that the attacker could create a binding
at the CN when the MN is not active, right? But I am saying
that when the MN comes back alive, it is going to initiate
RR+CGA binding at the CN (it WILL because it does not have
a corresponding Binding Update List entry for the CN). The
binding created by the attacker is invalidated.

So the "1 bit method" just prevents the following. It 
prevents the attacker from creating a binding at the CN 
when the MN is inactive. Also for this to work the CN has
to have obtained the MN's address through DNSSEC. Whats 
the big deal in this? Not worth modifying two RFCs for 
this extra protection.

Anything wrong in the above reasoning?

regards
Vijay

PS: for some reason, all the mails I have sent since 
yesterday are not making it to the mailing list. 
dont know why. could somebody please forward them 
to the mailing list?

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 08 Feb 2002 16:39:01 -0800

Hi Erik,

I am not sure if you have taken a look at the following draft.

http://www.ietf.org/internet-drafts/draft-le-mobileip-dh-01.txt

It uses RR+DH to create MN-CN security association. This draft 
also gives an example where DH method can take advantage of 
AAA (wherever available) to eliminate MiTM attacks that DH is
prone to.

Anyway, I dont want to get into a detailed discussion on how
PKI, DH or AAA can be used (maybe we can do it offline). But, I 
believe that there could be more than 2 strong BU Authorization
methods. I guess this where we disagree. You are not recognising 
anything other than RR and RR+CGA for the moment.

regards
Vijay

PS: I agree with you that there is currently no concrete 
proposal for the "other" BU Authorization mechanisms that I
am talking about. But by adopting this "1 bit method" (or 
2 bits as described in your mail), I fear there might be no
room for selecting these mechanisms later on.

---

From: Francis Dupont <[email-masked]>
Date: Sat, 09 Feb 2002 18:05:31 +0100

=> note there is a point where I DISAGREE with the CONCLUSION, i.e.
I believe the design team has missed an important point.
   
   1. INTRODUCTION
   ===============

   
=> I have three concerns in general:
 - the first one is purely philosophical and I wish to be wrong:
  we have not found the good balance between security and cost
  (in term of computing resources), I am afraid the market will
  find the proposals too weak (for RR) or too expensive (for CGAs,
  cf 2 2nd property). Of course the issue is hard because usually
  stronger security implied more computational resource consumption.
  But another detail can become very bad for the future of Routing
  Optimization (RO): the benefits are only for the MN but a significant
  part of the cost is for the CN. This is not economically viable
  in the general case (note that there is an interesting exception).
 - the second is about the procedure itself, there is a thread model
  and security requirement (TMRS) document: it is not used here! Both for
  gratitude for this work and for the clarity of the procedure as
  defined by the WG chairs, IMHO all details should reference the
  corresponding point in the TMRS and if something is not in the TMRS
  it should be added into the TMRS ASAP.
  [CLARIFICATION, CAN TOLERATE]
 - the last concern is about the possible use of "external" security,
  i.e. I can't find here a word about what one can do if one's already
  got for instance IPsec protection of all communications with proper
  (i.e. mobility aware) policies. In the same way, there is *nothing*
  about the MN-HA (aka Home Registration (HR)) security or Binding
  Acknowledgement (BA) security: something at least is missing in
  this introduction...
  [ISSUE, CAN TOLERATE]

   2. ALTERNATIVES
   ===============

   

=> [CLARIFICATION, CAN TOLERATE] (in fact I disagree but only
with the actual statement, not with the real idea).
The last statement is wrong because CNs can't offload computations
to HAs of MNs: CNs have no more reason to trust HAs than MNs,
this argument applies to any HA-based scheme (cf. Jean-Michel Combes).
So the property has no possible improvement for CNs in general.

=> [ISSUE, DISAGREE] I live in a country where software patents
are explicitely excluded by the law but with some pros. and
cons. pressures about them, so I can have a distorted view of
the IPR problem... My concern is about free softwares: I really
want to *never* see a BSD or Linux development stopped because
a standard is subject to IPR. In fact the problem is there is
no provision for free softwares in RFC 2026 10.3.2 (C) and we
rely more and more on free/open source softwares.

   
=> [CLARIFICATION, CAN TOLERATE] This point should be clearer
if BAs (and Binding Requests (BRs)) were taken into account too.
Note that I-D 15 has some security requests for BAs, perhaps
some of them for BAs of HRs.

   3. 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.

=> [CLARIFICATION, CAN TOLERATE] how long is not enough accurate,
i.e. units can be in time or in bytes/packets (cf. RFC 2401 4.4.3).
I recommend to use both and to expire on the first. In order to
make this as clear as possible, here is the whole reference:

>        o Lifetime of this Security Association: a time interval after
>          which an SA must be replaced with a new SA (and new SPI) or
>          terminated, plus an indication of which of these actions
>          should occur.  This may be expressed as a time or byte count,
>          or a simultaneous use of both, the first lifetime to expire
>          taking precedence. A compliant implementation MUST support
>          both types of lifetimes, and must support a simultaneous use
>          of both.  If time is employed, and if IKE employs X.509
>          certificates for SA establishment, the SA lifetime must be
>          constrained by the validity intervals of the certificates,
>          and the NextIssueDate of the CRLs used in the IKE exchange
>          for the SA.  Both initiator and responder are responsible for
>          constraining SA lifetime in this fashion.
>          [REQUIRED for all implementations]
>
>           NOTE: The details of how to handle the refreshing of keys
>          when SAs expire is a local matter.  However, one reasonable
>          approach is:
>            (a) If byte count is used, then the implementation
>                SHOULD count the number of bytes to which the IPsec
>                algorithm is applied.  For ESP, this is the encryption
>                algorithm (including Null encryption) and for AH,
>                this is the authentication algorithm.  This includes
>                pad bytes, etc.  Note that implementations SHOULD be
>                able to handle having the counters at the ends of an
>                SA get out of synch, e.g., because of packet loss or
>                because the implementations at each end of the SA
>                aren't doing things the same way.
>            (b) There SHOULD be two kinds of lifetime -- a soft
>                lifetime which warns the implementation to initiate
>                action such as setting up a replacement SA and a
>                hard lifetime when the current SA ends.
>            (c) If the entire packet does not get delivered during
>                the SAs lifetime, the packet SHOULD be discarded.

   This recommendation is
   
=> [CLARIFICATION, AGREE] The bit method is fine for CGAs because
as there is no implementation of the to come specs, the bit
method can be implemented before full MIPv6 itself.
=> [CLARIFICATION, DISAGREE] But the bit method doesn't work
for all other (perhaps unknown) mechanisms, so the argument
developped in the last statement of (1.) is only valid for CGAs.
This should be clearly explained in the MIPv6 RFC.

   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".

=> see the previous comment.

   This recommendation is based
   
=> AGREE

   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.

=> AGREE (but don't forget BAs)

   For CGA, the design team

=> can -> may?

=> [CLARIFICATION, DISAGREE] This statement makes some assumptions
   about the used scheme. CGAs provide a kind of authentication
   by signatures, this is very different from building a shared
   secret with Diffie-Hellman. The wording can, at least, be improved.

   1a. MN(HoA)--->HA--->CN
   1b. MN(CoA)--------->CN
   
=> [CONCLUSION, DISAGREE] (this is about 4 and 5 but I put it here)
An important case, both likely common in the future and with
critical vulnerabilities, is *not* addressed: mobile to mobile.
 - first argument: there is no reason to have only fixed CNs
   and RO can be very interesting (i.e. give far better performance)
   when the CN itself is mobile, for instance in the same network.
   (this is the important exception of my philosophical/first concern,
    IMHO this case is worth our consideration).
 - second argument: the RR (in)security is based on the fact
   the attacker should be near the CN, ideally on the HA-CN and MN-CN
   paths. This assumption is reasonnable for fixed CNs (if the attacker
   is in the core we already are in trouble without MIPv6) but
   not always for mobile CNs.
 The situation is symmetrical, if the mobile to mobile case is not
specially handled, vulnerabilities are doubled (i.e. both MN1->MN2
and MN2->MN1 BUs can be attacked). So the solution is to make
a special case which provides stronger security.
 Paths from MN1 to MN2 are:
  MN1->MN2
  MN1->HA1->MN2
  MN1->HA2->MN2
  MN1->HA1->HA2->MN2
The last one is very interesting: it is both the path used in
bidirectional tunneling mode (the other mode if triangular
routing is dropped) and a very safe path if HAs are near
the core (i.e. this cancels possible vulnerabilities from
wireless/cellular links where MNs are attached). Of course
I assume (5.): MNx<->HAx tunnels are encrypted for RR messages.
 This is not the place for detailed proposal but I'd like to
have a specific statement about this special case with some
messages using paths though the two HAs with a (6.)-like stuff.
I stop before to imagine how to provide RO^2 (:-).

   HA-MN tunnel

=> [CLARIFICATION, CAN TOLERATE] What about the MN-HA way?
Note that in many cases to provide the same protection in both ways
is not more expensive (in fact can be simpler) than to provide
it only in one way only.

   should be encrypted for the RR messages (but not
   necessarily for other messages on this tunnel).

=> [CLARIFICATION, AGREE] This has an impact about the BU format
(i.e. destination options don't make good IPsec selectors).

   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.

=> AGREE

   This could be done e.g. using IPsec ESP with pre-shared keys.

=> [CLARIFICATION, DISAGREE] Keys are SA keys (pre-shared is
not the right term) or IKE pre-shared key authentication mode?
In the second case the pre-shared key mode is known to have
*real* problems with mobile nodes.

=> AGREE

Regards

---

From: "Jari Arkko" <[email-masked]>
Date: Sat, 9 Feb 2002 19:52:58 +0200

Thank you Francis for your in-depth response! A couple
of quick responses below, I'll get to the rest later...

>   Acknowledgement (BA) security: something at least is missing in

I agree. We need to talk about the external security, as well
as the MN-HA security.

> So the property has no possible improvement for CNs in general.

True, though there's an important exception: MNs that act as CNs *can*
offload their CN-computations as well. I don't remember if we described this
in draft-roe, but it's doable at least.

>  not always for mobile CNs.

You argument seems right. But I need to think about this some
more.

Jari

---

From: Francis Dupont <[email-masked]>
Date: Sun, 10 Feb 2002 14:12:30 +0100

=> draft-ietf-ipngwg-addr-arch-v3-07.txt is supposed to be better.

=> I'd like to get these addresses reserved for universal addresses
not-based on IEEE standards (i.e. please wait I've written my IMEI I-D! :-)

=> I disagree for RFC 2472 but this is a detail.

=> my interpretation of the one bit method is you split u=0 into
u=0/g=0 and u=0/g=1, 0-0 becomes manual and RFC 3041, 0-1 becomes CGAs.
If the IPv6 WG doesn't raise strong objection, this is fine.

=> I agree, the concern is for other schemes.

=> so we have to support them.

=> I disagree, a good PKI doesn't need RR (i.e. it works without RR or
it doesn't work).

   I don't personally understand AAA-based authorization of binding
   updates would entail and whether it would fit into the architecture of
   AAA that the AAAwg is assuming to comment on that.
   
=> we are working on this (:-).

=> I agree but be careful in your deductions because the authorization
part of AAA can be "authorize to use this address". Another detail,
this is not fully true that we don't know the security properties
of CGAs because CGAs are related to anonymous Ho of HIP
(draft-moskowitz-hip-05.txt).

=> I agree, DNSSEC seems to be a required step to the secure Internet.

Regards

---

From: Francis Dupont <[email-masked]>
Date: Sun, 10 Feb 2002 14:43:02 +0100

=> you may think this is unworkable in practice in the general case
but I don't understand why you don't accept this for particular
cases. For instance DNSSEC can be used on reverse sub-trees of the DNS
(reverse: address to name/properties maps) and can solve the authentication/
authorization problem of Mobile IPv6 on the part of the Internet it applies.

   If you look at the case of a large commercial CA, how could they possibly
   verify that a Home Address is assigned to box "owned" by
   [email-masked]
   (where that string is the name in the certificate)?

=> easy, put this user_FQDN/RFC-822 address as the (Alternate)SubjectName
of the X.509 certificate pointed by the Home Address in DNSSEC.

=> please play with RFC 3041 too: to ask for both privacy and authentication
is a bit unfair in this discussion.

=> this problem doesn't exist for DNSSEC (i.e. DNS mechanisms deal with it).

   If the case is that there is a more local CA (e.g. a company or an ISP 
   running their own CA) I think there are also hard problems in creating
   the initial association between the certificate name and the Home Address
   placed in the certificate.

=> not for DNSSEC. My proposal to use the reverse tree is not neutral
(this is the good way because obviously we'd like to get properties
bound to the address).

   But it might be possible to throw people at the
   problem (i.e. I would get a phone call asking for verification or
   somebody would visit me in person).

=> the delegation mechanism of DNSSEC takes care of this kind of issue.

=> Certificates encode trust, a not-technical mechanism is needed for
this problem.

   
=> for mobile IPv6, AAA can provide:
 - local network access control (very standard)
 - remote network access control (new but this is only the result
   of the availability of an AAA infrastructure)
 - trusted-third party (same because the AAA infrastructure is a trust one).
AAA is a bit different than a PKI and perhaps more suitable (authorization
is builtin in AAA for instance).

=> I agree but anonymity is both not required here (as near everywhere
in the Internet) and the anonymity provided by RFC 3041 is questionable
(to be politically correct :-).

   
=> I share Vijay's concerns about the "1 bit mechanism".

=> it is not a bad thing if the "1 bit mechanism" is clearly dedicated
to further CGA introduction, but it is if the "1 bit mechanism" is
described as a general purpose mechanism.

   If there was e.g. a baked spec on how AAA based authorization would work
   at an abstract level (no need for packet formats)

=> there are three (two already published and the last one still been
worked on) but they are mainly about MN-HA security (i.e. HR security
in place of general BU security).

   and with what assumptions
   
=> so my question is that HRs are special BUs, do we develop a full special
case or are any solution good for HRs available for BUs too in favourable
cases? This seems to be Vijay's concern and I fully agree with him.

Regards

---

From: Francis Dupont <[email-masked]>
Date: Sun, 10 Feb 2002 15:02:27 +0100

=> in an answer to an Erik's message about this, I specified
we'd like to get both any kind of external security of the MN-HA/HR case
and a way to import this into the general BU case, i.e. I'd like
to keep the current "HR is just a special case of BU" style.

   > So the property has no possible improvement for CNs in general.
   
   True, though there's an important exception:

=> I finished by "in general" because I expected your answer.

   MNs that act as CNs *can*
   offload their CN-computations as well. I don't remember if we described this
   in draft-roe, but it's doable at least.
   
=> I am in favour to make the MNs that act as CNs a full special case
because its incredible number of possible nice specific improvements
(i.e. offloading to its own HA is only one among many).

   >  not always for mobile CNs.
   
   You argument seems right. But I need to think about this some more.

=> I am not in favour of mobile = wireless = cellular but in this context
you may not give the same level of trust to core networks and wireless
access infrastructures.
 The only counter argument to my advocacy for HA-HA path is this can
be considered as an infrastructure solution (imagine you can encrypt
the HA-HA path too).

Thanks

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 11 Feb 2002 14:10:40 +0100 (CET)

> authorization problem of Mobile IPv6 on the part of the Internet it applies.

DNSSEC wasn't intended to be a PKI last time I looked :-)

I don't claim I understand the issues involved in making DNSSEC for the
in6.arpa tree be a PKI providing certificates and implicit authorization for
binding updates. If you'd like to run this idea by namedroppers you'd get
better feedback than on the mobile-ip mailing list.
So I'd urge you to make a proposal there.

> is a bit unfair in this discussion.

With e.g. CGA you can provide a cryptographically strong proof that
you are the same as the Home Address without actually having to
say who "you" are.

So I don't think it is important to take into account the difference,
when proving address ownership, whether the address must or must not
be tied to a cerificate.
They have very different privacy implications.

>    of the availability of an AAA infrastructure)
If I understand what you are saying this is the same as what is
already being done with Radius - a remote (home) entity performs the
authentication,

> is builtin in AAA for instance).

Authorization of a client to the AAA is built it.
But this seems rather different than having the AAA infrastructure be an
intermediary between two clients (the MN and CN) of the AAA with the purpose
of gettting those to clients to trust eachother.

> (to be politically correct :-).

You don't think the ability to be anonymous is important or
you don't think the ability to be anonymous at the IPv6 address level
is important?

> cases? This seems to be Vijay's concern and I fully agree with him.

What is a "HR"?

  Erik

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 11 Feb 2002 14:57:09 +0100 (CET)

Jari,

You seem to be making the implicit assumption that a MN would always
immediately try to setup RO.
I think we want to keep the door open for MNs which e.g. perform some form
of flow detection before establishing the RO.
That seems to be problematic if the CN might have a BCE created by
an attacker using RR.

> with non RO data packet despite BCE.

The "starts its session" seems to imply that the IP layer, when choosing
whether or not to use a RR BCE, needs to be able to identify a new session
indepedently of the transport and application protocol.

For TCP and SCTP I can see us doing this, but what about some yet to
be invented protocol over (congestion controlled) UDP? Reliable multicast?
It seems impossible to make this distinction in general.

> forwarding and do more harm even without MIPv6.

If the attacker is actually on the CN - HA path it can presumably cause
that attempt to establish RO with CGA security fail by dropping
the relevant packets.

  Erik

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 11 Feb 2002 15:18:02 +0100 (CET)

> rely more and more on free/open source softwares.

Francis, 
I'm trying to understand what you disagree with.
You seem to disagree with software patents or at least have
concerns in this area, but that seems to be out of scope (we can't change
the legal situation for patents in this WG :-)

I don't think you disagree with the actual text i.e. that several IPR
claims have been made.

So do you think that 
1) we shouldn't take these IPR claims into account?
2) we should take these IPR claims into account?

> I stop before to imagine how to provide RO^2 (:-).

As far as I can recall the design team hasn't discussed this - at least
not in greate detail. I personally hope that we can make MN to MN binding
updates more secure by relying on the secure path between each MN and their
HA. In fact the BU3WAY spec presents one way to do this without adding
any more complexity to the exchanges but instead just making sure
that RR control packets sourced with a Home Address get reverse tunneled over
the secure tunnel.
So I personally agree with you that the design team should make 
clear recommendations in this space.

  Erik

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 11 Feb 2002 15:25:11 +0100 (CET)

> schemes. Perhaps you folks have already thought about it.. In any case, I
> would appreciate your feedback.
> 

Imagine an attacker between the CN and the MN.
Such an attacker can send packets to the CN claiming to want to use RR
for BU security and can claim that the CoA is either itself,
another address for which it is also on the path for, or a co-conspirator.

It can then do the above exchange without any problems.

Since the attacker is on the path(s) it can presumably also prevent the
packets from being delivered to the MN, thus the MN wouldn't be aware of
this.

   Erik

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 11 Feb 2002 15:32:07 +0100 (CET)

> details, see Jari Malinen's mail that was sent out yesterday.

I expressed some concerns with Jari Malinen's proposal earlier today
having to do with two assumptions:
 - that the IP layer on the CN know what is "start of a new session"
 - that RO will always be setup immediatly at the start of a new session
   (as opposed to the possibility of deferring RO until there appears
   to be a "flow" of packets that would benefit from the optimization)

> in Rajeev's mail, an attacker cannot bid down because

Is this the case when the CN already has a BCE for the real MN?

> binding created by the attacker is invalidated.

You are assuming that the MN will immediately setup RO.
When sending e.g. queries to a DNS server (a single request response) it
might not make sense to setup RO before the exchange.
What if the DNS servers (the resolvers) that the MN is configured to
use have bogus BCEs for the MN?
 
> the big deal in this? Not worth modifying two RFCs for 

Not only.
If the MN is active and reachable, but has not setup a BCE on a particular
CN then the attack could still succeed since the attacker is
on the path between the CN and HA (in order to attack RR) and it can
thus prevent packets from reaching the MN through its Home Address.

   Erik

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 11 Feb 2002 15:44:26 +0100 (CET)

> AAA (wherever available) to eliminate MiTM attacks that DH is

Yes, but I think this draft departs from the tradional model of AAA
in that it makes the AAA infrstructure a "pass through" as examplified
by the AAA sending out packets to the CN:
    *  Then CN's AAAh:

      -  forwards DH(CN), MAC(Ki) to CN

      -  verfies MAC(K1) and if valid, computes DH(MN), MAC(Kj)

The AAA was architected around the AAA being a service that could perform
authentication of clients on a global scale and pass back configuration 
information that carries no semantics in the AAA itself. 
What draft-le-mobileip-dh is proposing is to make the AAA aware of the
semantics of these extensions which means that the AAA code needs to be
modified on the servers. I'm not convinced this is the right path.
It might be better to just make the AAA servers an explicit PKI with 
cross-certificates etc.

Also, it wasn't clear from the draft how the AAA does the authorization
of an address.
Imagine I (NAI=[email-masked]) appear at some random ISP
and get authenticated.
The ISP assigned me a CoA (e.g. using RC 2462 stateless addrconf)
and I communicate with the AAA.
Is the assumption that my AAAh has a pre-configured list mapping NAI->home 
address for all nodes in sun.com?
What if my home network renumbers (mipv6 allows for this) - how does this
mapping get updated?
What if my MN wants to use a RFC 3041 home address - how does the mapping
in my home AAA get updated?

> room for selecting these mechanisms later on. 

I just think that they need to be selected using other means, but since I
clueless enough to not understand the big picture for infracstrcuture-based
BU authorization I can't speculate on how.

But a larger question which nobody has asked is whether the better CGA defense
against future attacks and less frequent HoA RR checks warrant the
additional complexity of CGA.

  Erik

---

From: Francis Dupont <[email-masked]>
Date: Mon, 11 Feb 2002 18:32:54 +0100

=> RFC 2538... DNSSEC is not a real PKI but is enough for this purpose.

   If you'd like to run this idea by namedroppers you'd get
   better feedback than on the mobile-ip mailing list.
   So I'd urge you to make a proposal there.
   
=> there are many messages about this in the IPsec mailing list
(DNSSEC was proposed in an opportunistic IPsec document).
And the new DNSSEC key distribution mailing list is both the best forum
and well known by namedroppers...

=> yes.

=> no, third trust-party: the MN and the CN trust the AAA so they can trust
each other (of course we have to explain what they trust about).

   
=> I believe the ability to be anonymous was never a concern for
the Internet architects and if it becomes a concern something better
than RFC 3041 will be needed. BTW only location privacy is listed
in the mobile-ip WG charter.

   What is a "HR"?
   
=> Home Registrations.

Regards

---

From: Francis Dupont <[email-masked]>
Date: Mon, 11 Feb 2002 19:01:01 +0100

=> I disagree about the consequences of this fact, not about the fact.

   So do you think that 
   1) we shouldn't take these IPR claims into account?
   2) we should take these IPR claims into account? <- this one of course
   
=> we shouldn't take the proposal (CGAs) into account until the IPR issue
is at least clarified, or we stand a good chance of losing our time.
I believe we are doing a dangerous bet about CGAs... Of course this
is out of our scope as technical persons.

   not in great detail.

=> this is exactly my concern.

   I personally hope that we can make MN to MN binding
   
=> so I'll switch for an agreement soon, shan't I?

Thanks

---

From: Alpesh Patel <[email-masked]>
Date: Mon, 11 Feb 2002 10:01:39 -0800

Peter,

Scott responded that this has been fixed and I should not file a ddts. I am
a
DE and not DT. Guess, you have fixed this issue. Wondering if you still want

me to load the image :)

thx
-a

Peter Xie wrote:

> Can you try this image and see if it still crashes?
>
> /tftpboot/ppxie/c3640-ik9s-mz.0110-pi4.dw15572sf
>
> Thanks,
> --Peter
>
> On Thu, 7 Feb 2002, Alpesh S. Patel wrote:
>
> > Team,
> >
> > In one of the images built off itd_flo_t_pi4, I used the local-address
> > keyword and associated with a loopback interface which did not exist.
> > This
> > crashed the box. I could reproduce this twice; am pretty sure nothing
> > else
> > was responsible. Can someone from your devtest try this out real quick.
> >
> > Thanks
> > Alpesh
> >

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 11 Feb 2002 20:43:33 +0100 (CET)

> and well known by namedroppers...

namedroppers or keydist - either one works for me.

> each other (of course we have to explain what they trust about).

From a trust perspective, yes, but that wasn't my point.

What I was trying to refer to is some abstract notion of information flow
where the model using AAA seems to make information flow from
	MN -> AAAh1 -> AAAh2 -> CN
Which is very different that the traditional model of
	MN -> AAAl -> AAAh and a reply AAAh -> AAAl -> MN
In the former case the AAA needs to know that it needs to contact the CN
at the other end, whereas in the latter case it is just the AAA returning
attributes.

Something that fits the traditional model better is to do more
of a PIC-like architecture where
 - CN is configured to accept certificates signed by AAAh2
   for the purposes of BU authorization
 - MN -> AAAh1 -> AAAh2 returns such a short-lived certificate to MN 
 - MN presents this to CN e.g. using IKE

> in the mobile-ip WG charter.

Times change. Back in the 1980 Internet security wasn't much of a concern
either.

>    > cases? This seems to be Vijay's concern and I fully agree with him.

I don't know exactly what is desirable for HR.
An "easy" approach would just be to use IKE + ESP for those, but that
means that MNs need to implement IKE.
Just using ESP with manual keys means that IPsec can't provide replay
protection but a simple sequence number in the HRs (or a cookie exchange - but
that adds a round-trip) would handle the replay protection for HRs.

  Erik

---

From: Michael Thomas <[email-masked]>
Date: Mon, 11 Feb 2002 12:24:28 -0800 (PST)

> that adds a round-trip) would handle the replay protection for HRs.

   This _could_ be provided by the MIP protocol itself.
   Indeed, if you don't use IPsec and do something
   specific to MIP, you'll have to provide replay
   protection anyway. If you simply require the 
   replay protection provisions for app-level
   security when you use manually keyed IPsec,
   you'd have equivalent security.
  
   That said, its arguable that manually keyed ESP
   should have some sort of replay protection
   scheme too since this is a common criticism of
   IPsec (eg, wanting the base protections, not
   wanting to require IKE too). This would be
   IPsec wg's baliwick though.
  
		Mike

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 11 Feb 2002 21:26:35 +0100 (CET)

>    This _could_ be provided by the MIP protocol itself.

Correct. That was what the reference to "a simple sequence number in the 
home registrations" tried to say.

  Erik

---

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 11 Feb 2002 12:35:25 -0800

> that adds a round-trip) would handle the replay protection for HRs.

To my understanding, we don't have to solve the problem of establishing
security associations between home agent and mobile node.  We never were
given that problem, and I hope it doesn't become an issue before we go
to Proposed.  It will be hard enough to solve the problems we have to
solve already.

Regards,
Charlie P.

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 11 Feb 2002 21:35:52 +0100 (CET)

>    mipv6 MUST implement and use. Mind you, I'm 

Mike,

I just realized I never responded to the above.

I agree that we need to come to consensus on the HA/MN part of security.
The design team was instructed by the chairs to work on 4 things and
we've focused on those.
Once those can be nailed down it is easier to talk about the HA/MN part
due to the dependencies between different pieces.

    Erik

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 11 Feb 2002 21:42:19 +0100 (CET)

> to Proposed.  It will be hard enough to solve the problems we have to

Well, I think IETF specifications should allow for independently
developped interoperable implementations.
To do this it seems like the mechanism used to secure binding
updates between MNs and HAs need to be specified.

But perhaps your use of the term "security association" is a more abstract
notion of establishing the trust relationship between MN and HA (e.g.
at subscription time) whereas I'm thinking of a "security association"
as the actual keying material, IVs, and algorithms used to secure the
traffic.

  Erik

---

From: Michael Thomas <[email-masked]>
Date: Mon, 11 Feb 2002 12:49:26 -0800 (PST)

> home registrations" tried to say.

   OK. If it's not obvious, I've been having a hard
   time keeping up with the list lately :-)

		Mike

---

From: "Jari T. Malinen" <[email-masked]>
Date: Mon, 11 Feb 2002 13:53:05 -0800

Erik,

- First, it might be good to motivate this discussion. It would
  be to see if an alternative method for the 1-bit method is possible.
  This because there are some problems with the 1-bit method mentioned
  by others including

  - the bit method locks us to one method, no much alternatives in the
    future nor room for replacement (even a chosen CGA method may need
    change, e.g. for better security or optimization, then the bit
    encoding needs to change again, so it may be not too good for even CGA)
  - the requirement for change is extensive for the bit alone, while also
    the CGA method itself is not standardized, requiring several yet not
    existing normative references to base MIPv6 and changes in RFCs.

> That seems to be problematic if the CN might have a BCE created by

The brief idea was formulated so that it looks like this but
looking closer it is not exactly so. It considers issues in
one particular idea of doing on-line signaling, but is here
for the case of illustration on-line signaling might be possible.

- There is no need to actually establish RO, just to do some signaling,
  to be precise, immediately after receiving the first non-RO packet
  with subsequent rate limiting not to do that for every non-RO packet.
  This could be a de-registration establishing the level of authorization
  and that MN wishes to do no RO, but e.g. bidir. tunneling, if desired.

- Or, one could add offline tag to support this case (an extension to DNS)
  which gives the minimum condition for the BCE making CN garbage collect
  too low priority BCEs and would be much more flexible for future
  change than address bit encoding and would require change to 1 place
  beyond base MIPv6 instead of many, just to give an example of
  an alternative to 1-bit which is a more "offline" method.

- Since it is not clear your example really is a relevant "present
  attack" against bidding down, (see my comment at end) one might
  consider what about "future attacks" (victim is not around when
  bidding down happens), leaving the CN-initiated traffic the relevant
  one to discuss. As with RR, garbage-collecting unused BCEs
  frequently (which would happen anyway in the case of "lower"
  method being RR). This limits the scope of the attack to something
  that could be considered insignificant enough, as one possible
  alternative.

> It seems impossible to make this distinction in general.

The "start session" option should be generalized as
the ability by CN to check whether a BCE was not set
up by a too "low" method. It could be based on recognizing
sessions (setting new flows could be one way), or also
to periodically send non-RO packets and a condition that
MN needs to respond to those with a BU (which can be
deregistration if one does not want to start RO now
or at all). This to invoke discussion looking more deeply
to generic locally standardizable on-line signaling
alternatives.

> that attempt to establish RO with CGA security fail by dropping

But this means that the CN - HA path is not essentially different
securitywise for RR from RR+CGA, hence making it irrelevant whether
bidding down signaling is dropped since _no_ online signaling
can then really work. This actually includes the bit method. A
CGA address cannot then be delivered to CN (even DNSSEC can be
then disturbed amounting at least to a DoS attack against
CN-initiated connections). That's why tampering with forwarding
is not a very fruitful case for the analysis, you can most
likely kill any bidding down mechanism or signaling that such
mechanism guards when CN does not statically know the lowest
method acceptable.

BR,

-Jari

---

From: "James Kempf" <[email-masked]>
Date: Mon, 11 Feb 2002 14:08:47 -0800

I have read through some of the traffic on this
last week while I was on vacation, but
here are my opinions and some additional
comments.

> 3. RECOMMENDATIONS

CAN TOLERATE

Given the seeming urgency of the need for a decision,
and the lack of clarity about CGAs, this seems like the
best solution for the time being. However, RR depends
on the security of the routing infrastructure, and
given that it is easy for an attacker to mount
an attack on the last hop and pose as a router
on multi-access links, I view RR as a stopgap
solution until a more general solution is
available for securing IP signaling. CGAs are
a possibility.

One comment: in the discussion there seemed to
be some confusion about the "bit method" of
reserving an address class for addresses that
are not secured via RR. I assume that what
is meant here is exactly that, and that the
bit combination to be specified will not
be used to specify that CGAs  must be used
but some future, to-be-decided IP signaling security 
protocol which *might* be CGAs.

Is that correct?

Also, I support the idea (which came up in the discussion),
of having the BU security RFC be separate from the
base MIPv6 RFC. This is more modular, and will
simplify introducing a more powerful IP signaling
security technology like CGAs when the IETF gets around
to specifying it.

> problematic to make CGA a mandatory requirement, however.

DISAGREE

I think there needs to be some discussion on how to secure
IP signaling in general. I think CGAs are one possiblity, but they
have some disadvantages, including the aformentioned
IPR restrictions. I would like to see a method of securing
IP signaling be developed that has wide applicability
(BUs, securing IPv6 ND, paging, etc.), and not
something that is restricted just to MIP. Otherwise,
every working group is going to have to go
through the same process the MIP group
went through, and will come up with their
own solution. The expense and complexity of
implementing one off solutions for securing
every IP signaling protocol will far outweight
the expense and complexity of CGAs, IHMO. 

Also, though the design team hasn't yet specified exactly which method
will be used for securing BUs, I have a difficult time
seeing RR as a widely applicable method. So I would
oppose having a separate RFC at this time strictly
for BU security using CGAs.

That said, I do believe that a more powerful mechanism
is required for securing IP signaling and I believe that
when such a mechanism is developed (if it ever is),
the RR spec should be obsoleted and an
RFC written which describes how to use that
mechanism for MIP.

> refreshed or updated with RR. 

AGREE, with the proviso that if an IPSEC SA already exists,
it should be possible to use it.

> performed on every binding refresh.

DISAGREE

I don't believe anything should be said about CGAs until
a specification is complete about securing IP signaling
in general.

> 2b. CN-------------->MN(CoA)

CLARIFICATION

I can't claim to have examined this in detail,
but this seems like an aweful lot of signaling
potentially going over the Internet, and
runs the risk of congestion
control dropping the packets.
What about the transport protocol? UDP is clearly at risk.
UDP with some reliability mechanism? TCP?
SCTP? This looks like an aweful lot of signaling,
every one of these is an opportunity for something
to go wrong. If either 1a or 1b is dropped, then
recovery may take a long time.

In any event, this is going to slow down MIP
handover by orders of magnitude. A scalable
LMM solution becomes even more critical.

AGREE

> every few hours or perhaps once a day.

DISAGREE

Again, a generalized IP signaling security protocol is better,
IMHO.

            jak

---

From: Jari Arkko <[email-masked]>
Date: Tue, 12 Feb 2002 00:42:02 +0200

>     encoding needs to change again, so it may be not too good for even CGA)

It has been suggested that including the algorithm/key type/cga type
in the hash that generates the CGA address would suffice to distinguish
between all different types of CGA-like schemes. That is,

    interface id part = hash(public key + ADDRMETH_CGA_CGA1 + RSA + MD5)

or similar. In addition, I believe all infrastructure-based BU authorization
solutions can be made to work with the selection being done by the
infrastructure, not a bit in the address. For instance, assuming you
protected BUs with PKI-driven IPsec, your policy data base (possibly
distributed from a central point) would dictate for which addresses
you require the IPsec protection.

Jari A

---

From: "James Kempf" <[email-masked]>
Date: Mon, 11 Feb 2002 15:02:56 -0800

> you require the IPsec protection.

I don't see how this would allow the CN to determine what the algorithm
is if the hash is irreversable.

Also, this assumes precisely the currently proposed, IPR-protected
CGA algorithms. It is possible that the another type of algorithm
which provides cryptographic security on addresses might have
different requirements on the interface id part, that would be
incompatible with using this kind of scheme.

I don't claim to have any solutions to the problem of identifying
the algorithm. I can see how the bit method would work to
identify whether or not RR should be used, though
I think it is limited and weak for that purpose. Is it really necessary
now
to figure out how to identify the cryptographic algorithm,
or do we just need to know whether RR should be used
or not?

If the latter, then maybe we can figure out some other way
rather than using the bits.

            jak

---

From: Rajeev Koodli <[email-masked]>
Date: Mon, 11 Feb 2002 16:40:23 -0800

> It can then do the above exchange without any problems.

How does the attacker see N2 in 1a ?

> packets from being delivered to the MN, thus the MN wouldn't be aware of

Isn't this a different problem ? The attacker could also drop plain RR packets..

-Rajeev

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 11 Feb 2002 18:09:00 -0800

Hi Erik,

>    to be a "flow" of packets that would benefit from the optimization)

I guess Jari has replied to those concerns.

> Is this the case when the CN already has a BCE for the real MN?

it does not matter. Just follow this simple rule. If there is
an existing binding created by RR and the CN gets a new RR message
from MN saying that the MN wants to do RR+CGA, it deletes the
existing binding (the attacker cant see the two nonces N1 and
N2, unless the attacker is on the CN link, which we dont consider).
The CN then does RR+CGA with the MN.

Nonce N1 and selector go in one message. Nonce N2 and the hash 
(N1 + N2 + selector) goes in another message. An attacker cant
see both these messages unless he is on the CN's link or the MN's
link. Please, for a moment, see this mechanism as a generic 
mechanism to select any BU authorization methods based on RR.

> use have bogus BCEs for the MN?

I could also argue, that a mobile node does not have to use 
the home address option for a DNS query. It could send a 
normal packet with the source address being CoA. this was 
always an option in the mobile node.

You are actually basing your argument on the assumption
that the attacker could somehow figure out that a particular
mobile node is about to set up a very short lived session
with a particular correspondent node. And the attacker gets
"into position" (basically figure out the route that packets
will take) to launch the RR attack.

regards
Vijay

---

From: Francis Dupont <[email-masked]>
Date: Tue, 12 Feb 2002 10:05:14 +0100

=> in my mind AAA is mainly usable when the CN is the HA (so the HRs
(Home Registrations) as a special of BUs discussion). I don't believe
in AAA for general CNs, this should be even harder than a global PKI...
But if I understand your model there is a second interesting case:
CN is mobile and/or in the same home domain/domain cluster.

=> this is the model I am working on (MN-AAAl-AAAh-HA).

=> I agree, the h1/h2 model needs more work if we'd like to try it.

=> yes, a credential based approach seems to be good (the credential is
the short-lived certificate).

=> at least to get a open door in the BU stuff?

=> I've tried this (with AH which is a bit easier than ESP as discussed
in a zillion of messages in lists). It works but it is terribly heavy
and slow: IKE configuration is a nightmare, certificates are lost
in first exchanges because of the path MTU discovery and UDP transport,
IKE does *not* like message lost, etc. It takes many seconds to get the
SA pair when the MN boots in visit. In fact the only good point is
this works and was tested between independent implementations.
This is why I work on AAA based solutions as an alternative (AAA is
far better but is not a candidate for a general solution).
BTW IKE is available on very small boxes, Palm Pilots and Psions
for instance.

=> there is a fine but subtle text in the MIPv6 I-D explaining the difference
between anti-replay protection and sequencing... My concern about ESP
with manual keys should be this is simply near unusable in practice.

Regards

---

From: Francis Dupont <[email-masked]>
Date: Tue, 12 Feb 2002 10:13:47 +0100

To my understanding, we don't have to solve the problem of establishing
   security associations between home agent and mobile node.

=> I agree but today the BU recommendation makes no provision for
something not based on RR [+ CGA] for this. IMHO this issue is
only a problem of the scope of the recommendation (this should be
in the introduction but is not).

   It will be hard enough to solve the problems we have to solve already.
   
=> the first step to a solution is an accurate definition of the problem,
isn't it?

Thanks

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 12 Feb 2002 10:59:50 +0100 (CET)

Rajeev,

> How does the attacker see N2 in 1a ?

In one case because the attacker is the entity sending 1a and 1b
specifying the real HoA of the MN.
It could do this every second or so so that even if the real MN
was doing BUs they would be overridden in less than 1 second.

Also, an attacker on the same link as the CN would see both 1a and 1b.
Assuming that the "leaf" links are the least secure (imagine a CN in
the IETF WLAN/terminal room) this would be a likely source of attacks.

> Isn't this a different problem ? The attacker could also drop plain RR

I was jumping ahead - I thought the issue about the real MN being able
to "veto" the on-path attacker claiming to be that MN was one of
the underlying points. My point is that such a "veto" assumes a bunch
of things including that the on-path attacker can't prevent packets
from being delivered.

  Erik

---

From: Alexandru Petrescu <[email-masked]>
Date: 12 Feb 2002 11:52:42 +0100

>    I don't think you disagree with the actual text i.e. that several IPR

What are the IPR claims that have been made?  What patents?  What
yet-to-be-filed disclosures?

> => I disagree about the consequences of this fact, not about the

I guess the consequences are proportional to the breadth of the claims
in the respective patent(s).  If there's a pile of them covering every
aspect of CGA's and all posible methods for implementing then there'll
be trouble in getting CGA's standardized.  If however the claims are
limited to certain aspects then it's always possible to "design
around", right?

Also, the conditions under which those patents are licensed matter a
lot.  If one company has all patents in this area and licenses all of
them for no charge, then it's fine, I believe.

Alex

---

From: Jari Arkko <[email-masked]>
Date: Tue, 12 Feb 2002 12:52:08 +0200

> is if the hash is irreversable.

The point was that if the algorithm is included in the hash, then the
MN can provide the algorithm in its request, and the CN can verify
the algorithm by verifying the hash. (And no, I'm not sure we need
anything to be able to change algorithms, but I just used "algorithm"
as an example.)

> incompatible with using this kind of scheme.

Maybe. But -- if you have a cryptographic security on addresses,
wouldn't it be reasonable to assume that such a non-CGA mechanism
would also allow similar hashing? For instance, a symmetric-key
based CGA-like scheme would allow this as well. I'm not sure a
symmetric key scheme would be useful, but again this is just
an example.

> rather than using the bits.

I think the latter is precisely what the intention is: these
addresses are set aside for RR in a manner that we can later,
without fear of bidding down, use something else later. (Henrik
Petander also proposed that the bits would be selected so that
stationary nodes could not be claimed as mobile.)

I eager to hear if you have another solution than using the
bits. I'm just not sure there can be much else, given that
all the information we have in the RR case is (a) the request
and (b) the address.

Jari

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 12 Feb 2002 15:07:08 +0100 (CET)

>   This because there are some problems with the 1-bit method mentioned

I do agree it makes sense exploring other methods here.

>     encoding needs to change again, so it may be not too good for even CGA)

For CGA itself I don't know how significant the problem - requires more
understanding of the evolution of crypto algorithms than I have.
One could take two different approaches for defining the semantics of
the bit:
 - An address with the CGA bit set has an interface ID which is the bottom
   64 bits of a hash of a public key (with the universal and group bits
   set to indicate the CGA property)
 - Same as above but instead of "hash" say SHA-1.

One question is what the tradeoffs are between the two descriptions.
If the hash is not specified how would a peer know which hash to
apply to verify the public key - interface ID relationship and what
are the security issues in communicating that insecurely to the peer?
If the hash is specified what is the likelyhood that there will be
a new more secure hash (when truncated to 62 or 63 bits) in the future
thus there will be a need to move to using that hash.
Note that more secure hash functions will appear e.g. hashes
producing longer results - the question is whether the fact that the result 
must be truncated change the likely evolution.
What has history tell us about the latter question?

>     existing normative references to base MIPv6 and changes in RFCs.

I think the change to reserve the bit might be as small as one sentence
in each of RFC 2373, RFC 3041 and RFC 2472.
Having MIPv6 not allow RR when the bit is set is presumably a short paragraph
in the mipv6 spec.
So I don't know what you mean by "extensive" - the amount of time
to complete the above?
[AD hat on: I think reserving a bit in the interface ID makes sense 
independently of CGA - there might be some great new idea in the future that
could benefit from a bit even if CGA doesn't need one.]

>   and that MN wishes to do no RO, but e.g. bidir. tunneling, if desired.

Hmm - that would seem to imply that the CN would need to keep state oer
MN even when RO is not used.
That state might be just one bit (e.g. don't accept RR BUs) but it would
still require separate state maintenance.

>   an alternative to 1-bit which is a more "offline" method.

Yes, but since applications today sit between the DNS (i.e. getaddrinfo())
and the protocol stack (socket interface) in many systems this would
require changes to the APIs to be able to pass this information.
Also, today typically only the initiating end of communication does a DNS
lookup. The above would require the accepting end of communication to
also do a DNS lookup - since that end can't securely know the DNS name
of the peer it presumably needs to do a reverse lookup to find the hostname
and then look for the "tag" record in the forward DNS tree.

>   that could be considered insignificant enough, as one possible

I think there are present bidding down attacks. (See below).

> to generic locally standardizable on-line signaling

Sure sounds complex. The periodic recheck is basically saying that you
allow DoS blackhole attacks for a time less than the period.
If this period is longer than the time for upper layer protocols (be it
transport or application protocols) to give up the DoS attack has
been successful. If that causes the recheck to happen every 10 seconds
this might be a lot of background chatter on the wire.

> mechanism guards when CN does not statically know the lowest

An on-path attacker can of course drop all the data packets and accomplish
DoS that way.
I don't understand your point about DNSSEC - if DNSSEC is used by the CN
to find the MN's HoA then the CN will know for sure the setting of
the bit.

But I think it would be useful to pop up a level when analysing the residual
threats. Per the DT document CGA protected BU's are strictly more secure
than RR protected BU's when it comes to e.g. future attacks and the need for
RR checks against the HoA in the context of attackers that are on the path.

Question is whether this matters in the large scheme of things for MIPv6.
Such an attacker can just drop data packets as a DoS attack and can
already (by virtue of being on the path and thereby being able to prevent RO)
see all the data packets (and modify them unless they are protected by
higher layer security like IPsec or TLS).
So does CGA, as we understand it today, really make a significant enough 
difference for MIPv6?
(I continue to believe that CGA would be a useful tool in authrizing e.g.
MLD joins for anycast groups, preventing DAD and address resolution spoofing
on a link, but those approaches might not need a bit in the address - to
early to tell.)

   Erik

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 12 Feb 2002 15:20:46 +0100 (CET)

Vijay,

> mechanism to select any BU authorization methods based on RR.

Yes, but I suspect an attacker on the CN's link is a common high-level
threat today with 802.11 and other multi-access links. (Using spoofed
router advertisements or neighbor advertisements, if the L2 can't be
spoofed, in order to see all packets.)

> always an option in the mobile node.

I don't think my arguement assumed that CoAs couldn't be used for
such short-lived connections. If I made that implicit assumption please
point it out to me.

In general the tradeoffs whether to use a CoA for short lived communication
vs. the HoA depends on lots of factors like predicting the length
of communication and the likely time of the next move.
There are likely to be cases where using a HoA makes sense due to unknown
in the above time factors even though the number of packets exchanged might not
be sufficient to warrant a RO.

> will take) to launch the RR attack.

No. The session doesn't have to be short lived.
It is the fact that I don't think we should assume that all sessions 
immediately go to RO (due to short-lived or few-packet sessions existing) 
that makes the attack possible.

If the CN can't know when a new session has started and for how long during
the start of a new session it should ignore RR-protected BUs (because 
the MN might want to use a CGA-protected BU) then the attack is possible.
And hardcoding the policy for what is a "new session" and "how long"
wouldn't be good for interoperability.

  Erik

---

From: Francis Dupont <[email-masked]>
Date: Tue, 12 Feb 2002 15:51:28 +0100

=> oh! What want details? The only concrete fact is Christian Huitema's
declaration at the last meeting (IPR stuff is sent to the IESG)

   
=> I do *not* want to become a lawyer!

=> perhaps the patents are only for protection, i.e. in order to avoid
a patent from someone else with licenses, etc. I have not the answer.

Regards

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 12 Feb 2002 16:14:06 +0100 (CET)

> => this is the model I am working on (MN-AAAl-AAAh-HA).

By "this" you couldn't mean the same as mine above, because they are very
different. In mine the path stops at AAAh and in yours the HA is the end.

Thus yours is the same as the yet-to-be-standardized diameter-mobileip model,
which I think is less than ideal.

Some while your idea is different than involving the CN as in 
draft-le-mobileip-dh-01.txt it still doesn't match the traditional architecture
for AAA as implemented by Radius today.

> => I agree, the h1/h2 model needs more work if we'd like to try it.

But same for your model - the AAAh needs to contact the HA.

> the short-lived certificate).

Good.

In that case do you see a need for AAAh to invoke the HA?

> => at least to get a open door in the BU stuff?

Do you see a closed door anywhere?
I don't. The protocol would need to get worked out, and follow the normal
standards track criteria. (clear, useful, etc)

> BTW IKE is available on very small boxes, Palm Pilots and Psions

Would AAA be better because diameter runs over SCTP instead of IKE
over UDP?
Others have claimed in the past that you don't want to run diameter on
the client due to size? performance? concerns.

  Erik

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 12 Feb 2002 17:04:26 +0100 (CET)

> yet-to-be-filed disclosures?

In draft-roe-mobileip-updateauth-01.txt there is an Ericsson IPR notice.

In Salt Lake City Christian Huitema stood up in the mobile-ip meeting
and said something about Microsoft having IPR.

That is all the information I have - I don't know if there are patents,
or patent applications and whether any such applications have been published.

  Erik

---

From: Alexandru Petrescu <[email-masked]>
Date: 12 Feb 2002 17:16:22 +0100

>  In your previous mail you wrote:
> 

> declaration at the last meeting (IPR stuff is sent to the IESG)

IIRC, Christian's declaration was something rather vague (MAY).

I did search public patent databases and it's difficult to me to
identify relevant patents on CGA's.  That's why I'm asking here.

If the patents are not yet issued, or are being now filed, or anywhere
on their way to show up in the public databases, it still means that
they have only recently been authored and this might raise "novelty"
controversies, since those things have been discussed long ago
publicly.

That's one of the reasons I don't fear that much the "CGA is patented"
argument.  Or someone please prove me wrong.

> => I do *not* want to become a lawyer!

Neither do I!

Alex

---

From: Michael Thomas <[email-masked]>
Date: Tue, 12 Feb 2002 08:32:33 -0800 (PST)

> the client due to size? performance? concerns.

   Just as a note, IPsec != IKE. You could use KINK
   instead and all of Francis' criticisms go away.

	       Mike

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 12 Feb 2002 17:36:48 +0100 (CET)

> protocol which *might* be CGAs.

If we go the path of the bit method the idea would be that RR-protected
BUs would not be accepted when the bit is set in the peer's HoA.

If we can come up with other schemes that can be expressed as a
property of the interface ID in the HoA then, as Jari pointed out
with including additional information in the hash/prf/mac
the actual details of the property and the protocol/algorithms used
for securing things could be expressed securely.

> security technology like CGAs when the IETF gets around

But having a common specification for MIPv6 which includes route optimization
probably will increase the rate at which correspondent nodes will
implement route optimization.
So there are pros and cons here.

In any case, it should be possible to specify new methods as separate
specifications. The IETF does that all the time.

> for BU security using CGAs.

Why don't you think RR will be widely applicable? Too many packets?

> it should be possible to use it.

Clarifying question: do you mean that if an IPsec SA exists
carrying the BU over that SA should be sufficient and no RR other BU
specific protocol is needed?
Or do you mean that the IPsec SA should be used in addition to the RR
checks?

The former interpretation has authorization problems.
Just because the CN has an IPsec SA with a peer that has a certificate
mbox=[email-masked] doesn't say anything what HoA's the peer
can issue BUs for.

> recovery may take a long time.

Since this is a single-shot (transmit one packet - is no reply retransmit)
application using a protocol which performs better under streaming conditions
(large amounts of data to transmit) doesn't seem to buy anything.
It might make sense to do RTT estimation so that when a binding is refreshed
it can use a reasonable RTT estimate based on how quickly the response arrived
for previous BU exchanges.

Agreed.

   Erik

---

From: Francis Dupont <[email-masked]>
Date: Tue, 12 Feb 2002 17:52:20 +0100

=> to return a credential (your model?) or to use AAA for the transport
(my model) is a matter of taste, I don't believe we have very different
opinions.

   Thus yours is the same as the yet-to-be-standardized diameter-mobileip
   model, which I think is less than ideal.

=> I like the diameter-mobileip model but I don't like aggressive modes,
i.e. not transport of the BU, not key distribution, etc. Look at
draft-dupont-mipv6-aaa-01.txt ...
   
   Some while your idea is different than involving the CN as in 
   draft-le-mobileip-dh-01.txt it still doesn't match the traditional
   architecture for AAA as implemented by Radius today.
   
=> I explicitely rely on the existence of an AAA infrastructure which
is not implemented today.

=> yes, in my model the HA is an AAA agent.

=> if you don't do that, you need another exchange. Basically
you can do three things:
 - get only the credential from AAAh (three RTT, MN<->AAAh for the
  credential, MN<->HA for the SA establishment, MN<->HA for BU/BA).
 - simple piggy-backing (two RTT, MN<->HA for the SA establishment,
  MN<->HA for BU/BA)
 - aggressive (one RTT, MN<->HA for BU/BA)
I don't like the last one because I don't trust AAA servers for everything:
they are good for network access control (i.e. authentication and
authorization of addresses, same than for CGAs but for whole addresses)
and transport. With a piggy-backed Diffie-Hellman exchange between
the MN and the HA nothing more is needed).

=> BU authentication == RR [+ CGA]

=> but the form of the current BU authentication recommendation is closed,
for instance I am very surprised we are not flooded by messages about
"I already have a good IPsec SA, how can I protect the BU with it"...
(there should be a flu epidemic in the Silicon Valley, or we have
bored them to near death :-)

=> this is a joke, isn't it? But I believe you are right. Some stupid
problems with IKE come from the use of UDP...

=> argh! I agree the model should be more accurate: there is an AAA
attendant between the MN and the AAA local server. Diameter is not
run between the MN and the attendant (read my draft :-), only
between AAA agents.
(PS: for the question I expect you'll ask: I don't know yet, read... :-)

About the real topic of this discussion: what is scheduled in the future
document about alternative BU authentications, including all the known
infrastructure based and/or for home registrations?

Regards

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 12 Feb 2002 10:03:01 -0800

Hi Erik,

> spoofed, in order to see all packets.)

There are mainly two kinds of CNs. Web servers and Mobile nodes. 
We can safely rule out an attacker on a Web Server's link. MIPv6 
is not your biggest concern in this case. In the case of the 
mobile nodes being CNS, any session initiated would through
their home address (through their Home Agent). If the tunnel
between the CN (a mobile node) and its home agent is protected
then we can rule out the attacker in this case too.

Lastly there are fixed CNs. that means somebody hacking into 
the network on which there are fixed CNs. Again MIPv6 is not
your biggest concern here.

So, lets not worry about the attacker being on the CN's link
and able to see both messages (1a and 1b). IMO, this is a 
resonable assumption to make.

Vijay

---

From: Francis Dupont <[email-masked]>
Date: Tue, 12 Feb 2002 19:02:53 +0100

Just as a note, IPsec != IKE.

=> I agree but IKE is the only generally available key exchange protocol
for IPsec.

      You could use KINK instead

=> KINK is fine even not generally available: I looked at KINK when
I developed the first version of my AAA-based stuff but today I prefer
to use HIP as the model (granularity of HIP is more suitable for the
context of Mobile IPv6).

       and all of Francis' criticisms go away.
   
=> note they are facts (the fact it was painful and slow, and the fact
it worked).

Regards

PS: for this usage the best IPsec stuff is SKIP (BTW I can't find
a RFC with the SKIP specs) but it is not enough available.
(SKIP was proposed by Jim Bound in a private discussion)

---

From: "James Kempf" <[email-masked]>
Date: Tue, 12 Feb 2002 10:13:04 -0800

The public patent databases only have filed patents starting in January
2000 and granted patents back until 1996. I found a filed patent
involving a CGA-like scheme from Ericsson but I could not find the
Microsoft patent, so I think it was probably filed before January 2000.
There is a patent database that one can search, http://www.delphion.com,
for a minimum $75/month fee, but I have not yet had the time to do the
search.

            jak

----- Original Message -----
From: "Erik Nordmark" <[email-masked]>
To: "Alexandru Petrescu" <[email-masked]>
Cc: <[email-masked]>; "Erik Nordmark"
<[email-masked]>
Sent: Tuesday, February 12, 2002 8:04 AM
Subject: Re: (CONCLUSION) Re: [mobile-ip] BU Authorization method:
design team recommendation

---

From: Francis Dupont <[email-masked]>
Date: Tue, 12 Feb 2002 19:26:15 +0100

=> ah!ah! Good attempt but James' question is "that SA *could* be
sufficient...".

=> RR uses more than one address and IPsec SAs have some issue with
multiple address (cf. SA lookup using *the* destination address in
inbound processing, RFC 2401 5.2.1).

=> so if an IPsec SA already exists with the proper policy?

   may issue BUs for.
   
=> this is a policy issue (IPsec knows what is a policy but details,
including how to use policies, are not in the IPsec WG scope).
And the policy can be encoded in the certificate: your point is
the certificate is not always enough (I parse your statement as "is
never enough").

   Since this is a single-shot...

=> I still have to read the Home Address Option recommendation to see
if Binding Acknowledgements (BAs) are now mandatory but at least
some new error codes are to be added in BAs for fast recovery
(something like "I don't receive the message Xy").
   
Regards

---

From: "James Kempf" <[email-masked]>
Date: Tue, 12 Feb 2002 10:27:41 -0800

Erik,

> for securing things could be expressed securely.

Since the question of whether to accept the BU is restricted to
the BU itself, what's the problem with putting some kind of
indication in the BU about which method should be used?

> specifications. The IETF does that all the time.

I think having route optimization in the base spec is fine, I was just
talking about the security method, if that can be separated. It probably
would have been better to separate out route optimization a year
ago when this controversy arose, but now it is too late. And, I
agree that having it in the base spec will probably speed adoption.
The base spec just needs to be written modularly.

> Why don't you think RR will be widely applicable? Too many packets?

By "widely applicable" I mean beyond Mobile IP. I think RR probably
will see some use in Mobile IP, but it is not entirely clear that it
will be widely deployed. As you say, the amount of signaling
involved is onerous, I suspect this will be a damper on use, especially
over the Internet.

And, more seriously, I fear that it may lead to serous pressure for
quick standardization  of "routing proxy" style LMM solutions when
people
start realizing how expensive secured BUs are.

> mbox=[email-masked] doesn't say anything what HoA's the peer

Good point. Since the IPsec SA adds nothing, perhaps it is unnecessary.

> for previous BU exchanges.

Sure, but it still doesn't solve the problem of what happens when
congestion
causes a router to drop a packet, particularly 1a and 1b. This could
make
BUs very expensive in terms of time.

            jak

---

From: "Jari T. Malinen" <[email-masked]>
Date: Tue, 12 Feb 2002 12:06:14 -0800

Erik,

Thanks for your comments. However, there are some
issues important for short-term progress..

Seems you are basically saying there is no need for
alternatives to CGA as of the bidding down method
is concerned. Perhaps even no need for variations of CGA.

But, to have RR+CGA as the only method beyond RR causes
that there actually is *no* higher method at all for
non-CGA addresses. Furthermore, this supposedly generic
bidding down prevention method prevents attempts to have
anything for non-CGA addresses in the future, either. Even
introducing better variants of RR is not supported.

Hence, I must conclude that even if no acceptable alternative
mechanisms are found, there should be concern taking the 1-bit
to the base MIPv6, since this is not a general-purpose
mechanism. Having the bit-method standardized elsewhere should
not preclude its use since once CGA address subspace is mandated,
any node supporting CGAs should implement this anyway and
there enforcement of the bit method should follow naturally.
But until that happens, this shouldn't stop making MIPv6
go forward.

But I am happy to continue this discussion at a later stage.

Some remarks below.

> > - the bit method locks us to one method, no much alternatives
> >   in the future nor room for replacement (even a chosen CGA
> >   method may need change, e.g. for better security or
> >   optimization, then the bit encoding needs to change
> >   again, so it may be not too good for even CGA)

> One could take two different approaches for defining the
> semantics of the bit:
>  - An address with the CGA bit set has an interface ID which
>    is the bottom 64 bits of a hash of a public key (with the
>    universal and group bits set to indicate the CGA property)
> One question is what the tradeoffs are between the two
> descriptions. If the hash is not specified how would a peer
> know which hash to apply to verify the public key - interface
> ID relationship and what are the security issues in communicating
> that insecurely to the peer?

You basically say: if it is not at all considered possible
to carry selection info online (which I disagree), there
is an issue to carry it even as Jari A. mentioned:
have it in the hash and tell in the signaling which
hash is used. The same concerns should apply to that
signaling making James's comment on undecodability
of the hash containing the method a valid remark.
Also, I wonder if CGA is really designed for permanent
home addresses.

> What has history tell us about the latter question?

Do not know about that, but are you saying there is
possibly no need to change the hash? Maybe it's
a result of the limited amount of bits available for the
hash in CGAs rather than no future for new methods.

> > - the requirement for change is extensive
> 

Can't comment here too much other than note some RFC changes
are needed. Also, some analysis on CGA and its specific uses
would not hurt before making it a fundamental part of the IPv6
addressing architecture.

I agree that there are many ideas on different properties of
the address that could be encoded into IPv6 addresses..

[discussion on on-line method]
> require changes to the APIs to be able to pass this information.

Or then not, depending on where the lookups you mention below
are done.

> and then look for the "tag" record in the forward DNS tree.

Or do the last two above from the stack without involving the
application, when doing fwd/B cache lookup. But these are
speculations on whether alternatives to 1-bit were possible.

..
> this might be a lot of background chatter on the wire.

Note that the ability to do DoS attack should be compared
against what you can do against higher methods. I am not
suggesting that frequent checks, just the ability to
recover from false BCE. To compare DoS, for CGA,
you can block DNS requests from the CN. It will not learn
the HoA nor the bit telling which method to accept.

> to find the MN's HoA then the CN will know for sure the setting of

You can DoS the 1-bit if the DNS query itself can be blocked,
saying the flag even there is passed on-line, though not in
the RR or BU signaling.

> RR checks against the HoA in the context of attackers that are on the path.

Given RR was changed to separately check direct and indirect
path, can you specify the non-future (on-path?) attacks against RR
if the attacker cannot block messages of the victim?

> So does CGA, as we understand it today, really make a significant enough

This is what I try to understand.

> on a link, but those approaches might not need a bit in the address - to

I also think it may have potential, but this would
merit more discussion..

BR,

-Jari

---

From: Michael Thomas <[email-masked]>
Date: Tue, 12 Feb 2002 12:32:43 -0800 (PST)

> DNSSEC wasn't intended to be a PKI last time I looked :-)

   There's a difference between being a PKI and
   presupposing a PKI. I think that DNSSEC assumes
   the latter. While I think it's perilous in
   general to posit large scale PKI's, if the net
   were ever to have one, DNS seems like a pretty
   likely suspect considering that it already 
   provides a top down namespace. Whether we'd
   want ICANN in charge of a global PKI is another
   argument, of course...

		Mike

---

From: Michael Thomas <[email-masked]>
Date: Tue, 12 Feb 2002 12:42:10 -0800 (PST)

Francis, 

My only point is that we not equate the base level
crypto with the keying. It's well known that IKE
has lots of flaws, and those are being worked on
from several fronts (KINK, JFK...). I think its
also pretty well agreed upon that the base level
2401 model is not broken, and that any changes
there are likely to be evolutionary, rather than
revolutionary (nuke AH, AES, nat traversal,
kernel/app credential API).

		      Mike

---

From: Rajeev Koodli <[email-masked]>
Date: Tue, 12 Feb 2002 13:08:51 -0800

Hello Erik,

> was doing BUs they would be overridden in less than 1 second.

I think this can be solved by requiring the CN to verify the home address
ownership prior to verifying the "selector hash". This is reasonable since the
BU authorization protocol (i.e., CGA)the MN is trying to use is tied to proving
address ownership anyway.

> the IETF WLAN/terminal room) this would be a likely source of attacks.

While this is valid, the problem scope is wider.

Regards,

-Rajeev

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 13 Feb 2002 01:16:19 +0100 (CET)

> (my model) is a matter of taste, I don't believe we have very different

I know we have different opinions on this point - the models are different.

> => BU authentication == RR [+ CGA]

Huh?
I've gotten the message that the MIP WG wants to get MIPv6 secure enough
so that it can go to proposed standard.
I don't think you're proposing that we delay this until there is some
additional approach involving the AAA.
So how does having a "do no harm" way of securing BUs prevent there from
developping other ways to secure them?

> bored them to near death :-)

Perhaps they see open doors?

> problems with IKE come from the use of UDP...

No. It is a direct response to your point about IKE not performing well
while AAA performing better under the same assumptions.
Both protocols as I understand send a request and wait for a reply
(and then repeat).
So what makes their performance differ?
Does IKE over UDP have a 10 second retransmit timer while SCTP/TCP
have an initial retransmit timer of 2? 4? seconds?

> infrastructure based and/or for home registrations?

"scheduled"?
The WG does need to come to consensus on how to secure home registrations.

I'm assuming the WG neither wants to hold up the MIPv6 specification
while infrastructure-based methods are developped, nor prevent such methods
from being developped and added to the stew.

  Erik

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 13 Feb 2002 01:39:57 +0100 (CET)

> indication in the BU about which method should be used?

The only issue is how to securely communicate this information to the peer
so that a MiTM can't force it to use less secure methods.
Jari Arkko's suggestion to include the loose notion of algorythm/method
into the hash as well as including that information in the BU messages
would solve that problem.
But this still assumes that the IPv6 interface ID is a hash of a public key.

> involved is onerous, I suspect this will be a damper on use, especially

Are you thinking about Seamoby and LMM type stuff?
For those creating BSAs might make more sense.

> BUs very expensive in terms of time.

Sure, having 5 packets instead of 1 increases the probability of at least
one of them being dropped.
But even with current model of a the single BU packet it might get dropped 
which would cause delays.

  Erik

---

From: "James Kempf" <[email-masked]>
Date: Tue, 12 Feb 2002 17:02:56 -0800

> But this still assumes that the IPv6 interface ID is a hash of a
public key.

Hmm, now I am confused. I thought that the idea was not to try to
force security against MiTM attacks, because that could not be
completely
assured for RR anyway. Or maybe some MiTM attacks can be secured
and others can't? I agree that Jari's method of a loose inclusion of the
algorithm in the hash would work, but I would rather not constrain
the address suffix at this point, since a future CGA-like method might
be impacted.

> For those creating BSAs might make more sense.

I'm thinking about securing paging and maybe other kinds of
IPv6 signaling, like ND. I think CGAs  or something similar
may have some applicablity here, RR certainly doesn't. Or
maybe BSAs, though that seems too heavyweight.

As for LMM, I assume the same RR would need to be done
with an LMM agent, unless the MN was prepared to
trust the local network and not do so. Or use a BSA,
as you state. A BSA would be alot better.

            jak

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 13 Feb 2002 02:18:05 +0100 (CET)

Francis,

I don't think there exists current PKIs that can provide
a strong relationship between an IP address and a certificate.
That doesn't mean it is impossible to develop such a PKI.

But until such a PKI exists it would seem prudent to provide implementors
and users of MIPv6 with accurate information on security issues, and not
pretent that something which looks like "IPsec policy pixie dust"
solves the problem.
(Yes, "IPsec policy pixie dust" is the next step after "IPsec pixie dust"
runs out :-)

> (something like "I don't receive the message Xy").

OOps - I think the DT forgot to make a conclusion on the BA part.

  Erik

---

From: Francis Dupont <[email-masked]>
Date: Wed, 13 Feb 2002 13:48:55 +0100

Huh?

=> this is the direct effect of the lack of a context description
in the introduction of the BU recommendation. I know this doesn't
really reflect the opinion of the design team but in place of
a BU for random CNs recommendation you produced a BU recommendation...
And the 1 bit method is another example of the lack of openness
(opening?) in the wording.

=> we know the target so I believe the problem is only in the form.

=> it should *not* prevent from using other ways to secure them.

=> the number of exchanges, the size of messages, the complexity of
crypto operations, ... many things are a bit different.

=> the retransmit timer is based on the RTT but in the case we discussed
about the RTT is not yet known for the first exchange which should not
have large packets... I believe you are already convinced that SCTP/TCP
is better even on first packets than any raw heuristic for UDP, aren't you?

   "scheduled"?

=> I maintain.

=> what we need is the list of necessary security properties (easy,
this is already in the mobile IPv6 I-D), a way to provide it
(a MAY for something which can work or better was proved to work)
*and* explicit possibility for any mechanism which can/shall provide
the needed security properties. To be allowed to use them for common BUs
will be fine (this is the reversed argument of "RR [+ CGA] secures BUs
but doesn't apply to the HR special case).

=> so we agree about everything at the exception of a minor point:
at least one infrastructure-based method already exists: IPsec
(with IKE, KINK, etc) so please give an easy way to add something
to the stew (a statement with careful wording should be enough).

Regards

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 13 Feb 2002 14:13:30 +0100 (CET)

> => it should *not* prevent from using other ways to secure them.

We're in violent agreement on that.

> crypto operations, ... many things are a bit different.

But that has presumably some relationship to the resulting security.
True that IKE might be too complex but if comparing the son-of-ike 
proposals against AAA-based SA establishment I would think
they would have the same number of messages and same computational complexity
to accomplish the same security.
If not it seems like AAA-based SA establishement would have some magic
potion that should be shared with the son-of-ike folks.

And if AAA-based SA establishment can't provide the same level of security
that son-of-ike SA estblishment can, then I think we should be very concerned.

> is better even on first packets than any raw heuristic for UDP, aren't you?

No - not for a single request-response interaction. 
E.g. Single DNS lookups over UDP are better than over TCP - less packets and 
less residual state. Sure, the implementation of the retransmit timer logic
becomes application protocol specific instead of shared e.g. in TCP
which places more responsibility on the application protocol and developper.

Of course, when there is either a need to have multiple outstanding messages
(as opposed to a request-wait-for-response model), when the requests or 
responses are larger than what fits in one datagram, or when there will be
a long conversation, then SCTP/TCP makes more sense.

> to the stew (a statement with careful wording should be enough).

For home registrations I personally think IPsec is a very good fit.
But I think you are referring to using IPsec to secure BUs to CNs as well
in lieu of using RR. Are you?

The fact that there isn't an automatic way to establish the authorization
policy in the CN case makes me wonder how wise it would be to do that.
(Yes, the policy can of course be manually created by people with a good
understanding of the authorization issues, but that wouldn't help mere
mortals.) I'd feel differently about this if/when there is work in the IETF in
using DNSSEC on the ip6.arpa tree to store certificates or public keys
since then there would be a way to automate this.

But it seems to be mostly you and I having opinions on this.
I'd also be interested in what others think.

   Erik

---

From: Francis Dupont <[email-masked]>
Date: Wed, 13 Feb 2002 16:36:06 +0100

=> not only they exist but when the IKE phase 1 uses address identities
(very common, the default mode of every IKE implementations I know
because it is needed for pre-shared keys in main mode) the address
must be the subject(Alt)Name of the certificate. This is checked
for all compliant IKE implementations and all good implementations
check too if the address in the identity and the address used for IKE
messages are the same (a trivial attack if not performed).

=> fortunately (:-)!

=> yes, there are better positions than FUD or hype... (:-)
Don't forget that the "road warrior" case is supported by many IPsec
implementations so this is more a question of how protocols are (mis)used
than about protocols themselves.

=> I'd like to know the opinion of the DT about BA security requirements
(BA of HR must be authenticated, but other BAs?)

Regards

---

From: "Jari Arkko" <[email-masked]>
Date: Wed, 13 Feb 2002 18:26:13 +0200

> (BA of HR must be authenticated, but other BAs?)

It seems that you are right about the HR_BA: if a BA could
be forged, an attacker could cause an *unnoticeable* DoS by
preventing a BU from getting through and then forging a
response... hmm... except that if we *encrypt* the BU and it
has a random cookie. So, we need either (a) authenticated
BA OR (b) BU encryption AND BU/BA cookie.

In the CN case, the MN must in any case be prepared for
its BCE being thrown out for resource or other reasons,
and the effect of the attack is the same as for that. Therefore,
it seems that at most the attackers can cause performance
problems but not a full DoS. I would say we need CN_BA
authentication if we get it easily, but if we have to pay a price
in some form to get it, we shouldn't bother.

Jari

---

From: Francis Dupont <[email-masked]>
Date: Wed, 13 Feb 2002 18:35:13 +0100

=> so this topic is closed.

=> yes of course. DoS resistance, identity protection, ... can/should
be different.

   True that IKE might be too complex but if comparing the son-of-ike 
   proposals against AAA-based SA establishment I would think
   they would have the same number of messages and same computational
   complexity to accomplish the same security.

=> agree

=> the magic potion is from a small village of Brittany (:-)

   And if AAA-based SA establishment can't provide the same level of security
   that son-of-ike SA establishment can, then I think we should be very
   concerned.
   
=> I don't believe in 100% equivalence (i.e. there are some reasons to
work on the two protocols). AAA can have an advantage if AAA *and* SoI
are required (this is the KINK argument in fact).

=> this is the only case and you have to assume no cached knowledge
(i.e. it should be the very first exchange).
As I don't like the idea of SA establishment in a single exchange in
this case (because the security cannot be as strong as I'd like), and
you too (:-), SCTP/TCP should be better.

   E.g. Single DNS lookups over UDP are better than over TCP -

=> BTW DNS is the only application in this case (:-). I expect
you'll never say the same thing for NFS...

   less packets and 
   
=> I still wait for a TCP like in applications as good as the real one,
and you loose the sharing too.

=> one time I believed in TTCP...
To come back to DNS, the retry stuff is very different between the server
(for the "recursive" feature) and the resolver. BTW usually the resolver
is a *stub* resolver (:-).

   
=> I'd like to get IPsec for HRs (we agree) and as HRs are special cases
of BUs to be allowed to use same things for BUs in the general case
(aka random CNs). As the security requirements for HRs are stronger
than for BUs, there is *no* security issue with my demand.

=> HAs have exactly the same authorization needs (even more in fact).

   mortals.)

=> I understand your concern, you can add warnings in the RFC about
this but please don't use extreme measures to avoid this authorization issue.

   I'd feel differently about this if/when there is work in the IETF in
   using DNSSEC on the ip6.arpa tree to store certificates or public keys
   since then there would be a way to automate this.
   
=> the problems of DNSSEC are mainly operational so the work is mostly
done outside the IETF. It will be the same when the AAA infrastructure
will be setup. You should believe this is good for the IETF.

=> we are in the same timezone too.

=> I'd like to get the feedback from people who'd like to deploy
mobile IPv6 (I expect concrete proposals, perhaps neither AAA nor
IPsec/IKE).

Regards

---

From: "James Kempf" <[email-masked]>
Date: Wed, 13 Feb 2002 09:37:24 -0800

Erik,

> they would have the same number of messages and same computational
complexity
> potion that should be shared with the son-of-ike folks.

I agree that the difference in message traffic between AAA-based SA
establishment and IKE or Son of IKE based SA establishment is probably
going to be in the level of percent and not orders of magnitude. The
major
attraction of AAA-based SA establishment is that ISPs have existing
AAA infrastructure that one could see being upgraded to support
AAA-based SA establishment, while IKE based SA establisment will
require a whole new infrastructure. In addition, ISPs can leverage AAA
for other purposes, while IKE is single purpose. Hence, the investment
makes more sense. This is a completely practical argument, however,
it has nothing to do with the technology.

> that son-of-ike SA estblishment can, then I think we should be very
concerned.

Certainly agree.

> since then there would be a way to automate this.

Well, the issue here is that one might want to secure BU traffic with
nodes in the foreign network, such as routers or LMM agents, and
therefore setting up an SA when the MN comes up in the foreign
network, then using it would make lots more sense than going through
the RR messaging each time the MN changed its point of attachment.

But, yes, I agree that it doesn't make sense for an arbitrary node
in the Internet.

            jak

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 14 Feb 2002 12:27:56 +0100 (CET)

> messages are the same (a trivial attack if not performed).

I having a hard time to parse the above.
It seems like you are saying that 
	when the IKE phase 1 uses address identities the addresses must be 
	checked

That seems very obvious and not surprising.

But IKE can also be used with phase 1 address identities.
For instance the IKE certs I use right now have
        Subject Name: <C=US, O=Sun Microsystems\, Inc.,
CN=[email-masked]>
                Subject Alternative Names:
                        email = [email-masked]

The problem I've pointed out in the past is that I don't see how
existing ways of doing PKIs can ensure that an IP address in the 
subject altname actually is actually the IP address assigned
to the node and that can be tracked as the node and/or site renumbers etc.

You are pointing out that should a PKI exist that can not only mechanically
produce such certificates, but also guarantee that the subject altname IP
address is assigned to the holder of the cert, they can be used.

I believe both of the above are true and independent.
So are we in violent agreement that while the mechanisms in IKE work
when using such certificates I can't get such a useful certificate from
existing commercial PKIs (like Verisign etc)?

> than about protocols themselves.

What does that have to do with the subject at hand?
My laptop certificate doesn't (and can't) use an IP address as a suject altname
because the IP address is different depending on where I connect.

   Erik

---

From: Michael Thomas <[email-masked]>
Date: Thu, 14 Feb 2002 17:14:58 -0800 (PST)

James Kempf writes:
 > AAA-based SA establishment

In fact, IPsec can leverage AAA in two ways:

1) XAUTH
2) KINK

The former is deployed, but the latter is a lot
cleaner. Recall that it's the subscriber database
that's actually important. There is no fundamental
reason you couldn't put a Kerberos protocol head
on an existing AAA database, just like you can put
a DIAMETER protocol head on that database. 

	   Mike

---

From: Francis Dupont <[email-masked]>
Date: Sat, 16 Feb 2002 17:34:03 +0100

=> this is not so obvious (from time to time someone asked in the IPsec
mailing list) and there is an easy interesting case.

=> the exception is this: a certificate which says nothing about addresses.
I've seen some answers (reading IKE implementation documentations/sources):
 - forget the check (BAD)
 - reject the certificate (very common: you should get the identity
   in the subject(Alt)Name)
 - resolve the DNS name (correct for a FQDN identity, very abusive
   for an user_FQDN identity as in your example)

=> this is a problem of how to do a PKI.

=> more, if such a PKI doesn't exist then the common default IKE
configuration doesn't work.

=> I agree, one (mine) is a practical requirement, the other (yours)
is how to fulfill the requirement.

=> I can't talk about commercial PKIs (not enough money to use them).
I create my certificates using OpenSSL (derived) tools and patch them
(i.e. add missing subjectAltNames) using OpenBSD certpatch tool.
The PKI mechanisms are supposed to deal with renumbering but
my plan is to use DNSSEC (which has a built-in name or address to public
key binding) as soon as it becomes usuable.

=> the "road warrior" case is your laptop case.

   My laptop certificate doesn't (and can't) use an IP address as a
   suject altname because the IP address is different depending on where
   I connect.
   
=> so your certificate has no subject(Alt)Names bound to an address
*and* you don't use an address as the phase 1 identity (and this
identity has to be one of the subject(Alt)Names). Usually
this is a special case in policies and there are some restrictions
(for instance the "road warrior" should not be a security gateway).
I can't see the problem: I believe this is only misunderstanding,
my clause is: PKIs can bind addresses to certificates, this kind of
bindings has a clear semantics but PKIs should not always bind addresses
to certificates.

Regards

---

From: Francis Dupont <[email-masked]>
Date: Sat, 16 Feb 2002 17:40:52 +0100

1) XAUTH
   2) KINK

=> IMHO Kerberos and DIAMETER/AAA are two orthogonal extensions/
improvements of the Unix login/password we used 20 years ago.

Regards