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

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

Hi Charlie, 

late reply, I'm struggling with email.

  > How about manual configuration?  Every mobile node
  > should be allowed to establish a permanent security
  > association by manual configuration.  The argument
  > against this for billions of correspondent nodes is clear.
  > There isn't any good argument for disallowing it in
  > special cases.

=> In this case would the policy be:
Trust any BU from [email-masked] ?
Or
Trust any BU from HoA 3ffe::1/128 ?

The latter is clearly not possible because
the HoA could be spoofed.
The former has the authorisation problems 
that PKI have.

  > > - AAA? This adds more burdens (infrastructure
  > >   requirement and inflexbility)
  > 
  > There's a huge difference between mandating AAA for
  > all purposes (which would be hard because of the reasons
  > you have given) and disallowing it for all applications
  > (which would be bad, because many scenarios work well
  > with AAA-style authorization).  AAA (and others!) could
  > be used to establish longer-term security associations
  > than ephemeral RR.

=> OK. I proposed this some time ago, 
but in light of the recent developments
(new IFL methods) I can't see the advantage
of using this. But i suppose that doesn't 
say that it can't happen.

  > >   > > => Interesting, because I can negate the exact
  > >   > > argument with examples.
  > >   >
  > >   > If so, then I will be able to show that your examples
  > >   > are not IPv6 compliant.
  > >
  > > => Charlie, this argument does not hold. Using
  > > extension headers is useful for processing
  > > of the 'received' packets. It doesn't mean
  > > that we can put any protocol into any packet and
  > > that disallowing this breaks IPv6. It might
  > > be worth discussing this on the IPv6 list
  > > though.
  > 
  > This discussion about piggybacking is ONLY relevant for
  > received packets, 

=> Received from someone who sent them :)
Anyhow, I meant that ext headers should be 
used to process the 'received packet', 
e.g. The HAO is used to process the received
packet by replacing the src address with
the address in the HAO.

and already IPv6 essentially mandates that
  > receivers be able to to the appropriate processing for IPv6
  > extension headers.  There is NO requirement that a sender
  > has to use piggybacking.
  > 
  > When I read this sentence:
  >               It doesn't mean that we can put any protocol
  >               into any packet and that disallowing this breaks IPv6.
  > I start to think that you are absolutely not following my
  > discussion.  But to try to make it clear:
  > - IPv6 nodes MUST be able to transmit packets with MTU >= 1280
  > - IPv6 nodes MUST be able to parse certain extension headers.
  > Putting these two mandates does not in any way add up to
  > "putting any protocol into any packet".  I think you should try to
  > explain why you made that characterization.

=> Perhaps I can best explain this by referring you
to the email I sent a moment ago in reply to Erik
on the same topic. I've tried to get to the crux
of the problem and summarise my reasons.

  > The links that you claim, are links that do not correctly 
  > implement IPv6.
  > There are no links, such as you claim, that correctly 
  > implement IPv6.
  > There are plenty of links that correctly implement IPv6.  

=> The links I refer to implement MTU correctly, 
it's not an MTU issue. Apart from losing the QoS
assurances if the BU is piggybacked on the wrong
stream (one that requires different treatment), there can 
be significant additional delays due to piggybacking
on short packets, which are likely to cause 
the packet to be dropped (e.g. because it's too 
late in the RT case). 

Hesham

---

From: Charlie Perkins <[email-masked]>
Date: Fri, 15 Feb 2002 07:33:42 -0800

Hello Hesham,

I'll try to answer your questions, but I think they are
mostly very straightforward.

"Hesham Soliman (ERA)" wrote:

> Hi Charlie,
>
> l  > How about manual configuration?  Every mobile node

Your question isn't very clear, but I will try to reword it
in order to answer the question I think you are most likely
to be asking.  Please forgive me if I guess wrong.

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.

> the HoA could be spoofed.

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!

> The former has the authorisation problems

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.

> packet by replacing the src address with

IP-level processing has several components, all easily
able to be ascertained by looking at the code, including:
- provide an IP-level identifier to higher level protocols
  (your example)
- forwarding packets according to a route table
- managing reassembly queues
- checking version number :-)
and, for Mobile IPv6,
- insertion of care-of address for proper routing
Features relevant to these functions belong at the
IP level.

> of the problem and summarise my reasons.

I would very much prefer if you could respond directly to this
instead of making me pile through even more volumes of e-mail.
This overload is somewhat less than "fun", and it's getting all
the way down to "dammit I cannot keep up with this dammit".

> it's not an MTU issue.

It is an MTU issue.  It is trivially solvable by QoS methods.

>                                Apart from losing the QoS

If you have QoS assurances, then you can make the Binding
Updates go wherever you want them to go.  I have never
argued against this.  I feel that you have not tried to hear my
explanation, though.

Regards,
Charlie P.