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

From: "Hesham Soliman (EPA)" <[email-masked]>
Date: Mon, 8 Oct 2001 12:40:03 +1000

At the risk of sounding like a broken record !
>    
>      [about relegating IPsec to low priority: ]
>    
>     >    (I am leaving the MN-HA SA out or the moment).
>    
> (from  Michael Thomas <[email-masked]>)
> 
>       Why?
>    
> => because this is easy (see assumption 1 in the threat draft)
> 
>       An attack against the MN/HA security would be
>       far more catastrophic than the MN/CN. There is
>       absolutely no reason why we should not have 
>       strong authentication for this security
>       association, and it should be a *mandatory*
>       part of any compliant MIPv6 implementation.
>    
> => I agree but we have no global PKI problem is this case and
> many solutions, for instance IPsec 
> 
	=> But are we talking about the "IKE IPsec" or the 
	"AH/ESP IPsec " ? 
	Please separate the 2 problems. For the former it is 
	well understood that we can not rely on IKE as the 
	only key exchange mechanism and solutions are 
	bein proposed. For the latter there are a zillion
	proposals to fix it and we have to pick one. 

	Regards,
	Hesham

---

From: "Glenn Morrow" <[email-masked]>
Date: Wed, 10 Oct 2001 10:14:19 -0500

Jari,

I am fairly confident that these respective access technology and
compression groups can find acceptable ways around handling piggybacked
binding udpates that meet the requirements for the particular media streams
in question.

Besides route optimized MIPv6 will never be ubiquitous anyway as long as the
binding update processing by CN's is only a SHOULD. The MN and HA will
always have to be complicated by back-off procedures to forward stream
tunnel mechanisms. 

In my opinion removing this complication is more important than removing the
piggyback complication for specific access technologies and compression
mechanisms.

I would rather see the group focus on making the route optimized mobility
ubiquitous and removing the complications of it not being.

Glenn

-----Original Message-----
From: Jari Arkko [mailto:[email-masked]]
Sent: Wednesday, October 10, 2001 2:58 AM
To: Pekka Savola
Cc: [email-masked]
Subject: Re: [mobile-ip] MIPv6 - Focus of the security discussion

>Link layer should fragment the IP datagram.

Yes, but then the whole stream of packets is
"moved forward" in terms of delay. Delay
might be bad enough already for this to not
be possible without loss of quality. Could
be better to throw away the whole packet.

Jari

---

From: "Glenn Morrow" <[email-masked]>
Date: Wed, 10 Oct 2001 11:03:51 -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

---

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

It would have made more sense to make the BU a router header option because
routing is what it is affecting albiet on the end-nodes themselves but I
don't see the need to create an entirely new header just for BU? 

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

	> 
>    You do _not_ need to change IPsec. All that is 
>    needed is a few relatively minor changes to 
>    MIP. This has been discussed ad infinitum on 
>    this list. 

	and getting a new extension 
header. the BU as a destination option has been through a 
lot of interoperability events (we have been at atleast 3- 
2000 Conectathon, 2000 ETSI IPv6 bakeoff amd 2001 
Conectathon). lets not change it. 

	=> No one suggested changing the BU option, it was 
suggested that it should be carried in a different header. 
That does not imply changing anything in the option. 

	Hesham

---

From: "Hesham Soliman (EPA)" <[email-masked]>
Date: Thu, 11 Oct 2001 11:29:21 +1000

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?
>  
> 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 ?
> 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
> 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 thing but I don't think it should hamper the acceptance of the existing
	=>  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

---

From: "Glenn Morrow" <[email-masked]>
Date: Fri, 12 Oct 2001 09:23:25 -0500

Michael R.,

I am pleased that you have brought this QoS issues up and I would definitely
like to "go there" with respect to the use of RSVP and BUs. 

Is it your intention to do node mobility with RSVP or do you see more value
allowing a BU and an RSVP message being conveyed in the same packet or are
you just trying to kill route optimization?

