Subject: [RAM] GSE security

From: RJ Atkinson <[email-masked]>
Date: Tue, 2 Jan 2007 17:35:44 -0500

% Well, GSE is certainly missing the security paraphernalia.
% I think that we all pretty much agree on that.

I'd rephrase the first sentence as:
	The existing published GSE Internet-Drafts did not go into
	detail about how information might be authenticated.

And then I'd note that not having written the security paraphernalia
down is wildly different from "it is impossible to secure".

Ran

_______________________________________________
RAM mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ram

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 3 Jan 2007 03:06:05 +0100

> down is wildly different from "it is impossible to secure".

fully agree

but do we also agree that when security is included in GSE, the result 
is not nearly as nice as the current GSe proposal?

I mean, what i really find attractive of the current GSE proposal is 
that the routers that perform the rewriting are almost stateless. They 
only need to know the globally routable prefix they need to rewrite the 
source address with and that's it.

I don't think this is possible when you include the security. In this 
case, you would need some state associated to the particular identifier 
and its associated locator set as well as the security information to 
bind them

But again i am assuming a certain threat model and from previous emails 
with you, i am not sure we are making the same assumption here, so 
maybe we should first start to discuss what threats do we want to 
protect any solution from...

Regards, marcelo

---

From: RJ Atkinson <[email-masked]>
Date: Wed, 3 Jan 2007 08:10:40 -0500

On  2 Jan 2007, at 21:06, marcelo bagnulo braun wrote:
> do we also agree that when security is included in GSE,
> the result is not nearly as nice as the current GSe proposal?

No scientific case has been made here that detailing how GSE
can be authenticated necessarily proves the resulting form of GSE
is "not nearly as nice".

If someone wants to try to make such a case on list, that would be
fine.

I suspect that it is hard to prove that for the universe of all
possible security approaches, GSE ends up being "not nearly so nice".

I'd also submit that "not nearly so nice" is a pretty subjective
criterion.  I'd prefer that we operate with more objective and
measurable criteria.

Ran

---

From: Eliot Lear <[email-masked]>
Date: Thu, 04 Jan 2007 17:28:18 +0100

Ran,

Let's be clear about the security concerns with GSE.  If someone in the 
middle is mucking with the RG (routing goo) is it sufficient for 
purposes of IPSEC to secure the lower eight bytes?  I'm sure this was 
talked about way back when, but I don't know that it was put into print.

The argument at the time as I recall it from Steve Deering was that TCP 
has the barest form of security through the overloading of the two name 
spaces with the pseudo-header checksum.  If we give up on the notion 
that this really provides ANY security in this day and age, what is left 
from a security standpoint?

Eliot

---

From: David Meyer <[email-masked]>
Date: Thu, 4 Jan 2007 09:29:11 -0800

> down is wildly different from "it is impossible to secure".

	Well said, and I'd add vastly different than "has been
	explored (not) and we conclude that "it is impossible to
	secure"".  (i.e., since GSE as considered dead, people
	[understandably] stopped working on it).

	--dmm

---

From: David Meyer <[email-masked]>
Date: Thu, 4 Jan 2007 09:32:04 -0800

> is not nearly as nice as the current GSe proposal?

	Well, that's hard to say, since GSE really hasn't been
	fleshed out (AFAICT).

	--dmm

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 4 Jan 2007 18:41:52 +0100

> criterion.  I'd prefer that we operate with more objective and

fair enough

did anyone ever provided a security architecture for GSE? if so, do you 
have a pointer? i guess this is the first thing we need in order to be 
able to see the full picture of GSE...

Regards, marcelo

---

From: David Meyer <[email-masked]>
Date: Thu, 4 Jan 2007 10:10:12 -0800

> able to see the full picture of GSE...

	To the best of my knowledge, no. But then, as I said,
	people don't generally publish negative data (or work on
	protocols that are perceived to be dead).

	--dmm

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 4 Jan 2007 14:11:43 -0500

