Subject: RE: [mobile-ip] Concern over draft-team-mobileip-mipv6-sec-reqts- 00.txt

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Wed, 1 Aug 2001 19:01:22 +0200

>         Vijay,
> 
> > take a look at this.
> >
> > http://www.ietf.org/proceedings/01mar/ietf50-91.htm#TopOfPage
> >
> > look at Jeff Schiller's comments.
> >
>         => My point is this:
>         - If we disallow piggybacking,
>         - develop some other key exchange mechnism (like BAKE or one
of Mike's proposals)
> 
>         Then I don't see why we can't use IPsec provided that the
granularity
>         of the IPsec selectors is fixed. Seems like an implementation
>         issue (the policy part). Have I missed something ?

i partly agree with you. i have personally implemented this fix. 
but the problem is that this fix needs to be implemented in every 
correspondent node. i wouldnt calls this an implementation issue.

=> I don't know what else to call it. If a -cn wants to 
receive a BU it has to do this. I don't see a problem 
with that. Nothing on the wire is changed.

Hesham

> 
>         Hesham
> 
> > "Hesham Soliman (ERA)" wrote:
> > >
> > > > >
> > > > > While you're answering question (or someone else who knows
> > > > > IPsec better than me), are there any problems foreseen with
IPsec
> > > > > if we simply get rid of piggybacking the BUs and send them
> > > > > in separate packets ?
> > > > > I thought not, but would like some confirmation.
> > > > >
> > > > The only other constraint is that there is no selector for
protecting
> > > > just binding update. IPsec policy allows you to select based on
> > > > the IPv6 "nxt" headers. In this case, it would be a destination
> > > > option. But binding update is just one type of such an option.
> > > > So, all destination options would be protected if you use
> > > > IPsec as it exists today.
> > > >
> > >         => Sure but we can have a new type header for it, that is
> > >         if you can't increase the granulaity of the policies. Is
this
> > >         really a problem ?
> > > >
> > > > Others that were mentioned in the past are :
> > > >
> > > > 1) Why only AH ? It is too restrictive.
> > > >
> > >         => Yes, that's another issue. I just wanted
> > >         to know if there were any show stoppers, it
> > >         seems like the selectors are the only issue.
> > >
> > >         Hesham
> > >
> > > > >
> > > > >
> > > > > > -----Original Message-----
> > > > > > From:     Michael Thomas [SMTP:[email-masked]]
> > > > > > Sent:     Monday, 30 July 2001 10:58
> > > > > > To:       [email-masked]
> > > > > > Subject:  RE: [mobile-ip] Concern over
> > > > draft-team-mobileip-mipv6-sec-reqts-  00.txt
> > > > > >
> > > > > > Glenn Morrow writes:
> > > > > >  > Michael,
> > > > > >  >
> > > > > >  > You may have a point but please do us the favor of
answering these
> > > > > >  > questions:
> > > > > >  >
> > > > > >  > 1> Do you believe that the credentials associated with an
SA for node
> > > > > >  > mobility would ALWAYS be the same as the credentials for
another SA for
> > > > an
> > > > > >  > application on two communicating hosts?
> > > > > >
> > > > > >    Not always. Sometimes though (maybe often even).
> > > > > >
> > > > > >  > 2> Can there be more than one ESP header in a single IP
packet without
> > > > > >  > tunneling?
> > > > > >
> > > > > >    Not to my knowledge.
> > > > > >
> > > > > >  > 3> Has there been any succesful work at changing the
answer to question 2
> > > > or
> > > > > >  > perhaps defining some new generic multi-purpose IP-layer
encryption
> > > > option
> > > > > >  > perhaps with different properties?
> > > > > >
> > > > > >    Not to my knowledge.
> > > > > >
> > > > > >  >  > 4> Has there been any successful work at changing the
fact that a BU
> > > > can be
> > > > > >  > sent in the same packet as an application PDU?
> > > > > >
> > > > > >    Not sure what you're asking here... Are you asking if
there's
> > > > > >    been an implementation of piggybacked BU's?
> > > > > >
> > > > > >      Mike

---

From: "Glenn Morrow" <[email-masked]>
Date: Thu, 2 Aug 2001 10:45:16 -0500

Ya know alper, route optimization, in general, certainly complicates things.
In fact mobility  complicates things. Perhaps we just shouldn't do any of
it. This is all just too complicated. Let's just keep building stagnated
stupid routers and hosts - not to mention access specific single point of
failure anchored systems.

My point is that it isn't that complicated. 

-----Original Message-----
From: Alper Yegin [mailto:[email-masked]]
Sent: Tuesday, July 31, 2001 6:38 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [mobile-ip] Concern over

Glenn,

I'm afraid other than killing birds, piggybacking has some other issues 
associated as well :) 

First of all, it'll complicate your implementation. You should queue your
Mobile 
IPv6 signalling messages, setup timers amd age them ... Basically your 
implementation should "manage" this new queue. It's different than sending 
packets as soon as they are ready. In addition to implementation complexity,