It seems clear to most the two should be harmonized in some way in the end.
The answer to the question above will simply draw the line in the sand a bit
better as to where people are going with their arguments. I think it would
be quite healthy for people to "go there" and get this debate settled now.

Thanks,

Glenn

-----Original Message-----
From: Michael A. Ramalho [mailto:[email-masked]]
Sent: Friday, October 12, 2001 7:26 AM
To: [email-masked]
Subject: Re: [mobile-ip] MIPv6 - Focus of the security discussion

Rajeev,

One more time for further clarity. I think the discussion
moved off the original point. Comments in line.

Regards,

Michael Ramalho

At 07:06 PM 10/11/2001 -0700, Rajeev Koodli wrote:
>Hello Michael,
>
>thanks for clarifying. I have some clarifications as well.
>
>- a *compressor* resides in IR/FO/SO states, not a *link*.
>- similarly, a decompressor has either no context, static context or full 
>context.
>
>- compression is limited to IP and transport protocol headers. So, once you
do
>ip_output, the HC engine works on IP and transport headers before the
device
>driver output occurs. Nowhere in this *compression process*, the link 
>layer itself
>comes into play.
>
>It turns out that Compressor-1 (on L1) need not know in which state 
>Compressor-2
>(on L3) is before sending a piggybacked BU. Consider the following two
cases.
>First, the compressor on L3 would be in an IR state if it has never 
>initialized a
>context for this stream or there has been a pathological failure of an 
>existing
>context. Note that once a compressor determines that the decompressor has
Full
>Context, it must not transition to the IR state unless there is an 
>irrepairable
>context. It should be in FO, SO, or IR-DYN states, all of which have 
>enough room
>to include additional bytes the size of a BU.
>
>Second, if Compressor-2 _is in_ IR state when it receives a piggybacked BU,
it
>would have to be able to include the BU as part of initialization, just as
it
>should be able to handle any IPv6 extension header. I believe 3095 
>specifies how
>to handle the extension headers.

I have no doubt that the Compressor-2 knows how to do its job - it would
do it as you have said. That was never my point (hopefully I have proved
that
I am cluefull on this issue and move on).

The issue that triggered this thread was that the outgoing packet with the
piggybacked BU could only fit on the outgoing link (L1) if ROHC was in
FO or SO - for the case of a QoS constrained, DOCSYS-like output link
(which effectively has packet length limitations due to the QoS granting
mechanisms used on the link).

I agreed with that ... but said you were forgetting about the link on the
other side.

On the other side ... you do *not* know the compression state ... and
do not know if the packet with the piggybacked BU will fit into the QoS
channel.

