Subject: RE: [Fwd: Re: [mobile-ip] Piggybacking - DT recommendation]

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Fri, 15 Feb 2002 16:58:17 +0100

> The problem is, I don't know what you mean by "the policy".
  > We are dealing with authentication of IP-level data as
  > received by a correspondent node.  Thus, "the policy"
  > would be geared towards verification of data from a
  > single IP address (e.g., xxxx:...:xxxx/128) (a home
  > address).  We are NOT dealing with NAI, and we are
  > NOT dealing with prefixes of length less than 128.

=> My points are: 

- what is the identity used to establish an SA?
- Just because you have an SA with
that identity does that mean that they can
modify your routing table (that's effectively
what a BU does). 

The ownership of a HoA does NOT give you the right
to forward traffic to any address (CoA) on
the Internet. This is why I said that the 
second option was not valid. But i clearly
said it wrongly, probably because of the 
time I wrote it!

Being a certain identity in a certificate
..etc does not necessarily authorise you
to divert traffic from an address (HoA), 
unless the HoA is included in your identity
somehow. And you still need to prove that 
you own a CoA of course. 

Authenticating someone doesn't necessarily 
give them authorisation to do whatever they 
want. For the BU, the proof of ownership 
for the HoA and Coa is needed. 

  > 
  > This is nonsense!  If a correspondent node has a
  > security association with a mobile node, based on its
  > home address, then the mobile node cannot use some
  > other home address!

=> OK I explained what I should have said
above.

  > 
  > > The former has the authorisation problems
  > > that PKI have.
  > 
  > We are not dealing with NAI, but anyway it does not
  > matter.  As shown by AAA for Mobile IPv4, a AAA
  > server can securely check the credentials of a mobile
  > node which is using NAI.  Thus, both of your assertions
  > are incorrect.

=> What's AAA doing here? My response
was on manually configured SAs!

  > > => The links I refer to implement MTU correctly,
  > > it's not an MTU issue.
  > 
  > It is an MTU issue.  It is trivially solvable by QoS methods.

=> I do not know why you assert that it's 
MTU related. MTU has nothing to do with this. 
What are the trivial QoS methods??

Hesham

---

From: Charlie Perkins <[email-masked]>
Date: Fri, 15 Feb 2002 08:47:26 -0800

Hello Hesham,

This has, by now, a lot less to do with piggybacking.
I ask you to avoid mixing all the discussions together.
I have relabeled this e-mail accordingly.

> - what is the identity used to establish an SA?

Presumably, the home address.  However, I didn't
make a user guide for manual configuration.
I only say that the result will be a BSA (Binding
Security Association) that will be useful for
authenticating Binding Updates from a particular
care-of address.  Just like the home agent has been
doing all along.

> modify your routing table (that's effectively

The purpose of the BSA is to enable the recipient
to modify the Binding Cache with updated information.
This is the very central purpose of the Binding Update,
and is just like what the home agent does.

> said it wrongly, probably because of the

We were supposed to be talking about piggybacking.
Your question is related to BU authorization in
general, and I am behind on that subject.

> was on manually configured SAs!

You mentioned something that looks like a NAI.
My experience with NAIs is that they are useful
with AAA-based authorization.  I'll happily forget
that you brought it up :-)

> MTU related. MTU has nothing to do with this.

If the link can carry 1280 bytes, it can carry Binding Update.
Thus it is exactly an MTU issue.

Your whole point is to get Binding Update out of the data
channel, and you are mistakenly using a very brute force
approach to doing this.

> What are the trivial QoS methods??

To sketch:

Application endpoint A asks for X bits/sec data, Y bits/sec control.
Application endpoint B says yes.  A sends <= bits over the data
channel.  A sends <= Y bits/sec over the control channel.
Endpoint B does not MAKE endpoint A mash together the
data and control, and endpoint B _DOES_ respect endpoint A's
request for QoS on the available channels.

Is that enough, or do I have to work harder to be clear?
Can you at least try to see what I have to say?

Regards,
Charlie P.