Subject: Re: I-D ACTION:draft-nordmark-multi6dt-shim-00.txt

From: Erik Nordmark <[email-masked]>
Date: Mon, 01 Nov 2004 10:50:59 -0800

Brian E Carpenter wrote:

>> You're right in the general case. However, one could further constrain 
>> flow label allocation for the hosts that implement multi6 so that for 
>> multi6 packets the receiver wouldn't have to compare the locators but 
>> only use the flow label. 
> 
> 
> No, that doesn't work, because two quite independent source hosts might
> choose the same flow label. You have no choice but to look at the source
> locator as well as the label.

It would work with the proper constraints. If some future standard where 
to say that a host should not send a multi6 packet unless the flow label 
had been "approved" (or allocated) by the intended receiver, the 
receiver could ensure that the flows of multi6 packets it receives each 
have a different flow label.
Whether we want to do this is a different point (and I don't think we 
should be overloading the flow label at all).

> Well, I think you could reasonably require that a sender never uses the 
> same
> flow label twice at the same time (that is more constraining than the 
> global
> rule, but probably not a problem in a 20 bit space).

Yes, and "same time" needs to take into account how long multi6 state is 
allowed to remain on a receiver.

> But you don't need to.
> You simply apply the normal rule - make it unique per source and dest ULID
> pair. That should make it unique across the {{source locator},{dest 
> locator}}
> set anyway, and thats's all you need.

My example should that your conclusion doesn't hold.
This is because the ULID->locator set mapping 1) isn't known when 
communication is started and 2) different ULIDs can map to the same 
locator sets (or map to locator sets that are partially overlapping).

   Erik

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 01 Nov 2004 09:26:40 +0100