I have *no doubt* that ROHC knows what to do with a packet with
a piggybacked BU. My point is not about compression; but rather
on the point (Mike Thomas' actually) that the piggybacked packet
may be too large for other links as well.

>So, in summary, the chances of Compressor-2 being in the IR state when a
>piggybacked BU is received should be small. However, if it is indeed in the
>IR state, it should not matter.

Again, I have little doubt that the ROHC folks know how to handle this
case. The issue is whether a QoS link can handle the larger packet
created by a piggybacked BU.

>-Rajeev

Think for a moment what one is saving via a piggybacked BU.

One argument is that it is saving precious bandwidth - so piggybacking
is good.

However, this *ignores* the way QoS flows are provisioned. One
example - the one above with a QoS grant mechanism on a link - shows
that piggybacking can be detrimental. But it is far from the only example.

Most QoS provisioned flows are policed at the edge of a network to
fit within a certain TSPEC/RSPEC. Given the expected frequency of
BUs ... to all but the most tight policers (in time constant or in strict
bandwidth), this increase would be negligible. This is effectively your
"wiggle room" argument. But one could imagine some policers would
actually mark the packet for discard eligibility (the new DE bit) or drop
it if the packet was too long. This is exactly the *wrong* thing to happen
to the BU (and to the QoS flow, which did nothing wrong!).

If I (and people like Mike Thomas) have not convinced the group that
BU piggybacking has more downsides than are worth it ... we may
be forced into a bigger debate on the interaction of QoS and mobileip.

[do you really want to go here ...]

To give an example of the proposed further debate .... suppose that
a pair of hosts have a "session" between them with a multiplicity of
QoS flows associated with this session (e.g., a videoconference with
QoS only provisioned on the voice). Now you want to send a BU.
Which "QoS type" packet do you piggyback onto. If the link layer
is dumb (the usual case) ... choosing the next packet is the easiest
choice. But you don't know the next packet's QoS treatment. In this
scenario, I'd choose one of the "reliable, delay insensitive" channels
if I had a choice. I would *not* choose the voice QoS channel.

In general, choosing "what type" of packet to piggyback onto is
hard. If you simply choose the "next or present" packet - at best
you get the QoS of this flow - and at worst you effectively harm
the packet/flow (e.g., marking it DE) for the flow that wanted
premium treatment.

Until convinced otherwise ... I am not persuaded that BU piggybacking
benefits outweigh the potential downsides. And I have not even
exhausted thinking about the downside arguments yet.

Remember ... one can make the following argument as
well ... "given the expected frequency of the BUs, that the
bandwidth saved by piggybacking is also negligible".

I am attempting to be a realist here. Bandwidth savings (piggybacking)
is usually good ... unless it causes more pain than the savings is worth.

Best Regards,

Michael Ramalho

Michael A. Ramalho, Ph.D.
Office email: [email-masked]
Personal email: [email-masked]
Office: +1.732.449.5762
Cell: +1.732.809.0188

---

From: "Michael A. Ramalho" <[email-masked]>
Date: Fri, 12 Oct 2001 14:32:05 -0400

At 09:23 AM 10/12/2001 -0500, you wrote:

>Michael R.,
>
>I am pleased that you have brought this QoS issues up and I would 
>definitely like to "go there" with respect to the use of RSVP and BUs.

I was kind of hoping no one really wanted to go there .... at
least not right now.

>Is it your intention to do node mobility with RSVP or do you see more 
>value allowing a BU and an RSVP message being conveyed in the same packet 
>or are you just trying to kill route optimization?

Being a VoIP guy ... I'm definitely not trying to kill route optimization.

I simply see piggybacking as unnecessary ... as the savings are
trivial given typical BU update frequencies.

In a response to Rajeev .. I suggested that if he really needed the
bandwidth savings on the mobile link ... that he specify the
"effective piggybacking" at L2 ... to save the link bandwidth.

>It seems clear to most the two should be harmonized in some way in the end.

I agree that the QoS issue needs to be resolved. Not piggybacking
the BU allows for de coupling of the QoS and the security issues. The
day of reckoning on QoS and security is simply postponed.

>The answer to the question above will simply draw the line in the sand a 
>bit better as to where people are going with their arguments. I think it 
>would be quite healthy for people to "go there" and get this debate 
>settled now.

>From: Michael A. Ramalho 
>[<mailto:[email-masked]>mailto:[email-masked]]
> >- compression is limited to IP and transport protocol headers. So, once 
> you do
> >context. Note that once a compressor determines that the decompressor 
> has Full
> >Second, if Compressor-2 _is in_ IR state when it receives a piggybacked 
> BU, it
> >would have to be able to include the BU as part of initialization, just 
> as it
>do it as you have said. That was never my point (hopefully I have proved that

---

From: "Glenn Morrow" <[email-masked]>
Date: Thu, 18 Oct 2001 15:16:02 -0500

Behcet,
 
>  I read your long email, talking about vertical and horizontal solutions.
I do not quite get what you are referring to (any drafts, RFCs, books,
papers, etc)?   

GM] I think there has been some discussion on numerous mailing lists inside
and outside of the IETF, some have done drafts, some have done papers.
SIGLITE, Active Networking, MIP and derivative lists have discussed this for
over 3 years now. I could try to dig up some references.

>  A simple question: you are saying that RSVP would not work with MIPv4,
aren't you?

GM] No. Perhaps one could say, "as currently defined they are not
compatible".  I think they could be made to be compatible even with route
optimization.
 
