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 02:19:19 +0200

> > 
> > 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: Mon, 30 Jul 2001 17:46:19 -0700

Hesham,

take a look at this.

http://www.ietf.org/proceedings/01mar/ietf50-91.htm#TopOfPage

look at Jeff Schiller's comments.

vijay

---

From: Jari Arkko <[email-masked]>
Date: Tue, 31 Jul 2001 10:34:05 +0300

Hesham wrote:

>...
>Seems like an implementation issue (the policy part).

Assuming BUs are in separate packets and that 
a new next header value is allocated for them,
I see no problems in using AH. With today's
RFCs and products.

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.

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). The change to add a look
at the destination options is trivial implementation-wise,
though it has been stated that standards-wise adding
such things would take a long time (I'm not really sure
why this is the case).

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.

Jari

---

From: Jari Arkko <[email-masked]>
Date: Tue, 31 Jul 2001 11:01:07 +0300

I have been informed that what I said about the piggypacked
case wasn't quite correct. If there are other policies besides
those dealing with BUs, it might happen that two policies
apply to a single packet. Such a case would need some more
thinking how it can be handled; definition of how the SAs
should be ordered etc.

My conclusions on the separate-packet-with-new-next-header
and separate-packet-with-option cases stay the same.

Jari

---

From: Michael Thomas <[email-masked]>
Date: Tue, 31 Jul 2001 08:03:10 -0700 (PDT)

> look at Jeff Schiller's comments.

   I believe that Jeff's opening comment about IPsec is overly
   broad. RFC 2401 compliant IPsec's do have the ability to
   classify traffic based on the normal 5-tuple which should be
   sufficient for MIP if it doesn't *violate* that requirement,
   which it was in two ways. Both of those violations seem quite
   easy to change within the MIP spec itself to accommodate
   use of IPsec within limited authentication realms.

	  Mike

---

From: Michael Thomas <[email-masked]>
Date: Tue, 31 Jul 2001 07:32:23 -0700 (PDT)

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

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

 > 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: Thomas Narten <[email-masked]>
Date: Tue, 31 Jul 2001 13:20:22 -0400

Michael Thomas <[email-masked]> writes:

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

This is from the top of my head, and may be incomplete, but there have
been a number of issues raised with using IPsec. That doesn't mean
that using IPsec for securing BUs is completely DOA, but it does mean
we may well want to to consider an alternate approach. Some people
feel more strongly about this than others.

Issues:

1) absence of global PKI (which is needed to avoid MITM) note: this is
   likely a "problem" with all proposals.  Unless the two endpoints
   have some sort of shared knowledge (e.g, key, CA, etc.), there is
   no way to avoid MITM.

   Thus, IPsec (if used between MN and CN) would not in practice avoid
   MITM. Thus, it may provide less protection that folks assume, and
   may be a bit more expensive than other approaches that provide the
   same protection.

2) cpu cost of operations is significant, and perhaps overkill given
   the function. (see point 3)
  
3) cost/number of packets involved in setting up SAs. Again, this
   seems to be overkill for the need at hand. It takes a lot of work
   and packets to set up proper state before the BU can be
   authenticated. Has someone done the math to make this clear?
   Maintenance of state on large servers is also an issue that has
   been raised.

   It is one thing to setup state for flows that will use that state
   heavily (e.g., a TCP connection that encrypts the entire flow). It
   is another to setup state that is only used for occasional packets
   (i.e, the ones with BUs).

4) incompatability of how filters are coded compared to what is needed
    As currently specified (and implemented), the IPsec policy
    database doesn't support the desired granularity of filtering. For
    example:

   - It doesn't allow filtering on packets with just a BU. 
   - The current filtering rules do not support selective filtering of
     packets. I.e., either all the packets for a particular flow would
     need to be protected by IPsec (in case one contained a BU) or
     none would (in which case the BU would need to be ignored)

   Note: some these issues could be addressed by writing a
   MIP-specific IPsec document that added more functionality. This
   would need to be done for correspondances between the MN and HA,
   but that might be OK. I.e, implementations of MNs aren HAs are
   presumably special devices and putting extra requirements on them
   are perhaps acceptable. However, it is not clear that it would be
   appropriate (in general) to require all CNs (and by implication
   *all* nodes) to also implement this. But we *are* looking for a
   solution that allows arbitrary MNs and CNs to do route
   optimization.

   In any case, the current (and previous) version of the spec didn't
   have enough details on how to use IPsec in this manner and these
   issues would need to be clarified to fully evaluate this approach.

