Subject: [mobile-ip] New authentication scheme in Mobile IPv6 draft revision ...-14

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 26 Jul 2001 12:42:29 -0700

Hello folks,

Somehow, the e-mail address on this note got truncated, so
I am resending to this list.

Regards,
Charlie P.

-------- Original Message --------
Subject: New authentication scheme in Mobile IPv6 draft revision ...-14
Date: Thu, 26 Jul 2001 12:28:13 -0700
From: "Charles E. Perkins" <[email-masked]>
Organization: Nokia Research Center
To: Bill Sommerfeld <[email-masked]>
CC: [email-masked]
References: <[email-masked]>

Hello Bill,

Draft revision ...-14 incorporates the authentication data as part of
the Binding Update option itself.  I thought that this modification
was essentially mandated by Jeff Schiller's comments at the last IETF,
and the surrounding discussion about use of IPsec vs. various
destination options.

One good thing about this arrangement is that it allows the verification
of the Binding Update authentication data to happen independently of
any IPsec requirement between the mobile node and the recipient of the
Binding Update.  To me, this seems like a good thing, and I am hoping
that you would agree.

> This is a *consequence* of the issue I pointed out yesterday: namely,
> that if you allow for traffic on a connection/flow to contain a mix of
> encrypted and unencrypted packets, you open yourself up to various
> nasty denial of service attacks, and IPsec cannot provide useful
> guarantees to upper layers.

Could you make a small description about how the attacks work?

I would have thought that IPsec should be applied depending on the
kind of socket opened by the application, but maybe not...

>> if piggybacking a BU was the problem, we could have solved
>> it long back. just disallow piggybacking. anyway its a 'MAY'
>> in the current draft. you dont lose much by not piggybacking
>> the BU.
> 
> I disagree.  If it's a "MAY", then folks will build implementations
> which always piggyback, which will cause interoperabilty problems with
> IPsec implementations (such as Solaris's) which do per-connection
> policy checks.

Doesn't this problem go away entirely in draft ...-14?

Regards,
Charlie P.

---

From: Mohan Parthasarathy <[email-masked]>
Date: Thu, 26 Jul 2001 13:53:45 -0700 (PDT)

Charlie,

You still want to have the possibility of using IPsec between MN and
HA. In that case the i would assume that some of the fields mentioned
in section 4.4. will be zero. In Section 4.4 Authentication requirements,
it does not talk about IPsec at all. It will be needed if we still
think that we may allow IPsec between MN and HA. Section 10.2 still
talks about Outbound IPsec processing. It looks a bit confusing to me.

-mohan

---

From: Michael Thomas <[email-masked]>
Date: Thu, 26 Jul 2001 14:28:32 -0700 (PDT)

> and the surrounding discussion about use of IPsec vs. various

   I disagree. Piggybacking and selective authentication were
   what was causing the problems with 2401 IPsec. That doesn't mean
   that IPsec is inadequate for this task. If we remove those
   two requirements on IPsec, IPsec should be an adequate solution
   for this problem. Indeed, given the complexity of creating a
   new DOI for BU's, etc, making MIPv6 conform to IPsec is
   comparatively trivial.

 > Binding Update.  To me, this seems like a good thing, and I am hoping

   It's marginal, and introduces keying questions
   which are always hard. Also: you can have multiple
   SA's with different selectors to accomplish
   this segregation.

 > kind of socket opened by the application, but maybe not...

   Not in the IPsec I'm looking at right now
   (KLIPS). Unfortunately. Dunno if Solaris has
   a better socket API. 
 
		Mike

---

From: Charlie Perkins <[email-masked]>
Date: Thu, 26 Jul 2001 21:51:51 -0700

Hello Mohan,

I thought that the use of AH and the use of the authentication
data within the Binding Update were to be logically independent,
so that the presence of one would not affect the presence of
the other (except insofar as the AH data would be computed
over the Binding Update option fields).  So I don't see why
any of the fields would have to be zero if AH were present.
The AH could theoretically be computed using an algorithm
that was less secure than the Binding Update authentication
algorithm.

Regards,
Charlie P.

---

From: "Jiwoong Lee" <[email-masked]>
Date: Fri, 27 Jul 2001 15:08:03 +0900

I agree with Charlie on that point.

BTW, when HA decaps reverse tunneled packet, which among the tunnel header
and the inner header MUST be accompanied by a valid AH ? From my reading,
"tunneled packet" means "inner header and its payload". "Tunneling packet"
means "tunnel header and its payload, which is in turn, inner header and its
payload."

Jiwoong

----- Original Message -----
From: "Charlie Perkins" <[email-masked]>
To: <[email-masked]>
Sent: Friday, July 27, 2001 1:51 PM
Subject: Re: [mobile-ip] New authentication scheme in Mobile IPv6 draft
revision...-14

---

From: Michael Thomas <[email-masked]>
Date: Fri, 27 Jul 2001 07:04:55 -0700 (PDT)

Charlie Perkins writes:
 > data within the Binding Update were to be logically independent [...],

   Can you please point to the thread where the consensus
   for moving the authentication data to the BU was achieved?

   Thanks.

		Mike

---

From: Mohan Parthasarathy <[email-masked]>
Date: Fri, 27 Jul 2001 09:32:23 -0700 (PDT)

> that was less secure than the Binding Update authentication
I don't have a problem with that. But it is not clear when
IPsec would be used, whether IPsec would be used at all etc.
reading the draft. If BU has auth data in it, reader would
first assume that IPsec is not used at all. 

First of all i don't remember this being discussed on
the mailing list before. So, it took most of us by surprise.

-mohan