> BTW, QoS issues to my knowledge will go to NSIS WG yet to be formed. 

GM] And NSIS is also supposed to handle the mobility interactions as well.
Perhaps we should try to help that effort out by allowing the two to work
synergistically. 

Regards, 

Glenn

---

From: "Glenn Morrow" <[email-masked]>
Date: Thu, 18 Oct 2001 15:22:14 -0500

I agree - of course.

> From: Charles E. Perkins [mailto:[email-masked]]
> Sent: Thursday, October 18, 2001 1:00 PM
> Cc: Morrow, Glenn [RICH2:C330:EXCH]
> Hello folks,
> Glenn Morrow said something which has resonated with me during
> the last week.
> 
> > 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.
> 
> 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.
>

---

From: "Hesham Soliman (EPA)" <[email-masked]>
Date: Fri, 19 Oct 2001 11:45:45 +1000

> > > > 	- an "unpiggybacked" BU with a new ext header and 
> > > > 	- an SCTP payload.  
> > > > 	Could you tell me why these two are different ?
> > > > 
> > > > 	If you drop the former then you'd drop the latter ...right ?
> > > > 	Sounds like a firewall that needs an upgrade. 
> > > 
> > > The difference is significant.  Perhaps I can help to clarify the 
> > > situation.
> > > 
> > >  SCTP header would be like:
> > > 
> > >   IPv6 HDR - SCTP header
> > > 
> > >  BU with new Ext Header would be like (if I get this right):
> > > 
> > >   IPv6 HDR - UnknownHeaderBU - TCP/UDP/... header
> > > 
> > 	=> No it's not like that. The _whole discussion was about 
> > 	introducing a new ext header for IPsec and removing
> > 	piggybacking. .... Please.... the 2 go hand in hand !
> 
> Sorry, I didn't know what you meant, exactly, with:
> 
> 'an "unpiggybacked" BU with a new ext header'
> 
> I took this as a BU dst option moved to a new, non-final extention header.
> 
> If this would have been the case, my discussion would have applied.  
> Perhaps you meant something else (a final BU ext header).
> 
	=> Yes (to the last sentence), sorry if I wasn't clear, it 
	was getting late :)

	Hesham

> -- 
> Pekka Savola                 "Tell me of difficulties surmounted,
> Netcore Oy                   not those you stumble over and fall"
> Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

---

From: "Hesham Soliman (EPA)" <[email-masked]>
Date: Fri, 19 Oct 2001 12:07:31 +1000

Hello Charlie,

> > 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.
> 
> This seems to hit the spot exactly.  We have disagreements, but I would
> good for IP instead of the restrictions imposed by the unadapted access
> Applied to the discussion about whether Binding Update should be carried
> it fits naturally in IP, and if there are going to be networks which can
> costs of the feature.  Some networks will gladly pay the cost, and some
> I am very much in favor of making the best IP definition, and along the
> networks. 
	=> Sounds good. but below is where the problems begin IMHO. 

>  The current proposal with Destination Options does do that.
	=> Well the problem is that IP is access independant :)
	So while my IPv6 MN may refuse to piggyback, my HA
	or CN might decide that piggybacking is a good idea
	and by that decision it is harming me. 
	This is despite the fact that my MN does not piggyback. 
	So the problem can not be solved based on a decision
	made by one side. 
	This is the main problem, keeping /removing piggybacking
	is an issue that will affect the sender and the receiver, 
	regardless of the design choices that each node may
	make. 

	Hesham

---

From: "Glenn Morrow" <[email-masked]>
Date: Fri, 19 Oct 2001 15:28:09 -0500

Modularity is achieved with logical demarcation via statistical multiplexing
of options within headers and headers themselves. Piggybacking is modular.
Modularity is achieved the same way that modularity is acheived in a packet
containing IP, TCP and HTTP. These things are doing separate functions and
yet they work synergistically. They are all contained in the same packet,
however.