marcelo bagnulo braun wrote:
>>> Good news. This is wrong (and I didn't realise it when analyzing NOID).
>>> Flow Labels are not unique on their own and cannot be used for
>>> anything on their own. You must always lookup a 3tuple.But if the
>>> received  {Flow Label, Source Locator, Dest Locator} is in the set
>>> {Flow Label, {Source Locators}, {Dest Locators}} corresponding to
>>> a particular {Flow Label, Source ULID, Dest ULID} 3tuple, the shim
>>> *knows* that it is a multi6 packet.
>>
>>
>> If the {flow label, src locator, dst locator} is used to identify the 
>> state then you are right. But that prevents a possible optimization 
>> with changing locator sets (think mobility) by requiring that multi6 
>> signaling be complete to tell the peer of the new locator before that 
>> locator can be used as the source.
>>
> 
> well, but in this case, there is also some security information nneded 
> to authenticate the new locator, so the receiver will have additional 
> information for the demux of this packet i guess.

Exactly. I'm kind of assuming we have something like HBA in place,
so prior knowledge of all locators is needed anyway.

    Brian

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 2 Nov 2004 16:38:22 +0100

El 01/11/2004, a las 9:26, Brian E Carpenter escribió:

>>> If the {flow label, src locator, dst locator} is used to identify 
>>> the state then you are right. But that prevents a possible 
>>> optimization with changing locator sets (think mobility) by 
>>> requiring that multi6 signaling be complete to tell the peer of the 
>>> new locator before that locator can be used as the source.
>>>
>> well, but in this case, there is also some security information 
>> nneded to authenticate the new locator, so the receiver will have 
>> additional information for the demux of this packet i guess.
>

Just one additional nit...
note that HBAs are particularly restrictive in this aspect, since all 
locators need to be known a priori. However, even if you use 
alternative schemes that don't impose such restriction, like CGAs, you 
still need to add security information at least in the same packet that 
carries the new locator.
So even if not all locators need to be known a priori, packets with new 
locators will have to carry additional information to validate the 
locator (e.g. a signature with the private key associated to a cga)

regards, marcelo

>    Brian
------------------------------------------
Please note that my former email address
[email-masked] is no longer in use
Please send mail to:
marcelo at it dot uc3m dot es
------------------------------------------

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 02 Nov 2004 16:28:46 -0800

marcelo bagnulo braun wrote:

> locators need to be known a priori. However, even if you use alternative 
> schemes that don't impose such restriction, like CGAs, you still need to 
> add security information at least in the same packet that carries the 
> new locator.

That requirement isn't obvious to me so I think it would warrant discussion.

The issue is whether it would be ok for the multi6 shim to pass a packet 
to the ULP when the source locator has not been verified as belonging to 
  the peer. We all agree that we need to do such verification before 
*sending* packets to a new locator, but what about just accepting the 
packet?

Things to take into account:
In today's Internet, when there is no ingress filtering anybody can 
spoof the source IP address and the packets will be passed by IP to the 
ULP. However, in today's Internet when there is some ingress filtering 
it is possible to restrict the nodes which can actually spoof the source 
IP address to those that are close to the path between the real location 
of the IP address and the receiving node.

If a host wants to prevent packet injection attacks today (such as 
spoofed RCP RST packets, if it wants to prevent it from all nodes and 
not depend on ingress filtering, wouldn't it use IPsec?

    Erik

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Wed, 3 Nov 2004 08:11:11 +0100

> not depend on ingress filtering, wouldn't it use IPsec?

That would have to be a must. I can't see anyone building a trust model 
based on (the non-existing) ingress filtering. That said, I think most 
protection against packet injection attacks on todays Internet is 
actually left to ULPs.

- - kurtis -

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 3 Nov 2004 12:39:29 +0100

El 03/11/2004, a las 1:28, Erik Nordmark escribió:

>> alternative schemes that don't impose such restriction, like CGAs, 
>> you still need to add security information at least in the same 
>> packet that carries the new locator.
>

agree

> The issue is whether it would be ok for the multi6 shim to pass a 
> packet to the ULP when the source locator has not been verified as 
> belonging to  the peer. We all agree that we need to do such 
> verification before *sending* packets to a new locator, but what about 
> just accepting the packet?
>

good point

> spoof the source IP address and the packets will be passed by IP to 
> the ULP. However, in today's Internet when there is some ingress 
> filtering it is possible to restrict the nodes which can actually 
> spoof the source IP address to those that are close to the path 
> between the real location of the IP address and the receiving node.
>

Well, if we allow hosts to accept packets coming from unverified 
locators and present them as belonging to a different ULP identifier, 
then not even ingress filtering would prevent such attacks. I mean, 
today, if ingress filtering is deployed, then the problem of spoofed 
addresses is reduced. If we allow the reception from unverified 
locators, ingress filtering won't help any more in this problem.
OTOH, i understand that there is a long way between the level of 
security provided by a semi deployed ingress filtering and the level of 
security resulting from requiring the usage of cga or hbas to verify 
any incoming locator. Perhaps a cookie would be enough to validate 
incoming packets (it is clearly not enough to send packet to that 
locator though)

Another point related to this is whether we consider this new incoming 
locator as a hint to rehome the communication to that new locator. In 
this case, we need additional certainty i guess.

regards, marcelo

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 03 Nov 2004 11:27:52 -0800

> locators, ingress filtering won't help any more in this problem.

Agreed.

> security resulting from requiring the usage of cga or hbas to verify any 
> incoming locator. Perhaps a cookie would be enough to validate incoming 
> packets (it is clearly not enough to send packet to that locator though)

A hard-to-guess cookie would probably make things stronger than today
in the absense of ingress filtering. Today's ULP have varying 
verification from SCTPs use of a 32-bit verification tag, TCP's reliance 
on the sequence number being in the window, and UDP with nothing (but 
applications using UDP might have something).

> this case, we need additional certainty i guess.

If it is merely a hint, and there is a cookie to prevent the off-path 
attackers from triggering the hint, that might be sufficient.

    Erik

---

From: Geoff Huston <[email-masked]>
Date: Thu, 04 Nov 2004 08:55:06 +1100

At 06:11 PM 3/11/2004, Kurt Erik Lindqvist wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>

I take it that you are classifying TCP as a ULP in this instance? As I 
understand it TCP attempts to provide protection against packet injection 
attacks and does not allow its ULP any discretion,
while UDP simply passes the packet upward and places the onus on its ULP to 
detect injected bogus packets in the UDP exchange.

regards,

   Geoff

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Sat, 6 Nov 2004 18:37:09 +0100

On 2004-11-03, at 22.55, Geoff Huston wrote:

> I take it that you are classifying TCP as a ULP in this instance?

Yes.

> As I understand it TCP attempts to provide protection against packet 
> injection attacks and does not allow its ULP any discretion,
> while UDP simply passes the packet upward and places the onus on its 
> ULP to detect injected bogus packets in the UDP exchange.

Agreed. I simply meant "something above IP" with ULP...

- - kurtis -

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Sat, 6 Nov 2004 18:37:09 +0100

Yes.

- - kurtis -