On  4 Jan 2007, at 13:28, marcelo bagnulo braun wrote:
> i think that in what we differ in in the view on how GSE security  
> would look like if done.
> I have tried to figure it out and what i found is that we will need  
> per identifier locator binding state (including security  
> information) in the edge routers and that the resulting solution  
> differs considerably from the current GSE proposal

I do not believe that per-ID/Locator binding state is needed
in the edge routers to have a reasonably secure solution that
is part of the GSE/8+8 class of solutions.

I believe the threat analysis falls into basically 2 situations
(assuming the hurdle is not set higher than we have today
for the deployed IPv4 Internet).

1) Some protection against off-path active attacks (e.g. on binding
	updates), where that protection is not computationally expensive
	because the threat environment is believed low.
2) Serious cryptographic protection against all forms of forgeries,
	because the threat environment is believed high,
	where AH is an example of an existing sufficient solution.

Ran
[email-masked]

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 5 Jan 2007 02:34:37 +0100

El 04/01/2007, a las 20:11, RJ Atkinson escribió:

>> per identifier locator binding state (including security information) 
>> in the edge routers and that the resulting solution differs 
>> considerably from the current GSE proposal
>

this goal makes sense to me (but we may have different perception of 
what the current vulnerabilties are)

> 	because the threat environment is believed low.

What about the so-called time shifted attacks?
And flooding attacks?
Should we provide protection against those?

(especially the first ones are quite tricky to protect from)
(please see RFC4225 and RFC 4218 for a definition of these attacks)

Regards, marcelo

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 5 Jan 2007 08:27:50 -0500

> (please see RFC4225 and RFC 4218 for a definition of these attacks)

It is not reasonable to require more from IPv6 or some enhancement
to IPv6 than we currently require from *the deployed IPv4 Internet*
with regards to various kinds of attacks.  Generally speaking,
security solutions for one version of IP also will apply to another
version of IP.  The kinds of architectural enhancements that I've
seen discussed on the RAM list don't obviously change that.

All of the kinds of things you cite above are possible today in
the IPv4 Internet, absent using something with strong cryptography
-- along the lines of ESP/AH. 
ESP/AH are available for both IPv4 and IPv6, and presumably for
any IPv6 enhancements.  In fact, the original ESP/AH code at NRL
was mostly the same code path, with just a few branch instructions
that were based on the IP version field.

So those items you cite above are not legitimately in the scope
for the situations where "the threat environment is believed low".

Ran

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 05 Jan 2007 16:37:22 +0100

> seen discussed on the RAM list don't obviously change that.

Maybe not, but possible defences may exist in IPv6 that don't
exist in IPv4; at least, I don't see how you can do any kind of
cryptographcally generated addresses in IPv4.

    Brian
> -- along the lines of ESP/AH. ESP/AH are available for both IPv4 and 
> IPv6, and presumably for

---

From: Roland Dobbins <[email-masked]>
Date: Fri, 5 Jan 2007 07:49:56 -0800

> to IPv6 than we currently require from *the deployed IPv4 Internet*

Why not?  That's how it was 'sold', and that's what a large number of  
people seem to think, that IPv6 through the use of 'mandatory'  
encryption is magically more 'secure' than IPv4.  What's wrong with  
a) expecting more from IPv6 and/or successors and b) working to  
provide IPv6 and/or successors with more actual security properties/ 
strengths/capabilities than IPv4?

> version of IP.

This isn't necessarily the case - for example, the 'recommended' use  
of /64s for link addressing has the unintended consequence of turning  
every router into a sinkhole for either scanning Slammer-type  
malware, which could result in a DoS, or a deliberate scanning-type  
attack intended as a DoS.  For another, the ND mechanism in IPv6  
differs pretty significantly from what's present in IPv4, and there  
may be some additional ways to leverage that as a DoS mechanism, and  
thus different self-protection measures required.

-----------------------------------------------------------------------
Roland Dobbins <[email-masked]> // 408.527.6376 voice

		   Technology is legislation.

                     -- Karl Schroeder

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 05 Jan 2007 10:54:47 -0500

