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

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Tue, 31 Jul 2001 09:20:05 +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 ?

	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: Vijay Devarapalli <[email-masked]>
Date: Tue, 31 Jul 2001 10:56:28 -0700

>         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.

vijay

---

From: "Jari Arkko" <[email-masked]>
Date: Tue, 31 Jul 2001 23:03:39 +0300

Vijay Devarapalli writes...

> correspondent node. i wouldnt calls this an implementation issue.

The way I see this is that _current_ IPsec selectors can be
used quite fine, IF piggybacking is disallowed AND we have
a separate next header value for BUs. Furthermore, _something_
needs to be implemented in every CN before secure BUs work,
whatever solution we pick. So I don't think we need to argue
about that.

So, in my mind our options are the following (again talking only
about the BU protection, not the key exchange):

    a) The mip-specific scheme in the -14 draft
    b) Standard IPsec usage without piggybacking
    c) Fixed IPsec which enables piggybacked and/or
        option-specific selectors

Personally, my main preferences are either (a) or (b)
solutions. There are differences between these two
approaches, but the main significant question seems
to be if the piggybacking is needed or not. Has someone
looked at the concrete benefits of piggybacking in terms
of numbers somewhere, preferrably taking in account
various header compression schemes that get to be
applied on the most sensitive links? Please note that
separate packets can still be sent in parallel, no additional
RTTs should be introduced. Also, there might be other
factors such as firewall rule sets that affect this discussion.

Jari

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 31 Jul 2001 14:22:47 -0700

Jari,

B cannot work at all. all packets from tbe MN to the CN 
contain a home address option in a destination options 
header. that means the security association is applied 
to every packet between the MN and CN. so 'B' also needs 
option specific selectors.

vijay

---

From: Michael Thomas <[email-masked]>
Date: Tue, 31 Jul 2001 14:35:59 -0700 (PDT)

> option specific selectors.

   Nonsense. All that means is that all traffic with a
   home address option would have crypto applied
   to it. This sounds like a feature to me. Since
   we're going to have a weak version of binding
   updates, you can always use that method if you
   think that crypto overhead is objectionable.

	      Mike

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 31 Jul 2001 15:15:40 -0700

Mike,

we are trying to see how a security association can
be applied only to the BU and not every packet.

vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 31 Jul 2001 15:23:46 -0700

Mike,

be careful with the words you use. what do you mean by
'nonsense'? maybe you are right. but you have no right
to talk like this when you respond to others' mails.
there are more decent ways of disagreeing with people.

i am not using my time here trying to imagine some
crap and putting it out on the mailing list.

vijay