Subject: RE: [mobile-ip] MIPv6 - Focus of the security discussion

From: "Glenn Morrow" <[email-masked]>
Date: Thu, 11 Oct 2001 15:50:58 -0500

Hey Hesham,
 
I guess people just don't agree on the value of piggybacking, the affect of
delays incurred by segmentation and whether the access network should drive
the IP definitions or the access networks should adapt to the IP
definitions. 
 
The last time I got involved in this piggyback discussion it got very messy
and so I think I'll refrain from further discussion for now.
 
I do want to commend Jari for taking the time and effort to produce what I
consider a fairly unbiased BU security draft in record time.
 
Best wishes,
 
Glenn

-----Original Message-----
From: Hesham Soliman (EPA) [mailto:[email-masked]]
Sent: Wednesday, October 10, 2001 8:29 PM
To: [email-masked]'
Subject: RE: [mobile-ip] MIPv6 - Focus of the security discussion

	Hi Glenn, 
  
Not that this is the particular place for this discussion but it seems that
limitations of specific access technologies have again emerged into the
requirements of this IETF WG. 

	=> Probably not the right place but we can try till the chairs tell
us to stop :) 
  
Have you explored sending the piggybacked packets over something like - say,
the MAC representation of the signaling PDP context? 

	=> I don't get that, could you elaborate a bit ? 

	It seems that this multiplexing could be accomplished quite easily
via some ROHC middle box? 
  
I, for one, don't see much of a problem with some miniscule delay on one
single packet during a handoff of a mobile to mobile or mobile to cable
voice call - even if something like the signaling PDP context is not used.

Dropping the packet is probably worse than some miniscule segmentation delay
on one packet. 

	=> I'm not sure that it's a miniscule delay at all. The delay will
probably be doubled. 
If one packet fits nicely in the radio frame, and the extra bytes 
take it beyond that frame, then it is likely that the delay will at least be
doubled 
(I'm clearly considering the delays over the air whichh are the major
portion of 
the RTT delay in a cellular network). 
Now for a real time application, this delay is just as good as dropping the 
packet. Have I missed something ? 
  
I could see creating some new form of generic authentication/encryption
header that could be used for integrity and confidentiality of any set of IP
options and used in conjunction with existing IPSEC headers for the
applications; but based upon the timeliness of such work and cross WG
controversy involved in this, it seems that the logical and expedient
solution specified in the existing draft makes the best sense at this
particular point in time. I don't mind if someone suggests such as thing but
I don't think it should hamper the existing MIPv6 proposal which does solve
the problem.

	=> This is an orthogonal issue to piggybacking IMHO. The current 
soution in the draft doesn't solve the problems we're discussing. 
Obviously this new susboption will not be compressed by 
ROHC, s the extra bytes are still there. 
  
As far a creating a new header specifically for BU, I don't see how that
would solve much of anything. Again, I don't mind if someone suggests such
as thing but I don't think it should hamper the acceptance of the existing
MIPv6 proposal.

	=>  Again this is another (a third issues). This was suggested for 
allowing IPsec to protect the BUs. Have a look at Jari's draft. 

	Hesham 

	-----Original Message-----
From: Hesham Soliman (EPA) [ mailto:[email-masked]
<mailto:[email-masked]> ]
Sent: Wednesday, October 10, 2001 12:56 AM
To: [email-masked]'
Subject: RE: [mobile-ip] MIPv6 - Focus of the security discussion

	        Hello Charlie, 

	        >      the minor changes involve throwing out piggybacking
(which
>      in my opinion is a nice feature).
>
>      => This was discussed in detail, it's nice but not practical.
>      BW-constrained links (like cellular links) allocate set
>      channels based on the service, piggybacking the
>      BU _will_not_fit_ in the channel and the packet will
>      dropped ! That's not nice is it.
>      Non-BW-constrained links could not care less if
>      we piggyback or not.
> 

	        First, it was discussed in detail.  It's nice.  For some
applications
on some links, it's not practical.  For other applications on other
links, it is practical.  It's been implemented, tested, and it works. 

	        => I realise it was implemented and tested. My issue here
is that how does a MN know whether the CN receiving
the piggybacked BU will be negatively impacted by piggybacking ? 

	        Jari has mentioned this in a previous email but I'll quickly
mention
it again. A MN on a WLAN could be sending a BU to a CN
connected to a cellular link which was assigned a fixed channel
size. Because the BU was piggybacked, the entire packet
is dropped as it doesn't fit in the allocated channel.
Is there any solution to avoid this scenario ?
This is only one of the issues that were mentioned
against piggybacking. 

	        Hesham

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 18 Oct 2001 11:00:21 -0700

Hello folks,

Glenn Morrow said something which has resonated with me during
the last week.

> the IP definitions or the access networks should adapt to the IP definitions.

This seems to hit the spot exactly.  We have disagreements, but I would
like to suggest that we should make the IP definitions based on what's
good for IP instead of the restrictions imposed by the unadapted access
networks (or, worse yet, the least common denominator of all access
networks!).

Applied to the discussion about whether Binding Update should be carried
along with payload, this would mean that we should have the feature if
it fits naturally in IP, and if there are going to be networks which can
use the feature to good advantage.  The reasons why this feature are
advantageous are outlined in the draft from Jari Arkko, along with the
costs of the feature.  Some networks will gladly pay the cost, and some
won't, for a myriad of reasons.

I am very much in favor of making the best IP definition, and along the
way making sure that it can be used to fit well with existing access
networks.  The current proposal with Destination Options does do that.
There is no requirement that any implementation MUST supply payload
in packets that contain a Binding Update, and almost all of the
complication from processing payload with a Destination Option comes
on the sending side.  So I don't agree with arguments based on the
extra complexity.  If some implementations don't want to undertake
the extra complexity, that is fine, but those groups should not be
allowed to penalize the implementations that wish to offer the better
performance by the magic of making it illegal to do so.  That is not
fair in my book.

Regards,
Charlie P.