It looks to me like people are talking past each other.
So let me see if I can paraphrase several points from different people.

Everyone agrees that some forms of security are needed for use with 
GSE style (or in fact most any style) addresss / locator 
separation.  Exactly what needs to be secured varies from case to 
case, but typically, the issue is updates to the binding between 
identifiers and locators.

Clearly, if one is really concerned about security (high threat 
environment, where one cares about the attacks a great deal) there 
are powerful mechanisms that can be applied.  These range up to usage 
of AH-like mechanisms and/or cryptographic addresses, etc.

Equally, there are lower threat environments.  For example, a web 
server providing public service is not interested in authenticating 
the clients (even if the client is interested in authenticating the 
server by default some times.)  And such services are fully prepared 
to invoke much stronger mechanisms (TLS, etc) when appropriate.  Even 
then, we probably want some protections against some attacks.  I read 
Ran's note as suggesting that for this case, something close to the 
current capabilities, possibly with extra strength against off-path 
attacks might be a quite sensible alternative.

Now, if the solution we craft provides additional security in all 
cases, or make it available when desired, that's nice.  But lets not 
get so caught up in our security desires that we demand the 
impractical.  (I remember a proposal to prevent DoS on each and every 
link in the Internet many years ago that was clearly theoretically 
beautiful and powerful but was impractical to implement.)

Yours,
Joel M. Halpern

---

From: Roland Dobbins <[email-masked]>
Date: Fri, 5 Jan 2007 08:04:39 -0800

On Jan 5, 2007, at 7:54 AM, Joel M. Halpern wrote:

> are powerful mechanisms that can be applied.  These range up to  
> usage of AH-like mechanisms and/or cryptographic addresses, etc.

There's a lot more to security that crypto and auth - namely, DoS  
vectors/defenses/resiliency.  That's a primary concern, along with  
the ability to provide useful encyption/auth/anonymization  
capabilities as is desired and is practical.

> cases, or make it available when desired, that's nice.  But lets  
> not get so caught up in our security desires that we demand the  
> impractical.

Of course; but we need to ensure the system doesn't fall over at the  
touch of a feather, either, heh.

                     -- Karl Schroeder

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 5 Jan 2007 18:40:51 +0100

El 05/01/2007, a las 14:27, RJ Atkinson escribió:

> with regards to various kinds of attacks.

agree

>   Generally speaking,

well there are some solutions that can work in only one version of IP...

>  The kinds of architectural enhancements that I've
> any IPv6 enhancements.

you mean time shifted attacks and flooding attacks?

If you do, previous security analysis didn't came to the same 
conclusion...

AFAIK, the first analysis on redirection attacks related to some for of 
locator id split was performed by the mobile IP community and they did 
imho very good analysis on RFc4225. Their conclusion was that neither 
time shifted attacks nor flooding attacks were possible in todays v4 or 
v6 internet and that any new tool for spliting the identifier role from 
the locator role must provide protection against those. Hence they 
designed the return routability procedure (which is periodically 
performed) in order to prevent those.

Later on, the threat analysis for multihoming was performed and the 
result is rfc4218 and both time shifted attacks and flooding attacks 
were considered and it was required that solutions must provide 
protection against those.

So, having worked in finding solutions for those, i must say that it is 
quite tricky and that a solution that is not required to address those 
will be significantly simpler.

So, should we or should we not provide protection against time shifted 
and flooding attacks caused by id/locator split protocols?

I must say that i personally think we should because i think the 
resulting attacks are serious and are beyond what is possible in today 
internet, but i would like hear other people's opinion on this one.

(I am not 100% sure but i think that during mip design they first 
didn't considered this type of attacks and they stated that anyone that 
wnated more protection could simply use IPSec and the protocol was 
returned to the wg by the security IDs because it was not secure 
enough, maybe people that was there can expand on this....)

Regards, marcelo

>  In fact, the original ESP/AH code at NRL

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 5 Jan 2007 18:53:54 +0100

Hi Joel,

good summary, thanks.