this will also have an effect in the performance of your system. 

Piggybacking also effects PMTU. If upper-layer wants to send a PMTU-sized 
packet, and IP wants to piggyback Mobile IPv6 signalling on this packet...?

alper

> Well simply put, piggybacking allows two things to be accomplished with
one
> packet. I think this is efficient. It seems that if there is a packet on
the
> queue headed for where the BU needs to be sent - might as well kill 2
birds
> with one stone. I also think that if you need to reserve resources of some
> sort, the combination might be useful either in conjunction with other
> options or protocols. I also think you could kill 3 birds with one stone.
> 
> Glenn
> 
> 
> Could you explain more on why piggybacking is important ? When MIPv6
> is deployed, do we know how often a binding update will be sent ?
> Is it your concern that there will be too many binding update packets
> on the network ? 
> 
> -thanks
> mohan

alper

---

From: Alper Yegin <[email-masked]>
Date: Thu, 2 Aug 2001 12:26:48 -0700 (PDT)

Hi Glenn,

> failure anchored systems.

Of course not :) You seem to be picking on my "implementation complexity" point. 
By the way, I'm talking about piggybacking binding messages, not talking about 
route optimization.

Implementation complexity by itself is not the only issue. The other points I 
have raised was the performance hit due to handling  "binding message should 
wait until we have a packet to send to the same destination, or a timer goes 
off"... It's hard to say which one is more important: saving bandwidth or 
processing power.

And the PMTU issue...

You haven't addressed my last two issues..

All I'm saying is that there are also downsides to piggybacking. It's not all 
that great.

alper

alper

---

From: "Glenn Morrow" <[email-masked]>
Date: Mon, 6 Aug 2001 15:13:18 -0500

Alper,

I thought your argument was that it was too complicated to do the bundling
for several reasons (PMTU, etc.). My counter-argument was that there are
many things that one could position as complex and I named a few indicating
that one might withdraw support for these functions using the same
reasoning. 

Specially let us consider the PMTU issue. If you consider this PMTU issue to
be that complex, then I deduce that you consider any other functionality
such as: ESP, AH, Tunneling etc.. that has to deal with a similar situation,
as complex.

Another point of misunderstand seems to be that you believe I was saying
that the BU should wait until there is another packet to send to that
address before sending the BU. 

What I was saying is that there are many implementation choices where it
would be quite useful:

For instance, it would be efficient to bundle a binding update with the
first application, reservation or transport datagram destined to a specific
destination. 

Also, if a host did implement some sort of egress queue and packets to
destinations were on it when a mobility event occured, perhaps the queue
should be processed in a smart fashion such that the BUs are bundled. I
agree that not all hosts will be/are this complex.

I believe you should see now that depending on the particular case of
implementation, the complexity is varied. I hope you see that the first case
is not that complex at all.

Clearly the protocol documention should not have to discuss such
implementation realms but perhaps the documentation should have some verbage
about what processing is mandatory and what is optional. For instance there
might be a statement somewhere that says if a CN supports the BU then it
MUST also support the de-bundling of it.

Thanks,

Glenn

-----Original Message-----
From: Alper Yegin [mailto:[email-masked]]
Sent: Thursday, August 02, 2001 2:27 PM
To: Morrow, Glenn [RICH2:C330:EXCH]; [email-masked];
[email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [mobile-ip] Concern over
draft-team-mobileip-mipv6-sec-reqts- 00.txt

Hi Glenn,

> failure anchored systems.

Of course not :) You seem to be picking on my "implementation complexity"
point. 
By the way, I'm talking about piggybacking binding messages, not talking
about 
route optimization.

Implementation complexity by itself is not the only issue. The other points
I 
have raised was the performance hit due to handling  "binding message should

And the PMTU issue...

All I'm saying is that there are also downsides to piggybacking. It's not
all 
that great.

alper

alper

---

From: Francis Dupont <[email-masked]>
Date: Mon, 06 Aug 2001 22:42:24 +0200

=> I support Alper: pigybacking is a bad idea IMHO.

[email-masked]

PS; about selectors, the cleanest solution is to use a new (i.e.
to be allocated by IANA) payload type, aka final next header value.
Expensive (8 bit space) but nobody should be able to find a technical
objection.
PPS: I'd like to be able to use IKE, KINK, AAA, ... if I want:
there is a difference between "cannot use" and "should not rely on".

---

From: "Glenn Morrow" <[email-masked]>
Date: Wed, 1 Aug 2001 16:25:39 -0500

I'm just glad that I'm not the only one that sees value in it. Thanks for
the detail. 

-----Original Message-----
From: Alper Yegin [mailto:[email-masked]]
Sent: Tuesday, July 31, 2001 6:38 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [mobile-ip] Concern over

Glenn,

alper

one
the
birds

alper