> From: Michael Thomas [mailto:[email-masked]]
> Sent: Friday, October 19, 2001 2:30 PM
> To: Koodli Rajeev (NRC/MtView)
> Cc: 'ext Michael Thomas'; mobile-ip; Michael A. Ramalho
> Koodli Rajeev (NRC/MtView) writes:
>  > >   This is, in fact, a good reason to keep things
>  > >   modular. The fact that piggybacking is problematic
>  > >   for many extant links, and not especially useful
>  > >   for others (ie, 802.11) says to me that the KISS
>  > >   principle probably applies.
>  > >  
>  > 
>  > I am sorry: I don't see the flow of logic here.. BTW, I would have
>  > agreed to the modularity  principle if you stated that one must not
>  > strike out destination option because a particular link, yet
>  > unspecified, does not know how to handle it.
> 
>    Modularity would dictate that a packet with two
>    separate functions should be divided into two
>    packets. It's quite obvious that a great deal of
>    the current set of problems with MIPv6 security
>    suffers from the law of unintended consequences
>    directly related to trying to avoid modularity.
> 
>  > >   Also: I've asked Rajeev several times for an 
>  > >   example of a L2 on a shared media which delivers
>  > >   different QoS than BE which doesn't suffer from
>  > >   either excessive bandwidth utilization or undue
>  > >   latency/jitter for real time traffic, and thus
>  > >   far he hasn't provided me a pointer. Maybe he
>  > >   just can't talk about it, but if there exists
>  > >   such a beast I'd _love_ to hear about it (seriously).
>  > 
>  > This brings back the question of whether destination 
> option must have
>  > been specified in the first place because some weird link 
> does not know
>  > how to support it! What's the logic in saying IP cannot have
>  > variable-sized packets because a link would have 
> performance issues?
> 
>    The current BU design is not modular. It claims
>    that it did that because of bandwidth/latency
>    gains. You have not presented a *single* MAC/PHY 
>    where that claim can be tested. Here you dodge 
>    my direct question yet again.
> 
>  > > > I read this as a particular response to the suggestion that
>  > > > highly structured MACs couldn't handle the Binding Update.
>  > > > I found his response to be reasonable, which is to say that
>  > > > reasonable engineers could make it work.
>  > >
>  > >   Uh, how? Until details are provided, I remain
>  > >   skeptical.
>  > 
>  > Well, please check the recent archives for header compression and
>  > piggybacking interworking.
> 
>    I did. You haven't answered my question.
> 
>  > >   RTS/CTS-style links produce unacceptible latency
>  > >   and jitter for real time traffic, especially at
>  > >   slow link speeds.
>  > >
>  > 
>  > So what ? If IP was designed looking into every possible link's
>  > idiosyncrasies, you and I would probably not having this 
> conversation!
>  > hmm..
> 
>    I'm only looking for a single link layer which
>    benefits. You haven't provided an example.
> 
> 		 Mike
>

---

From: "Glenn Morrow" <[email-masked]>
Date: Sun, 21 Oct 2001 10:48:04 -0500

Behcet,
 
I have read the draft; however, there are some issues with that solution as
well (the AAA battle) - not that I am apposed to someone implementing and
deploying it in the situations where they could. For now, I think it is best
to focus on the cleaner slate and then retrofit, dealing with BW
compatibility.
 
Thanks for your input and please continue.
 
Glenn

-----Original Message-----
From: Behcet Sarikaya [mailto:[email-masked]]
Sent: Friday, October 19, 2001 4:08 PM
To: [email-masked]
Subject: Re: [mobile-ip] MIPv6 - Focus of the security discussion

Hi again Glenn, 
  I am going to reply to your two consecutive mails, just on RSVP and
layering: 
1. RSVP. Firstly mipv6 allows sending BUs separately (as I said in my email
yesterday, mipv4 mandates, i.e. not only allows but requires, this already
for registration requests), i.e. not piggybacked, so how are going to
achieve what you wish to have as a required behaviour? 
This answer is you need to standardize. An example such thing is in
AAA-mipv4 application defined in draft-ietf-aaa-diameter-mobileip-07.txt
(nicely defined by Pat and Charlie!) 
2. You said in your mail: 
Modularity is achieved the same way that modularity is acheived in a 
packet containing IP, TCP and HTTP. 