El 05/01/2007, a las 16:54, Joel M. Halpern escribió:

> GSE style (or in fact most any style) addresss / locator separation.  
> Exactly what needs to be secured varies from case to case, but 
> typically, the issue is updates to the binding between identifiers and 
> locators.
>
> environment, where one cares about the attacks a great deal) there are 
> powerful mechanisms that can be applied.  These range up to usage of 
> AH-like mechanisms and/or cryptographic addresses, etc.
>

i agree with all your points... the next question is what is the 
minimum level of security acceptable. Previously many folks thought 
that providing protection against time shifted attacks and flooding 
attacks was mandatory for the lowest level of protection... do we still 
think this is the case or shall we go for a lower minimum?

Regards, marcelo

---

From: Jari Arkko <[email-masked]>
Date: Fri, 05 Jan 2007 20:29:47 +0200

Ran,

I agree with your principle, but I'm not sure what it has
to do with Marcelo's list of vulnerabilities. I'm pretty sure
whatever ID-Locator separation design we plan to have,
we don't want it to open significant new vulnerabilities
from what we have in the current Internet. Perhaps we'd
even like it to close some existing ones, at least some
designs do that (whether its worth the cost is another
question).

Anyway, back to the issue of not opening any new
vulnerabilities: If the design allows switching hosts from
one locator to another, we wouldn't like such changes
to be announced by just any unrelated entity in the
Internet. Similarly, we don't want the design to allow
malicious hosts to be able to amplify their denial-of-service
capabilities, e.g., through using redirection and third
parties.

Jari

---

From: Roland Dobbins <[email-masked]>
Date: Fri, 5 Jan 2007 12:22:44 -0800

On Jan 5, 2007, at 9:40 AM, marcelo bagnulo braun wrote:

> So, should we or should we not provide protection against time  
> shifted and flooding attacks caused by id/locator split protocols?
>
> resulting attacks are serious and are beyond what is possible in  
> today internet, but i would like hear other people's opinion on  
> this one.

I concur with your assessment, especially with regards to flooding  
attacks.

                         -- Karl Schroeder

---

From: Tony Li <[email-masked]>
Date: Fri, 5 Jan 2007 12:57:33 -0800

On Jan 5, 2007, at 9:40 AM, marcelo bagnulo braun wrote:

> result is rfc4218 and both time shifted attacks and flooding  
> attacks were considered and it was required that solutions must  
> provide protection against those.

Whoa.  Attacks are considered, but solutions for all such attacks  
were not supposed to be required by 4218.  In particular, attacks  
that exist today under IPv4 need not be solved.  Well, that was the  
intent, anyway...

Tony

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 5 Jan 2007 22:34:51 +0100

El 05/01/2007, a las 21:57, Tony Li escribió:

> Whoa.  Attacks are considered, but solutions for all such attacks were 
> not supposed to be required by 4218.
>  In particular, attacks that exist today under IPv4 need not be 
> solved.  Well, that was the intent, anyway...
>
> Tony
>

exactly that is what i am asking about time shifted attacks...
i quote RFC 4218

4.1.2.  Time-Shifting Attack

    The term "time-shifting attack" is used to describe an attacker's
    ability to perform an attack after no longer being on the path.
    Thus, the attacker would have been on the path at some point in time,
    snooping and/or modifying packets; and later, when the attacker is no
    longer on the path, it launches the attack.

    In the current Internet, it is not possible to perform such attacks
    to redirect packets.

...

    It would be reasonable to require that a multihoming solution limit
    the ability to redirect and/or DoS traffic to a few minutes after the
    attacker has moved off the path.

4.3.  Third Party Denial-of-Service Attacks

....

    In today's Internet, the ability to perform this type of attack is
    quite limited.

...

  Thus, the multihoming
    mechanism probably needs some form of defense against third party DoS
    attacks, in addition to the help we can get from the transport
    protocols.

So, rfc4218 identifies that both these attacks are not possible (or 
limited) in today internet and that new multihoming solutions should 
try to prevent them

Regards, marcelo