Thus, while one certainly could imagine making IPsec fit, it is not at
all clear that it is the most desirable approach given the actual
function at hand.

The idea of only allowing BUs as standalone issues would appear to
address some of the issues above, but not all. Of course, eliminating
piggy backing, removes an optimization that also has benefits.

Thomas

---

From: Michael Thomas <[email-masked]>
Date: Tue, 31 Jul 2001 10:55:50 -0700 (PDT)

Any alternate scheme for allowing strong crypto
for BU's where that is appropriate (eg, MN/HA)
would need to have answers for doing automated key
distribution. IPsec currently has ways of using
PKI, pre-shared keys, and Kerberos (both the
GSSAPI mode of IKE and directly using KINK).
There are none for an alternative scheme.

None of the issues you raise, IMHO, come anywhere
close to the extremely high hurdle of building or
extending existing key distribution protocols.

A few more comments in line:

 >    may be a bit more expensive than other approaches that provide the

   What I think we all need to keep in mind is
   that there are really *two* separate problem
   spaces with securing BU's. The one is where
   authentication localization is practical and
   the other where it is not. The MN/HA and _some_
   situations with MN/CN (say, within an
   enterprise) fit category 1. The second problem
   is not practically solved by PKI, etc, and as
   such needs to have some of the requirements
   relaxed (namely, MITM).

 >    Maintenance of state on large servers is also an issue that has

   The state is inherent in symmetric key crypto,
   not IPsec per se. Also: KINK and AAA based
   keying are much better than IKE's 6 message
   main mode/quick mode exchange. AlsoL any
   alternate keying scheme would face the same
   problems. Again, this only applies where you
   can take advantage of strong authentication.

 >    (i.e, the ones with BUs).

   Unless you are willing to require public key
   signed BU's, there is no way to avoid this
   problem. And public key signed BU's would be
   no panecea: public key operations are *very*
   CPU intensive.

 >      none would (in which case the BU would need to be ignored)

   It seems that you're just restating that IPsec
   filters on 5-tuples. Correct?

 >    MIP-specific IPsec document that added more functionality.

   As I've said before, I have no idea why you
   would only want to protect BU's, but not other
   destination options. If the destination options
   weren't piggybacked, they could easily be
   selectively authenticated using standard IPsec.

 > all clear that it is the most desirable approach given the actual

   This needs to be weighed primarily against the
   key distribution problem. I am willing to bet
   $1 that there isn't going to be a lot of
   enthusiasm for writing a BU specific DOI for
   IKE, KINK, etc.

	      Mike

---

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

hi,

I like authentication data as a BU suboption. this 
authentication data protects the BU option and the 
home address option alone. nothing else. draft-14 
gives a cleaner solution for authenticating BU's IMO.

advantages
----------

1. we dont have to get a new next header value for the
destination options header containing the BU

2. we dont have to modify the ipsec selectors

3. we dont have to protect the whole packet

4. we dont have bother about the traffic flows between
the MN and the CN.

5. we can piggyback BU's. somebody asked a question if 
BU's are sent often. YES, BUs could be sent often to 
refresh the bindings. its not necessary the home agents 
agree to very large lifetimes for BUs. and BUs are sent
to everybody in your binding update list everytime you
move.

6. we dont have to store the security association for
protecting the BU in the ipsec database. lookup is 
expensive. it could be stored in the binding update 
list entries. you already have access to the key.

7. authentication checksum calculation can be done 
very early (ie when the BU is being formed). in the 
current implementations you pull the packet out from 
the ip6_output function, calculate the checksum and 
put it out again in the ip6_output function. this is 
because you cant calculate the checksum until the 
whole packet has been formed.