This is because HTTP is an application layer protocol, it uses TCP as the
transport layer, i.e. L4 which in turn uses IP as the network layer, i.e.
L3. 
A bit of lesson on OSI layering, please. 

Kind regards, 

Glenn Morrow wrote: 

Mike, 

I'm sorry no one ever responded to this before. Here is an example I hope
meets your criteria:

-- 
Behcet

---

From: "Glenn Morrow" <[email-masked]>
Date: Mon, 22 Oct 2001 09:30:53 -0500

4. Don't piggyback on RTP streams that are not encrypted.

-----Original Message-----
From: Hesham Soliman (EPA) [mailto:[email-masked]]
Sent: Monday, October 22, 2001 12:31 AM
To: [email-masked]'
Cc: Koodli Rajeev (NRC/MtView); 'ext Michael Thomas'; Michael A. Ramalho
Subject: RE: [mobile-ip] MIPv6 - Focus of the security discussion

	Hello Rajeev and all, 

	>  > This brings back the question of whether destination option
must have 
>  > been specified in the first place because some weird link does not know

>  > variable-sized packets because a link would have performance issues? 
> 

	Actually, I mentioned previously that the use of [rohc] over
cellular is one 
reference for you. See http://www.ludd.luth.se/users/larsman/rocco
<http://www.ludd.luth.se/users/larsman/rocco>  and follow 
the references. 
Note: use of [rohc] would require support for variable packet sizes on the 
link (perhaps the same kind of link you are considering). 

	=> I'm not sure why the discussion has gone towards header 
compression, but anyway, the point I was raising was that 
piggybacking can have negative effects on the MN/CN if they 
are attached to a tight channel. Obviously the channel is tight 
because it''s expensive so there is a very limited potential 
of reserving a "just in case" extra BW for piggybacking. 

	Now, I'm not saying ROHC can't handle it, all I was saying is 
that this "larger" packet will likely take double the time 
to be sent over the air since it may not fit into one radio 
frame. If it does, then the end to end delay will be significantly 
increased (the air link delays are -by far- the largest part 
of the e2e delay in a cellular environment) and it may be dropped. 
ROHC is not reallt relevant here. 

	So the result of the scenario above is a degradation in service. 
Now we can argue for a long time about whether these links 
are "IP friendly" and whether we should design IP for 
these interfaces, but the fact is this is what we have _today_. 

	Also BTW these systems are the ones deploying IPv6 first ! 
So we just have to deal with the real case here and try to 
solve it. 

	Unfortunately, we can not assume that the problem can be solved 
