Subject: RE: draft-nordmark-multi6-threats-01.txt

From: <[email-masked]>
Date: Fri, 11 Jun 2004 06:39:14 +0300

Hi Erik & Marcelo,

> > Section 1 - Introduction
> > 
> >      "These attacks pose threats against confidentiality,
> >      integrity, and availability."
> > 
> > I guess that i could make sense to also include impersonation attacks 
> > (or the way you prefer to call them) in which the attacker pretneds to 
> > be one party of the communication, since they are also considered in 
> > the doc
> 
> I think such attacks are and end to accomplish threats against the above.
> For instance, I might be successful in convincing somebody that I am
> Santa Claus, but if they are not going to engage Santa in some way
> that has no effect. If they do believe that they are having confidential
> communication with Santa Claus but they are instead communicating
> (with confidentiality) with me then there was an attack on confidentiality.
> But perhaps "authenticity" should be added to the above list?

Well, I think that authenticated at this layer is very difficult.  One could
make a case that you could authenticate Santa Claus' IP address but not
Santa himself - what if one of his elves is actually talking to you, Erik?

What we should consider is that a multihoming event doesn't cause any
redirection attacks, so that at first you were talking to Santa Claus'
computer then after the event you were talking to Mrs. Claus' computer.

Trying to authenticate the user at the multi6 level probably would be 
impossible & goes beyond the 'do no harm' edict.  

John

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 11 Jun 2004 18:34:54 -0700 (PDT)

> Santa himself - what if one of his elves is actually talking to you, Erik?

Of course. The names at this layer are some identifier - and many proposals
have identifiers that are binary 128 bits. Thus "santa claus" was
merely a prettier way than using 9993:8192:56bb:9258:34:99:8192:5882
as the example.

So restating my example, a threat might be that an attacker can impersonate
9993:8192:56bb:9258:34:99:8192:5882 at the IP/multi6 layer.
But I don't think this impersonation is a means to the end of being able
to attack integrity, confidentiality, or availability.

Thus to me it doesn't seem to add anything listing "impersonation"
at the same level as integrity, confidentiality, and availability.
What does make sense is to look at how the ability to cause redirection
has an impact on I, C, and A.

  Erik

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 13 Jun 2004 03:22:43 +0200

> has an impact on I, C, and A.

And we certainly should not attempt to solve at network or transport
level security issues that can only actually be solved at applications
level, where the network and all its characteristics like multihoming
are just viewed as a cloud anyway. If Santa Claus lets an elf use his
computer, that is not our problem.

    Brian

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 13 Jun 2004 06:01:47 -0700

> computer, that is not our problem.

Unfortunately, some of these issues can't be solved in higher layers if 
lower layers are vulnerable. An example of this is an attack on TCP 
when TLS is in use. Since TLS sits on top of TCP, it can't improve on 
availability (in the presence of an attack) over regular TCP. It can 
only guarantee the integrity and confidentiality of communication that 
actually makes it through. Alternatively, IPsec rejects falsified 
packets before TCP sees them so it also improves availability.

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 13 Jun 2004 18:44:15 +0200

Iljitsch van Beijnum wrote:
> lower layers are vulnerable. An example of this is an attack on TCP when 
> TLS is in use. Since TLS sits on top of TCP, it can't improve on 

Indeed, and if I had written "highly available cloud" instead of just
"cloud" my point would have been clearer. We do need to worry about
availability and therefore about attacks that reduce availability.

    Brian