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

From: Mohan Parthasarathy <[email-masked]>
Date: Mon, 30 Jul 2001 17:10:47 -0700 (PDT)

> 
> Mike, 
> 
> 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.
  
Others that were mentioned in the past are :

1) Why only AH ? It is too restrictive.
   
2) May be there are others..

-mohan

> Thanks,
> 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: Mohan Parthasarathy <[email-masked]>
Date: Mon, 30 Jul 2001 17:34:20 -0700 (PDT)

> 	=> 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 ? 
> >   
Are you sure that it is that simple to get a new type header ? I am
assuming you meant a new "nxt" header value.

> 	=> 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.   
> 
I guess so. I just verified that one could use other forms of
key distribution and not just IKE with IPsec.

-mohan

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Tue, 31 Jul 2001 02:39:34 +0200

> assuming you meant a new "nxt" header value.
	=> Yes that's what I meant, sorry for confusing the terminology

	Hesham

---

From: Mohan Parthasarathy <[email-masked]>
Date: Tue, 31 Jul 2001 09:21:54 -0700 (PDT)

> 
> I believe that piggybacking is very important and would prefer to keep the
> existing proposal than get rid of it. You can always spend time later
> developing something generic. The current proposal is on-scope and quite
> pragmatic without giving anything up other than it just doesn't use IPSEC.
> 
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

> From: Michael Thomas [mailto:[email-masked]]
> Sent: Tuesday, July 31, 2001 9:32 AM
> To: Jari Arkko
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: Re: [mobile-ip] Concern over
> draft-team-mobileip-mipv6-sec-reqts-00.txt
> 
> 
> Jari Arkko writes:
>  > Of course, we must remember to keep separate the
>  > packet protection and the key management problems.
>  > The minutes from IETF #50 that Vijay referred to
>  > discussed mostly the key management issues. It
>  > seems very clear that there is working group consensus
>  > on that BUs can't use IKE, KINK, PKI, AAA etc.
> 
>    Actually, I don't think there's consensus about
>    _not_ using IKE etc. There is clear direction
>    from the IESG that PKI/centralized keying cannot
>    be the _only_ method of protecting BU's, especially
>    for random MN/CN situations. Where you can use
>    strong crypto (same administrative domain, say),
>    it should be used in preference to a scheme based
>    on a return routability test.
> 
>    One other nit with notes: IPsec (IKE/strong
>    authentication, really) does protect against
>    man in the middle attacks, something that a
>    return routablity test based scheme would not
>    be able to defend against.
> 
>  > But back to the BUs themselves. If it is not possible
>  > to allocate a new next header value, the granularity
>  > of standard IPsec policies isn't today sufficient (no
>  > destination options looked). 
> 
>    I don't understand this: destination options are not
>    supposed to be touched in the middle. Requiring
>    all destination options to be protected -- not just
>    BU's -- sounds like a *feature* to me. This requires
>    no changes to IPsec.
> 
>  > Going further: if it is not possible to keep the BUs
>  > in separate packets, then the above change to the
>  > granularity of packets would be sufficient to send
>  > even piggypacked BUs. In this case the IPsec policies
>  > would state that packets from anywhere to us would
>  > have to have protection if they contained a BU option.
> 
>    If you set up a selector which only selected
>    based on IP addresses, you could piggyback
>    with IPsec as it stands today. I'm not sure
>    that piggybacking is really worth the grief
>    that it's causing though.
> 
> 	     Mike

---

From: "Glenn Morrow" <[email-masked]>
Date: Tue, 31 Jul 2001 12:59:45 -0500

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

-thanks
mohan

---

From: Alper Yegin <[email-masked]>
Date: Tue, 31 Jul 2001 16:38:25 -0700 (PDT)

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

> Is it your concern that there will be too many binding update packets

alper