Subject: RE: [mobile-ip] Binding Authorization data for Binding Update to Home Agent

From: "Hesham Soliman (EAB)" <[email-masked]>
Date: Sat, 12 Oct 2002 11:17:05 +0200

Hi Charlie, 

  > "Hesham Soliman (EAB)" wrote:
  > 
  > > => This proposal seems to allow two different ways of
  > > securing BUs to the HA: IPsec or binding authorisation 
  > data, right?
  > > What is the advantage of having two different methods?
  > 
  > The advantage of having the possibility for Kbu used for
  > authentication of Binding Updates to the home agent is
  > that a home agent and mobile node can use a predetermined
  > security association to authenticate Binding Updates.  

=> But they can do that already with IPsec. Have I
missed something ?
draft-ietf-mobileip-mipv6-ha-ipsec-00 already allows
for manual and dynamic keying. 

Hesham

---

From: gabriel montenegro <[email-masked]>
Date: Mon, 14 Oct 2002 02:12:45 +0200

> for manual and dynamic keying. 

Yes. I don't think we need a third way (ESP and AH being the
first two) in the base MIPv6 spec. But I'm fine with the usual
weasel wording to futute-proof other uses of binding authorization
data. Any such future uses would rely on other specs
independently (though perhaps parallel in time) from the base MIPv6 spec.
Is BAD to home absolutely necessary for base MIPv6? I don't
think so. In the interest of moving forward, I suggest we
reject this issue as a MIPv6 issue. Interested folks can
continue to work on it clear away from the critical path
for the MIPv6 base spec.

Independently of this, I noticed the new intermediate version
already "features" this change. It seems
like we've been here before, so at the risk of repeating
what has been said before: Please don't put any *non-editorial*
changes that have not been properly discussed *previously* on
the mailing list into drafts (including intermediate versions).
Putting stuff in to initiate discussion means they will remain
in the document by default, as it relies on everybody
being alert and on their toes to take it out if consensus is
not reached. This reverses the correct way of doing things.

-gabriel

---

From: Charlie Perkins <[email-masked]>
Date: Sun, 13 Oct 2002 19:13:24 -0700

gabriel montenegro wrote:

> Is BAD to home absolutely necessary for base MIPv6?

It is necessary to allow manual configuration of security associations
between mobile node and home agent in the same way as is done
today in Mobile IPv4, which is manifestly simple and effective.

> not reached. This reverses the correct way of doing things.

That sentence was not distributed.  Maybe you are being
premature in your criticism.  It would be nice if you didn't
do that.  I sent that sentence to you and Jari with the indicator
that maybe we should raise an issue on the mailing list before
putting it in the specification.  It's simple enough that it could
be considered an editorial change, and I have always thought
that manual configuration MUST be possible between home
agent and mobile node.  In fact I definitely still think so.

Regards,
Charlie P.

---

From: gabriel montenegro <[email-masked]>
Date: Mon, 14 Oct 2002 09:32:46 +0200

> today in Mobile IPv4, which is manifestly simple and effective.

Couple issues:
- yet one more way of doing the same thing (manual SA configuration
	between HA and MN).
- does not provide a way for RR signaling to be encrypted between
	HA and MN (which is really important for securing RR)

> agent and mobile node.  In fact I definitely still think so.

You're absolutely right, this version of the draft was not
distributed to the alias. I got confused with the previously
distributed intermediate version. My bad.

I apologize, Charlie.

Perhaps I shouldn't post at 2am...

-gabriel

---

From: Michael Thomas <[email-masked]>
Date: Mon, 14 Oct 2002 08:08:55 -0700 (PDT)

I agree whole heartedly with Gabriel.

	Mike

---

From: Michael Thomas <[email-masked]>
Date: Mon, 14 Oct 2002 08:17:26 -0700 (PDT)

It is not at all clear that manual keying is all
that useful as it requires permanent shared state
between the two nodes for replay protection. This
is a sticky problem and solving it ultimately
sends you down the key management path. I agree
with Gabriel's position that anything which
proposes to something different than the base
IPsec mechanisms should be done in a new draft so
that it can be considered on its own merits.

	    Mike