8. mobile ip code just calls hmac_md5 function 
supplying the text and the key. thats all.

so THIS is better. why dont we forget IPSec. hope 
you guys have read Thomas Narten's mail. draft-14 
gives a cleaner alternative solution to IPsec

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 31 Jul 2001 11:32:05 -0700

and the keys are obtained through BAKE or whichever proposal 
that gets accepted.

dont bother IPSec and IKE folks. let them build their VPNs.

vijay

---

From: Michael Thomas <[email-masked]>
Date: Tue, 31 Jul 2001 11:33:41 -0700 (PDT)

Disadvantages:

1) no standard key distribution
2) no means of encryption
3) no means of cipher suite negotiation
4) no standard key distribution

      Mike

---

From: Thomas Narten <[email-masked]>
Date: Tue, 31 Jul 2001 16:18:32 -0400

Michael Thomas <[email-masked]> writes:

> None of the issues you raise, IMHO, come anywhere close to the
> extremely high hurdle of building or extending existing key
> distribution protocols.

I expect that having this group design a new key negotiation protocol
in an attempt to do better/different than IKE is fraught with risks
that have been pointed out by many. We should not consider going there
without really good cause. I do not know that we are at a point where
such a direction is called for or such a decision needs to be made. 

>    What I think we all need to keep in mind is that there are really
>    *two* separate problem spaces with securing BU's. The one is
>    where authentication localization is practical and the other
>    where it is not.

I would like to better understand environments where this is makes
sense. What are some target deployment scenarios where using
pre-shared keys, a local PKI, etc., would make sense?

Also, how would the MN & CN *negotiate* which SA to use? Would it have
to assume one and then not work in any other environment? What happens
when a MN moves outside of the environment where the private PKI is
being used? Can a MN operate in two different realms at differnt
times? How scalable is all this?

I.e., it is not immediately clear to me how useful/desirable it is to
to target the first environment (while ignoring the other) and how one
would handle the case where one moves from one location to another
where different kinds of authentication are appropriate.

I.e, would this satisify the needs of those that want MIPv6 route
optimization?

>    not IPsec per se.

Right. But the cost of the IPsec state and messages is specific to
IPsec/IKE. I think *that* is what is at issue, not that there is
state. Clearly there has to be some state.

>    filters on 5-tuples. Correct?

Yes. 

>    As I've said before, I have no idea why you would only want to
>    protect BU's, but not other destination options. If the
>    destination options weren't piggybacked, they could easily be

I'm not suggesting anything about whether just the BU or all the
destination options should be covered. The issue is that the *current*
specs do not support sufficient granularity for dealing with BUs
within MIP. The question is how do we fix that. Move to something
else? Write a MIPv6-specific IPsec document that specifies how this is
being done (and if so, is this really the direction IPsec should go in)? 

Thomas

---

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

> all clear that it is the most desirable approach given the actual

The list of issues is fine, but I think the discussion would benefit
if we keep the key exchange and the packet protection issues
separate. Global-PKI-as-the-only-BU-key-exchange -issue has
been discussed at length earlier, as is many roundtrip and RSA/
Diffie-Hellman efficiency issues. But these aren't necessarily
reasons to throw out AH, even if they mean IKE isn't applicable.
For instance, the separate-packet-with-new-next-header-value -approach
seems to solve all issues related to the use of standard AH with
RFC 2401 policies. Or did you Thomas have additional problems
even for this case?

Anyway, the discussion around the packet protection is already
ongoing with good contributions on the benefits/disadvantages
of the different approaches.

As far as the key exchange discussion goes, I would like bring
up one point, though. In the global Internet, we can't use PKIs
and other schemes. However, do we have requirements for
smaller parts of the network being able to do this? For instance,
assuming organizations like the DoD have a internal authentication
infrastructure in place, can they secure their internal BUs using _their_
PKI, or are they forced to rely on BAKE only? That is, assuming BAKE
is the scheme for the global world, do the protocols allow DoD to provide
better protection in their network? If so, how?

