Subject: RE: [mobile-ip] Comments on Draft 16

From: Erik Nordmark <[email-masked]>
Date: Thu, 28 Mar 2002 11:52:07 +0100 (CET)

> Or if the binding cache entry is removed/expired, a replayed binding
> update
> will be accepted (assuming nonces are still valid). I am not sure
> how bad is this. But requiring the implementors to store it in NV might
> be a overkill because you have to store one per MN plus the home
> address and how do you know when to ever remove them from NV ?

Mohan,

The issue with non-volatile memory for the sequence number is just an
issue for the HA. BUs sent to CNs rely on fresh cookies to prevent
replays combined with using the sequence number when the CN already has a BCE.
This requires some case (not well-specified in -16) on how to deleted
BCEs at a CN - essentially it needs to keep a tombstone BCE around 
until the cookies used to create it are so old they would be rejected.

Since we're not using RR cookies for the home registration (for better
performance) and allow IPsec with static keys (which can't provide IPsec
replay protection) it seems like we need the sequence numbers to provide
strong replay protection for home registrations.

  Erik

---

From: Samita Chakrabarti <[email-masked]>
Date: Mon, 1 Apr 2002 18:29:17 -0800 (PST)

> 
> > > Although, it adds extra replay protection at HA, I'd think, the
> > > home-agent usage of NV memory could be optional. I'd like to know
> > > how big is the threat in this particular case (i,e if HA reboots).
> > > If we somehow decide that HA should preserve the bindings accross reboot,
> > > then obviously, it makes sense to have all the information intact. 
> > 
> > 
> > Yes. Why don't we use the -15 scheme, describe the remaining threat and
> > make the seqno-preservation through reboots a SHOULD (or a MAY).
> 
> Stable storage at the HA for the seqno can presumably be a SHOULD, with
> the ability to "lock in" on the first sequence number is receives from
> a MN after rebooting.
> But I thought the concerns were more on the MN side (where stable storage 
> would often be implemented using NVram with a finite number of writes
> during the lifetime of the memory.
> We can't relax that constraint as far as I can tell.

I thought that is what Jari was referring to, but perhaps it's not clear.

Thanks for pointing it out.

-Samita

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Tue, 2 Apr 2002 16:59:58 +0200

=> Sure.

  > 
  > That is one possible policy. But there might be other policies
  > that don't require an IPsec VPN when packets are tunneled to home
  > site-local addresses.
  > There shouldn't be a need to pick and cast in stone any 
  > particular policy here
  > as far as I can tell.

=> Ok. I guess organisations that care about 
their security will set the right policies.

  > > => Sure, but I was concerned about the case where
  > > they can reach a site-local address in the home
  > > site, while located at a visited site. Which is 
  > > normally impossible.
  > 
  > But even that isn't unique to MIPv6. A node could run an 
  > IPv6-in-IPv6 tunnel
  > endpoint - one entity outside the firwall and one inside.

=> Right, but today the tunnel will be dropped
if it's not secured. I guess your point 
is that this behaviour does not need to be 
explicitly mandated, it's more like common sense
for administrators to set this policy. Sounds fair enough.

Hesham

---

From: "Glenn Morrow"<[email-masked]>
Date: Tue, 2 Apr 2002 12:34:21 -0600

Sorry I haven't kept up on the mail list lately. I guess this is a generic
tunneling issue. We need to ask ourselves the question, "what harm would
tunneling in unauthenticated packets using site-local source addresses do?".

What are site-locals are use for anyway? I did a search and couldn't find
anything explicit; although there is a proposed use for manet autoconfig. I
guess the only use for it is some sort of guaranteed retriction that
communications are originating from and contrained to a particular site.

So the only harm I might see is that this guarantee could be broken by
tunneling somehow. In the case of a remote node tunneling in site-locals
there is nothing wrong with that as long as you can guarantee that it really
is an authorized remoted node of the network. Note for globals  there is no
auro of perception that the originator was definitely site-local.

Just checking the source address may not help. Any node on a mobile's shared
medium could forge a packet using the mobile's care of address and a site
local in the inner tunnel.

If there is no percieved harm in this then there is no problem. If there is
harm then we might consider putting some statements in the tunneling specs
or the applications which employ their use. 

I'm beginning to get a little confused with what is and isn't a security
requirement and what is a BCP. It seems a bit arbitrary to me how these
decision have been made. With the criteria used for RO'd MIP I honestly
think we might consider reviewing the IPv4 targeting BCPs to see if these
should be made requirements of IPv6. This would be a bit on the extreme side
though. This begs the question should site-local source checks be done on
the ingress into sites?

I think the original suggestion was that we insure that some terminology was
included "somewhere" that RECOMMENDS that a policy of integrity checking be
set up to guarantee the site-local nature. I guess the tunneling specs
should be the place for it. I'm hoping that a few recommended words will map
to a default configuration on routing devices.

Also tunneled link-locals should also require integrity as well. There are
probably more security issues related to these.

Thanks,

Glenn

> -----Original Message-----
> From: Hesham Soliman (ERA) [mailto:[email-masked]]
> Sent: Tuesday, April 02, 2002 9:00 AM
> To: 'Erik Nordmark'; Hesham Soliman (ERA)
> Cc: [email-masked]'; [email-masked]'; Morrow,
> Glenn [RICH2:C330:EXCH]
> Subject: RE: [mobile-ip] Comments on Draft 16
> 
> 
>   > > But my point was, if I want to talk to a site-local
>   > > address inside ericsson.com, while I'm at the IETF
>   > > I would have to have some sort of VPN access
>   > > (IPsec tunnel) to the firewall. I'm assuming that
>   > > someone might want to use site-local addresses 
>   > > inside a site to prevent anyone from reaching the 
>   > > server from outside the site. 
>   > > So if we allow any MN to tunnel a site-local HoA from 
>   > > a CoA through the HA, don't we want to make sure that 
>   > > the tunnel is authenticated to prevent anyone snooping 
>   > > the traffic from creating this tunnel?
>   > 
>   > Yes, but that is because you have a policy, independent 
> of MIPv6, of
>   > wanting VPN protection for your data packets.
> 
> => Sure.
> 
>   >

---

From: "Glenn Morrow"<[email-masked]>
Date: Wed, 3 Apr 2002 13:14:23 -0600

This noncesense is very much appreciated today :). I think you might be on
to something here.

> 
> So is there a better way to solve this problem?  For manually 
> keyed SAs between
> a HA<->MN we could define a new sub-option that carries a 
> timestamp (like
> seconds since Mobile IPv6 became an RFC :), and the HA 
> rejects BUs with the
> timestamp out of a certain range.  Of course this would 
> require synchronization,
> 
> but most MNs should know what time it is...
> 
> -Brian
> 
>

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 4 Apr 2002 18:47:19 +0200 (CEST)

> So is there a better way to solve this problem?  For manually keyed SAs
> between a HA<->MN we could define a new sub-option that carries a timestamp
> (like seconds since Mobile IPv6 became an RFC :), and the HA rejects BUs
> with the timestamp out of a certain range.  Of course this would require
> synchronization,

Something the design team talked about was to do essentially 
an RR check for home registrations when the sequence number isn't known.
Thus the fresh cookie presented in the BU would indicate that the
BU isn't a too old replay.
That seems like a fair amount of complexity to add and the details
haven't been worked out.

So perhaps there is simpler a way to specify rules for handling sequence
numbers for home registrations that have a small replay hole when manual keys
are used, but do not have such a problem when IKE is used to create
the IPsec SAs.

  Erik