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

From: "Glenn Morrow" <[email-masked]>
Date: Wed, 10 Oct 2001 11:26:49 -0500

Hesham,
 
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. 
 
Have you explored sending the piggybacked packets over something like - say,
the MAC representation of the signaling PDP context? 
 
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 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.
 
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.
 
regards,
 
Glenn
 
p.s. I thought this issue was settled already with further discussion
prohibited from the mailing list after being endlessly splattered by Michael
and myself. All this regurgitated FUD seems a bit strange to me. The access
technologies should easily be able to adapt to the bundled packets. 

-----Original Message-----
From: Hesham Soliman (EPA) [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