Jari

---

From: Michael Thomas <[email-masked]>
Date: Tue, 31 Jul 2001 11:41:07 -0700 (PDT)

Are man in the middle attacks always acceptible?
BAKE etc cannot provide MITM protection. Not
having *any* strong authentication mechanism is
a step backward. 

       Mike

---

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

> better protection in their network? If so, how?

have both. rely on DoD's PKI when communicating with CN inside the 
DoD's network. use BAKE (or other competing proposal) only if you 
want to send a BU to a random CN. 

vijay

---

From: Michael Thomas <[email-masked]>
Date: Tue, 31 Jul 2001 17:07:22 -0700 (PDT)

> such a direction is called for or such a decision needs to be made. 

   I agree. This is why I don't like the idea of chucking
   IPsec because, warts and all, it's the devil we know.
   Unless we go crazy and decide that MIP doesn't need
   strong authentiation *ever*, the question of key
   distribution looms very, very large.  
  
 > pre-shared keys, a local PKI, etc., would make sense?

   A good example is a service provider who's provides
   a telephony service, say, which has interoperablity 
   specifications, etc. It's almost certainly the case
   that the security association between the MN and HA
   can and should be protected using strong authentication
   using public key/IKE, kerberos or AAA mechanism for
   keying. In this limited realm, it may also be perfectly
   reasonable to assume that the calls between hosts
   which use the same service may use IPsec to transport
   the telephony signaling (SIP, say) end to end to
   counter threats against SIP (disclosure, forgery...)
   In this case, it would be perfectly natural to allow
   BU's to be protected using the same SA. 

 > times? How scalable is all this?

   There are already mechansims within 2401 to determine what
   security policy to apply to an outgoing SA. Ultimately this
   needs to be populated by the host, perhaps as part of 
   general provisioning. In the Packetcable environment,
   there is just a blanket policy that endpoints use transport
   mode IPsec for signaling traffic. In other environments,
   it may be useful to relax that sort of requirement when
   you aren't behaving as an end node for service X. 

   Security is inherently hard on provisioning and policy.
   I don't think it's really fair to use it as an argument
   for or against as it comes with the territory of trying
   to answer the questions "who are you" and "should I let
   you do this."

 > where different kinds of authentication are appropriate.

   I see absolutely no reason why you'd *ever* want the 
   HA/MN security association to be secured using anything
   other than strong authentication. It has all of the
   desirable realm localization properties. If the IESG
   backs away from strong authentication where it is not
   only possible, but appropriate, it will be sending a
   really bad message that strong authentication is not
   a requirement. I think that would be a very bad message.
   Manifestly: this working group is now asking the question
   of if we don't have to do for some, why should we be 
   doing it for any. Very, very, bad precedent.

 > state. Clearly there has to be some state.

   Why do you think that IKE/IPsec state is more costly than
   other state? I just looked at the state header in freeswan's
   pluto and it's a couple hundred bytes and not optimized for
   memory. The KLIPS SADB probably has a similar amount. I 
   doubt that two optimized implementations are likely to be
   significantly different. 

   As far as messages go -- a keying protocol is a keying
   protocol is a keying protocol. MIP is just another 
   potential DOI and you aren't going to change the 
   fundamental message exchanges just because it's
   MIP. A protocol with better message exchange count
   would equally benefit IPsec as well as whatever
   application layer security you dreamt up.

 > being done (and if so, is this really the direction IPsec should go in)? 
 
   draft-thomas-mip-esp-bu-00.txt describes a mechanism. The
   previous description of AH in the -13 draft was close as well,
   though it needed to not piggyback in some situations as well
   as drop the idea of only authenticating BU's and not all 
   destination options.

		Mike

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 31 Jul 2001 11:55:42 -0700

> 4) no standard key distribution

its three and not four. you cant list a disadvantage twice.
actually cut it down to 1. i dont care about encryption.
keys are obtained through BAKE or some other accepted 
proposal.

vijay