at one end only. So what can we do ? 

	1.  Keep piggybacking and just say to the designers of these 
     systems "tough luck". ? Doesn't look good for MIPv6. 

	        Pro: - The draft doesn't change 
        con: - Adds another reason for not deploying MIPv6 in cellular 
               systems. 
             - The IPsec problem still stands 

	2.  Remove piggybacking ? 
       
    pros: - End of this thread (can't wait :)) 
            - End of the IPsec problems. IPsec can be used 
            - MIPv6 becomes more "cellular friendly" 

	     Con: whatever advantages people see for piggybacking 
             (in Jari's draft) will disappear. 

	3.  Have some negotiation mechanism in MIPv6 between 
     the MN/CN. I'm not sure how this would work yet 
     but I could imagine having something in the Home Address 
     option or the BU option to indicate whether piggybacking 
     should be used or not. 
     If we use the Home address option, we would need to 
     account for the fact that it will not necessarily be secure. 
     Meaning, it can be modified en route. 
     
     If we use the BU, we will still get some service degradation 
     for the first BU. 
     Regardless of the chosen method for this option, this 
     new "flag" or "indication" MUST be supported by all 
     MNs and CNs to avoid any service degradation due to 
     piggybacking. 

	I'd be more inclined to 2 or 3 .... Comments ? 

	Hesham

---

From: "Hesham Soliman (EPA)" <[email-masked]>
Date: Tue, 23 Oct 2001 11:27:39 +1000

Hi Rajeev, 

> this is really the issue of carrying IPv6 over certain links.
> Piggybacking happens to make use of destination option, that's all. So,
> when you characterize not having piggybacking in MIPv6 as "cellular
> friendly", you are inevitably referring to how to support destination
> options in general. If these links are the first to carry IPv6, it
> should be possible to support destination options in arbitrary packets,
> don't you think ? 
> 
	=> I don't think you got my point, it doesn't matter what the 
	link "should" be doing. We're not radio link designers and 
	there is an existing reality that we have to deal with. There
	are lots of things that I'd like to see link layers do but that's
	not the issue.

> [I realize home address option is a destination
> option, BTW]. 
> 
	=> A static one in every packet, and is compressed. 

> More generally, a link should be able to handle variable
> packet sizes. Thus, removing piggybacking should not be an option.
> 
	=> Again "should", I'm talking about what they "do", not 
	"should do". 

> I am in favor of option 1 you mention below. This is in line with
> general IP protocol design. Any performance considerations could be
> stated in the draft in some form.
> For instance, we could state that "..if the BAck does not return after
> transmitting a Binding Update BU_PIGGY_TIMES, the sending node must send
> a BU without piggybacking". BU_PIGGY_TIMES, a non-zero integer, is a
> configurable parameter.
> 
	=> I don't think that's a good idea. It shouldn't take a few BUs
	and dropped packets for us to "guess" whether piggybacking 
	is needed or not.
	In fact I don't know why you say it's in line with general IP
protocol
	design ?? Could you explain what that is ? 
	In the Fast Handoffs work for v4 and v6, the design teams have 
	been modifying parts of MIP to -for example- get the AR to 
	start forwarding before receiving a BU, why was this acceptable ?
	Why didin't we just say link layers should be desinged to allow 
	for MIP signalling ?
	Well some of us did, but the WG decided that both philosophies 
	are needed to support existing link layers. BETH is one example. 
	So I don't think your logic is in line with the previous WG
decisions
	on similar topics.

> I am willing to live with option 3. As you suggest, in the home address
> option, a flag might indicate the MN's intention to piggyback.
> I however, don't know how the CN would be able to negate it unless it is
> also using the home address option. 
> 
	=> Well if it happens then it can't be negated.

> >      reference for you. See
> >      http://www.ludd.luth.se/users/larsman/rocco and follow
> >      the references.
> Rajeev: Since we were discussing a "tight channel", it is likely that
> header compression is needed on such links. Hence the discussion on HC.
> 
	=> HC was not the issue, tight channels are. 
> Rajeev: chances of a piggybacked packet being large enough that it
> creates the problem you mention above is not an issue when you use HC.
> In the non-IR states, you already have 40 bytes of gain due to IPv6
> compression which is more than the size of a BU. 
> 
	=> How do you know that the link was not designed with the 
	underlying assumption that header compression is used ?
	Hence no gain ! 

	Hesham

---

From: "Koodli Rajeev (NRC/MtView)" <[email-masked]>
Date: Tue, 23 Oct 2001 21:43:15 -0400

Hello Hesham,

	Hi Rajeev, 

[Rajeev] Well, I am afraid that you did not get the essence of what I
said either: If a link claims it supports IPv6, it _is_ supporting
destination option in arbitrary packets. 

=> A static one in every packet, and is compressed.
[Rajeev]   Good. You acknowledge the presence of header compression.
That means there is no problem with piggybacking on such a link. 

[Rajeev] Please read the sentence. It says removing piggybacking should
not be an option. Actually, removing piggybacking MUST NOT be an option.
It only indicates to me that MIPv6 is expressly eliminating what is in
2460. 

	I am in favor of option 1 you mention below. This is in line
with 

[Rajeev:]There was an e-mail earlier from Greg Daley on how to do this
better.

In fact I don't know why you say it's in line with general IP protocol 

[Rajeev]  Well, do they eliminate piggybacking ? How do they violate
base IPv6 specification ?  Anyway, my point (which I have made few times
now in this thread) was that you don't design an IP protocol based on
each link's idiosyncrasies!

Well some of us did, but the WG decided that both philosophies 
are needed to support existing link layers. BETH is one example. 
So I don't think your logic is in line with the previous WG decisions 
on similar topics. 

[Rajeev] Performance optimizations are fine as long as the base protocol
is not violated. Here, by saying that we will disallow piggybacking, you
are saying that we don't support IPv6 destination options in arbitrary
packets.  

	I am willing to live with option 3. As you suggest, in the home
address 
option, a flag might indicate the MN's intention to piggyback. 
I however, don't know how the CN would be able to negate it unless it is

[Rajeev:] You seem to be contradicting yourself, and I see myself
repeating a lot..I said when the channel is tight, it is likely that HC
is used, and you mention above, wrt to home address option, compression
is in use.

[Rajeev:] You don't have to know. If the link supports IPv6, it handles
destination option regardless of HC.

BTW, no header compression on a _tight link_ that supposedly carries
IPv6 packets, piggybacking would not be the primary problem! 

Regards,

-Rajeev

        Hesham

---

From: "Hesham Soliman (EPA)" <[email-masked]>
Date: Wed, 24 Oct 2001 16:23:30 +1000

I don't know where I poorly explained my point, but 
		let me see if this works. 
		Let's assume we have a tight channel with a large 
		RTT delay and was designed with the assumption that HC 
		is used. Hence, there is no 40 byte slack in the channel
		because the assumption was always that HC exists
		and the IP header was not accounted for. This is 
		obviously for the case where this channel is "tight"
		due the low BW requirement of the service running on it.

		When a device starts sending an occasional (additional) ext
header
		that causes the payload to be split across more than
		one radio frame, then significant delays will be encountered
		for that payload. If this is a real time payload (like
voice)
		then the delays makes this datagram useless when it 
		arrives at the other end. Hence service disruption has 
		already taken place. 

		Note that I didn't say anything about the packet being 
		dropped above. I will assume that the implementation 
		of this channel will not drop the packet. So the packet
		will still (eventually) be delivered to the other end where 
		the BU is processed.

		Now In the above (_realistic_) scenario, 
		was the service disrupted due to the piggybacking ? Yes
		Will the BU be delivered to the other end ? Based on the
		assumption above: Yes
		Is this radio link breaking RFC2460 ? No because the 
		packet was not dropped. 
		Did the user gain anything from piggybacking ? No. 

		So I don't understand why you're in favour of mandating 
		piggybacking. 

> [Rajeev:]There was an e-mail earlier from Greg Daley on how to do this
	=> No that doesn't solve the problem. Michael already 
	responded to that. 

> [Rajeev]  Well, do they eliminate piggybacking ? How do they violate base
> IPv6 specification ?  
> 
	=> I didn't refer to piggybacking ! They violate MIPv6 which clearly

	states that forwarding to a new CoA must be done based on 
	the reception of an authenticated BU. They don't violate
	the base IPv6, but MIPv6. Is that allowed ? If so then I 
	don't understand the "violation" argument.

> are saying that we don't support IPv6 destination options in arbitrary
	=> The example I showed above does NOT disallow 
	piggybacking, but it shows that it can be disruptive to
	the services. Anyway, I don't think your charaterisation
	is accurate. Destination options are certainly supported
	(the Home address option is for one). The point is that, 
	the behaviour by which a node signals to the other end
	needs to be optimised to minimise service disruption. 
	In this case the optimisation is to send the MIPv6 signalling
	message on a separate channel, hence eliminate piggybacking. 

	There is nothing wrong with sending DST options in separate
	IP packets. RFC 2460 did not say that all the information
	MUST be piggybacked.