Subject: RE: Fwd: Minutes / Notes

From: "J. Noel Chiappa" <[email-masked]>
Date: Sat, 19 Jul 2003 12:48:14 -0400

> From: "Tony Li" <[email-masked]>

    >> This is only important if you want TCP connections to be able to
    >> survive having an incoming link fail .. This may not be an important
    >> goal

    > I believe that the WG has come to rough consensus that this is, in
    > fact, an important goal for us to solve.

*It is architecturally crucial that the WG resolve this point.*

If you don't need this capability, then the simplest# architectural change you
really need to do widespread multi-homing is multiple addresses. (As I have
pointed out before, separation of location and identity is not really crucial
to do most multi-homing things.)

However, if you want connections to a multi-homed entity to be able to
withstand loss of connectivity to one of the addresses, then you more or less
have to have separation of location and identity.

Saying "oh we don't have to separate location and identity - we'll just use a
set of addresses, the way SCTP does, or a distinguished address, the way
MobileIPv6 does" misses the point: architecturally, even in those cases you
*have* separated location and identity - it's just that the "identity" and
"location" names are drawn from the same namespace.

All the architectural/engineering challenges - such as protecting the binding
between the two against intruders, finding the mappings back and forth,
handling error recovery, etc, etc, etc are basically the same, whether or not
the two namespaces (used for identity and location) are the same or not.

Yes, there may be engineering/architectural advantages to having two separate
namespaces (with or without identical syntax, an intermediate point) - but
that is a *separate* question.

There is also the issue of whether or not you want to carry both the location
and identity in all packets. You more or less have to have the location,
otherwise the packet can't get there. Whether or not you carry the identity
as well is an architectural/engineering question.

There are also engineering questions having to do with TCP (because of the
TCP checksum), and whether or not interoperation with unmodified TCP's is a
goal. The latter can be done, but you're probably going to have to do it with
something that uses MobileIPv6 mechanisms.

I'll stop there for now...

	Noel

#: I said "simplest because there are some other wild ways of doing
widespread multi-homing that involve substantial changes to the routing
architecture.

---

From: "marcelo bagnulo" <[email-masked]>
Date: Sun, 20 Jul 2003 17:41:59 +0200

Hi Noel

> as well is an architectural/engineering question.

As it was mentioned in the meeting, information contained in packets binding
locators to identifiers can not be trusted (unless it is secured with
additional tools), so i guess that it is only needed to carry both
identifier and locators in packets that convey binding information securely
which shouldn´t be in all packets.
So, i guess that you need to carry the locator of the destination, since it
is needed to forward the packet to the destination.
I guess that you don´t need to carry the destination identifier in all
packets.
For the source endpoint information, i am not sure.
I think that carrying the source identifier would make more sense, since it
identifies the other endd of the communication. This would also allow to
configure filters depending on the source identifier making things like
renumbering easier. The first problem that i find with this option is that
you cannot send error messages back to the source (since there is no locator
of the source) when there is a problem and additional mechanisms are needed
to perform reverse mapping in this situation.

So (without much analysis) i would say that packets should contain the
destination locator and the source identifier, but i am certainly missing
many things here.

Regards, marcelo

---

From: Pekka Nikander <[email-masked]>
Date: Sun, 20 Jul 2003 21:10:27 +0300

marcelo bagnulo wrote:
> For the source endpoint information, i am not sure
> identifies the other endd of the communication. 

Carrying a source identifier is harmful.  For our argument, see

Catharina Candolin and Pekka Nikander, "IPv6 Source Addresses Considered 
Harmful," in Hanne Riis Nielson (ed.), Proceedings of NordSec 2001, 
Sixth Nordoc Workshop on Secure IT Systems,  November 1-2, Lyngby, 
Denmark, Technical Report IMM-TR-2001-14, pp. 54-68, Technical 
University of Denmark, November 2001.

http://www.tml.hut.fi/~pnr/publications/nordsec2001.pdf

> This would also allow to

Error messages (ICMP, congestion notification) are about the only
reason why you should have any kind of source names in the average
packets once you make the id/loc separation.

In fact, IMHO it would make most sense to *record* the source *path*
to the packets, somewhat ala itrace, if the id/loc separation is
made.  That would allow one to trace back DoS packets.

(Note that all of the above discussed *generic* packets.  It is a
different issue with the very first packet send by a host to another,
and in any packets that affect the id->locs binding.

--Pekka Nikander

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 20 Jul 2003 23:18:06 +0200

On zondag, jul 20, 2003, at 17:41 Europe/Amsterdam, marcelo bagnulo 

> to perform reverse mapping in this situation.

Having the source identifier rather than a source locator in packets 
might be useful. It certainly makes "big" easier to implement. I don't 
think sending back ICMP messages would be a huge obstacle in practice: 
a box somewhere in the ISP network can source an aggregate route for 
the whole identifier space and replace the identifier in the 
destination address with an appropriate locator.

The ingress filtering issue is a bigger issue. But I think this 
approach may actually strengthen anti-DOS measures rather than weaken 
them, as we're in the position to mandate mechanisms for tracking and 
controlling source addresses for the new identifier space from the 
start. For instance, we could have the mapping between an organization 
and its identifier address space be cryptographically signed by the 
registry. Then whenever abuse is suspected (for instance, because of 
high traffic volumes or complaints) it is possible to send a challenge 
to the source as indicated by the identifier, who can then either 
acknowledge that the traffic is theirs (and use a signature to prove 
this) or deny it so the traffic can be filtered. It should even be 
possible for the acknowledgement to contain information about allowed 
traffic types and rates so illegitimate use of network resources by the 
legitimate holder of an address can be automatically detected and 
stopped. The challenge/response with signature thing can also be used 
to automatically adjust ingress filtering at the ISP side.

---

From: Pekka Nikander <[email-masked]>
Date: Mon, 21 Jul 2003 11:10:26 +0300

Iljitsch van Beijnum wrote:
> might be useful. 

That might form a serious privacy problem, as I mentioned
in an earlier message.

> The ingress filtering issue is a bigger issue. 

If the source address field semantics is changed to record
the route rather than to contain an address that is filtered,
the problem gets trivially solved.  That change does *not*
change routers that are not aware of the change.  Hence, such
a change can be made incrementally, without any flag days.

--Pekka Nikander

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 21 Jul 2003 16:17:11 +0200 (CEST)

> identifies the other endd of the communication. 

For the source part (locator vs. id) we need to understand how multicast
routing would work. Today it applies RPF to the source address and uses the
hierarchical structure of the source address to aggregate the information used
by the RPF. If the source identifiers are not aggregatable this will be an
issue.

> to perform reverse mapping in this situation.

The ability to return packets without much overhead, such as an ICMP error or
a  TCP SYN, might be important to avoid a class of DoS attacks om routers.
Having the source locator in the packet
means that an ICMP error can be generated without performing
any ID->locator mapping

  Erik

---

From: Pekka Nikander <[email-masked]>
Date: Mon, 21 Jul 2003 20:43:35 +0300

Erik,

> by the RPF. If the source identifiers are not aggregatable this will be an

I have to admit my ignorance here.  Any pointers that would allow
me to better understand what you say above?  Especially, I don't
understand if the "source" address you talk about is the source
address in a packet, or the addresses (locators) of the members
of a multicast group.

--Pekka Nikander

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 22 Jul 2003 10:23:11 +0200 (CEST)

> address in a packet, or the addresses (locators) of the members

Steve Deerings PhD thesis explains it all :-)
Google finds some easier things at:
http://www.google.com/search?hl=en&ie=UTF-8&oe=UTF-8&q=reverse+path+forwarding+multicast
but no good summary as far as I could tell.
(I think there was an mboned intro to multicast I-D somewhere but I can't find 
it).

In summary there is a source-rooted distribution tree which is independent
of the multicast group (which is carried in the destination address field).
The source rooted tree conceptually exists all the time and there is
a separate tree for every source address, but the actual tree is built
on demand - details depending on the multicast routing protocol which is
used.

The tree is then pruned based on the precence of members in the multicast group
to try to avoid to deliver packets down braches where there are no members
i.e. no interested receivers. The details of the tree pruning are different
for different multicast routing protocols.

The resulting issue for multihoming appears if a site wants
to forward packets towards the rest of the internet from more than
one attachment point.
If the same packet ends up with different source addresses/locators 
when exiting through N different border routers (e.g. due to source
locator rewriting by the routers) then the RPF checks will
operate on two different trees and as a result each receiver will receive
N copies of every packet.

  Erik

---

From: Keith Moore <[email-masked]>
Date: Sat, 19 Jul 2003 13:37:04 -0400

[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
  and therefore delete posts by non-subscribers.  if you wish to regularly
  post from an address that is not subscribed to this mailing list, send a
  message to <listname>[email-masked] and ask to have the alternate
  address added to the list of addresses from which submissions are
  automatically accepted. ]

]     >> This is only important if you want TCP connections to be able to
]     >> survive having an incoming link fail .. This may not be an important
]     >> goal
] 
]     > I believe that the WG has come to rough consensus that this is, in
]     > fact, an important goal for us to solve.
] 
] *It is architecturally crucial that the WG resolve this point.*

It is essential that TCP connections be able to survive link failures.  If you
don't have this, you basically have to re-implement much of TCP at a higher
layer.  (Typically, explicit acks for application data, the ability to detect
a lack of acknowledgment and to retransmit unacknowledged application data,
and to gracefully handle duplicate transmissions of application data.)

---

From: Brian Haberman <[email-masked]>
Date: Tue, 22 Jul 2003 06:47:58 -0400

> N copies of every packet.

Well, some of this depends on the multicast routing protocol in use
and the implementation.  Your description is much closer to what
dense mode protocols do for multicast forwarding (DVMRP and PIM-DM).
PIM-SM will build the distribution tree prior to data flowing.
When PIM-SM builds source-rooted trees, the RPF check will be built
on the Locator value, not the ID since the RPF is a topological
check.

The issue of multiple trees due to multi-homing can be modeled in
much the same way that multicast is implemented over load-balancing
links.  That is, a single forwarding entry is instantiated and
"locked" to a path.  Of course, you would probably lose forwarding
state during an outage.

With SSM, the forwarding entry will be tied to specific source
address.  In SSM and multi-homing this may have to be the ID
rather than the Locator, even though the Locator is needed for
the RPF check.

Regards,
Brian

---

From: Måns Nilsson <[email-masked]>
Date: Wed, 23 Jul 2003 12:48:28 +0200

--On Saturday, July 19, 2003 13:37:04 -0400 Keith Moore <[email-masked]>
wrote:

> It is essential that TCP connections be able to survive link failures.
> If you don't have this, you basically have to re-implement much of TCP at
> a higher layer.  (Typically, explicit acks for application data, the
> ability to detect a lack of acknowledgment and to retransmit
> unacknowledged application data, and to gracefully handle duplicate
> transmissions of application data.)

I agree -- this is important, and if altered would break lots of things. 

-- 
Måns Nilsson            Systems Specialist
+46 70 681 7204         KTHNOC  MN1334-RIPE

We're sysadmins. To us, data is a protocol-overhead.

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 24 Jul 2003 11:56:50 +0859 ()

Marcelo;

> additional tools),

And it was an error corrected at the meeting.

Binding between locators and identifiers in single packets have
just enough security.

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 24 Jul 2003 12:20:15 +0859 ()

Pekka;

> http://www.tml.hut.fi/~pnr/publications/nordsec2001.pdf

You forgot the fact that the Internet is a public network.

							Masataka Ohta

---

From: Pekka Nikander <[email-masked]>
Date: Thu, 24 Jul 2003 07:26:02 +0300

> Binding between locators and identifiers in single packets have

Strongly disagree.  See the flooding attacks in
http://www.ietf.org/internet-drafts/draft-nikander-mobileip-v6-ro-sec-01.txt

They do not, as such, directly apply to multi-homing,
but you can fairly easily find out variants that do.

--Pekka Nikander

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 24 Jul 2003 13:37:11 +0859 ()

Pekka;

> > Binding between locators and identifiers in single packets have

It should also be noted that binding between locators and identifiers
in single DNS reply packets have just enough security.

> They do not, as such, directly apply to multi-homing,

Notification of locator changes, of course, needs its own
security, which does not apply to multi-homing issue here,
not even indirectly.

> but you can fairly easily find out variants that do.

Wrong.

The variant (or a simple case) is an issue to be addressed by
return routability and/or DNS reverse/forward mapping just as
current IPv4 or 6.

							Masataka Ohta

---

From: "marcelo bagnulo" <[email-masked]>
Date: Thu, 24 Jul 2003 11:19:30 +0200

Hi Masataka,

What about time shifting attacks?
I mean you can solve it with RR, but this implies periodical exchanges such
as MIPv6.
I do agree that DNS packet excahnge are susceptible to this kind of attacks,
but currently you have the option of using directly the IP address
preventing such attacks. However, if you build an insecure id/locator
binding, you cannot prevent them, so i guess we do not want to do this
Besides there are flooding attacks, as mentioned in Pekka´s draft.

IMHO we should really consider this draft as a valuable input to the design
of the solution, since it describes many issues that have to be considered.
Underestimating these issues will only delay the solution.

Regards, marcelo

> -----Mensaje original-----
> De: Masataka Ohta [mailto:[email-masked]]
> Enviado el: jueves, 24 de julio de 2003 6:38
> Para: Pekka Nikander
> CC: marcelo bagnulo; J. Noel Chiappa; [email-masked]
> Asunto: Re: Fwd: Minutes / Notes
>
>
> Pekka;
>

Wrong.

							Masataka Ohta

---

From: "marcelo bagnulo" <[email-masked]>
Date: Thu, 24 Jul 2003 11:29:31 +0200

Hi Masataka, Pekka,

> Enviado el: jueves, 24 de julio de 2003 5:21
> Para: Pekka Nikander
> CC: marcelo bagnulo; [email-masked]

So? What do you mean?, could you be a bit more explicit?.

Actually, IMHO it is the oposite, this article assumes that packets are not
trusted by default. I mean, most of the time, the information carried in
packets such as the source address, has not been modified. (this is
essentially due to the fact that nobody is interested in spoofing most of
web surfing packets or my email exchange with my friends, since there is no
point to do so).
So i do not think that we need high crypto security by deafault...

So i guess that my question would be: is it a reasonable approach to use
crypto in all comunications? (such as HIP)

Perhaps this is the most simple way to safely decouple loc and ids (so we do
it for simplicity and not because it is the only way to achiev the required
security level)

Regards, marcelo

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 24 Jul 2003 20:36:53 +0859 ()

Marcelo;

> I mean you can solve it with RR, but this implies periodical exchanges such

Huh?

> I do agree that DNS packet excahnge are susceptible to this kind of attacks,

Huh?

I'm afraid you don't correctly understand the requirement for weak and
strong securities.

> of the solution, since it describes many issues that have to be considered.

Your problem is that our design team has already completed the design
with all the issues resolved.

> Underestimating these issues will only delay the solution.

No. We did not underestimate anything and the solution is already
available that there is no delay.

							Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 24 Jul 2003 20:44:14 +0859 ()

Marcelo;

> So? What do you mean?, could you be a bit more explicit?.

On what? Could you be a bit more explicit?.

> crypto in all comunications? (such as HIP)

Are you saying autoconfiguration of shared secret for the crypto?

I am aware that some people are stupid enough to believe it possible.

HIP is a lot less stupid merely assuming that an initial identity is
kept cryptographically securely preserved, even though the initial
identity is not cryptographycally secured.

							Masataka Ohta

---

From: Pekka Nikander <[email-masked]>
Date: Thu, 24 Jul 2003 15:45:57 +0300

> crypto in all comunications? (such as HIP)

I don't think so.  There certainly is some communication that
does not need any protection at all in addition to what is
provided by the application layer.

On the other hand, it has been stated that there certainly is
some communication that does not need the added flexibility and
robustness provided by the id/loc separation.

Now, there is a good question:  Do we get four distinct subsets,
each of a reasonably big size, or is any of the four subsets
so small that we can almost ignore it:

   - non-robust, non-flexible, non-protected traffic (current IP)
   - non-robust, non-flexible, protected traffic (current IPsec?)
   - maybe-multihomed, maybe-mobile, non-protected traffic
   - maybe-multihomed, maybe-mobile, protected traffic

The id/loc mapping itself needs some kind of protection, or otherwise
we get new nasty DDoS attacks using all hosts, even uncompromized
ones, as zombies.  The actual traffic may or may not need protection.
It is a know deficiency in the current HIP spec that it does not
directly support non-protected traffic.  However, if unencrypted,
non-integrity protected ESP was allowed, one could use the SPI
in the ESP header as a kind of condensed identifier, without
any cryptographic protection.

--Pekka Nikander

---

From: Pekka Nikander <[email-masked]>
Date: Thu, 24 Jul 2003 15:58:22 +0300

Masataka,

> in single DNS reply packets have just enough security.

No, it doesn't, see below.

>>Strongly disagree.  See the flooding attacks in
...
> return routability and/or DNS reverse/forward mapping just as

Please get your facts right.

1. I create the following DNS records for myself
    (using A here for AAAA just to make the point...)

    pnr.iki.fi.         IN IDENTITY XXX
    pnr.iki.fi.         IN A        131.112.32.132
    pnr.iki.fi.         IN A         81.17.193.194

    [For those who don't want to check,
     81.17.193.194 is pnr.iki.fi,
     131.112.32.132 is necom830.hpcl.titech.ac.jp]

2. I order a large number of streams, all
    associated with XXX, directed to 81.17.193.194
    These can be TCP or UDP streams...

3. I start sending acknowledgements with source
    address spoofed to 131.112.32.132

4. The hosts shipping the streams think that my
    link to 81.17.193.194 has just crashed, and
    start shipping the packets to 131.112.32.132

The rest should be clear.  Yes, you can defeat
this particular scenario by saying that in IPv6
ingress filtering will be universally deployed,
but there are other, more complex ones where
ingress filtering does not necessarily help.

--Pekka Nikander

---

From: "marcelo bagnulo" <[email-masked]>
Date: Thu, 24 Jul 2003 17:19:35 +0200

> De: [email-masked] [mailto:[email-masked]]En
> nombre de Pekka Nikander
> Enviado el: jueves, 24 de julio de 2003 14:46
> Para: marcelo bagnulo
> CC: Masataka Ohta; [email-masked]
> Asunto: Reasonable to use crypto in all communications? (Re: Fwd:
> Minutes/ Notes)
>
>

I would say that none of those 4 types can be negliged.

> any cryptographic protection.

I am not so sure.
I would say that inlcuding unprotected identifiers instead of unprotected
locators is weaker, since locators are somehow verified by the routing
system and ingress filtering and identifiers (as currenlty proposed) are not
verified. I mean, it would be trivial to impersonate an identifier, since
the packet would be routed using the locator (this is not the case if
locator and identifier are the same). Am i missing something?

marcelo

---

From: "marcelo bagnulo" <[email-masked]>
Date: Thu, 24 Jul 2003 17:29:35 +0200

> nombre de Masataka Ohta
> Enviado el: jueves, 24 de julio de 2003 13:38
> Para: marcelo bagnulo
> CC: [email-masked]

Please read MIPv6 spec and Pekka´s draft about ro security design

> I'm afraid you don't correctly understand the requirement for weak and

I was agreeing with you, so i am not sure what we are discussing now :-)

> with all the issues resolved.

This is not a problem, it is great!

Could you please give us a pointer to the documents that explain the
security issues?

Regards, marcelo

---

From: Pekka Nikander <[email-masked]>
Date: Thu, 24 Jul 2003 18:38:20 +0300

> locator and identifier are the same). Am i missing something?

Using an unprotected identifier (or a pointer to a cached
identifier) allows an attacker to send packets that may
be delivered to a wrong socket.  I don't see anything new there.

Allowing an unprotected packet to set up or change
identifier -> locator mapping seems to be dangerous.

Return routability based on a cryptographic challenge-response
that binds the different addresses genuinely together looks
like a secure enough solution.  However, it is hard to
implement in fewer than 3-4 messages (1.5 to two round trips)
without opening a resource exhaustion danger at the passive end.
An IP layer resource exhaustion attack would be more severe
than a TCP layer one, IMHO.

--Pekka Nikander

---

From: "marcelo bagnulo" <[email-masked]>
Date: Thu, 24 Jul 2003 18:05:30 +0200

> identifier -> locator mapping seems to be dangerous.

This is the case i was thinking about, i.e. packets carrying both id and
locator unprotected (and that haven?t been previously bound in a secure way)

If this is dangerous, a possibility is to use some sort of crypto for each
node that you are communicating with in order to perform the binding. the
other possibility is some sort of RR check, as you mention below. Other
choices?

My original question was if a solution that rerquires crypto for each
communication (not for every packet) is acceptable.

The problem with RR check is that it has to be done periodically in order to
prevent time shifting attacks. However, in the multi-homed case, perhaps
this could be avoided. I mean, an important difference between mobility and
multi-homing is that in multi-homing all the possible addresses are known in
advance. this means that they can be exchanged when the communication with
the other end is initiated. This reduces the critical packets to the initial
ones. So perhaps a solution that performs a RR check to all possible
addresses of a communication when the communication is initiated would be
acceptable. There are still some time shifting attacks that have to be
considered though.

Perhaps crypto would provide a simpler solution anyway

Regards, marcelo

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 25 Jul 2003 01:10:07 +0859 ()

Pekka Nikander;

> No, it doesn't, see below.

Yes, it does.

> The rest should be clear.

Ignoring the mistake that using source address of 131.112.32.132
does not make its peer that 81.17.193.194 has crashed...

Yes, lacking proper acknowledgements from 131.112.32.132, the
peer will terminate the stream.

That is, you can't send proper acknowledgements, unless you can
receive packets to 131.112.32.132, which is the return routability.

It should also be noted that there is no amplificaiton here that
it is no worse than ICMP echo requests with spoofed source addresses.

> Yes, you can defeat

Yes, similar attack is, for example, possible with

    pnr.iki.fi.         IN MX        10 pnr.iki.fi,
    pnr.iki.fi.         IN MX        20 necom830.hpcl.titech.ac.jp
    pnr.iki.fi.         IN A         81.17.193.194
    necom830.hpcl.titech.ac.jp IN A        131.112.32.132

and sending a lot of erroneous mails from pnr.iki.fi to
random recipients.

So?

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 25 Jul 2003 01:14:58 +0859 ()

Pekka Nikander;

> The id/loc mapping itself needs some kind of protection,

For most mapping, cookie is the protection.

For mobility mapping, the protection should use shared secret.

> However, if unencrypted,

It is a poor form of cookie with so much extra overhead.

							Masataka Ohta

---

From: Pekka Nikander <[email-masked]>
Date: Thu, 24 Jul 2003 19:40:10 +0300

> peer will terminate the stream.

Exactly.

> receive packets to 131.112.32.132, which is the return routability.

Not true.  If you open a TCP session and receive the first
few packets, it is easy enough to generate fake ACKs.
I can dig up a reference if needed.  You can even make
it look like the bandwidth is much higher than it is,
thereby clogging a pipe even with just one or few
streams.  All you need to do is to get a stream that
is originally directed to yourself to be now directed
to the victim, with the possibility of generating faked
ACKs.

Some people claim that it is even easier to fake ACKs
for some UDP based protocols, but I don't know the details.

> it is no worse than ICMP echo requests with spoofed source addresses.

Not true, see above.

> and sending a lot of erroneous mails from pnr.iki.fi to

The problem is that the attacker is able to make the
stream to continue uninterrupted, since it can fake
the acks very easily.

If you make a false MX, the MXed host will not
accept the mail.  Hence, in that case application
level stops the attack.

--Pekka Nikander

---

From: Pekka Nikander <[email-masked]>
Date: Thu, 24 Jul 2003 19:42:06 +0300

> For mobility mapping, the protection should use shared secret.

Depending on the definition of cookie, I may agree.
Depending on how you get the shared secret, I may agree.

Hence, please be more specific.  And please explain in
detail how you *bootstrap* the system.
Assuming a global PKI is not a solution.

--Pekka Nikander

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 25 Jul 2003 02:11:29 +0859 ()

Pekka Nikander;

> detail how you *bootstrap* the system.

It is of course that cookie is exchanged with three way handshake
and the shared secret is shared OOB.

Note that the shared secret is necessary only between HA and
MH (rest is done by cookie) that the secret is shared when
MH owner asks HA service to the administrator of the HA and
configured to MH when a HA address is configured.

> Assuming a global PKI is not a solution.

I know very well why PKI is not useful.

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 25 Jul 2003 02:27:50 +0859 ()

Pekka;

> few packets, it is easy enough to generate fake ACKs.

Assuming that there is no packet losses and that the attacker
send acks slowly enough, maybe.

> streams.

See above.

> All you need to do is to get a stream that

Note also that there is no victim host. See below.

> for some UDP based protocols, but I don't know the details.

You can, of course, design such protocols by yourself.

However, hosts supporting such protocols are compromised from
the beginning.

> > it is no worse than ICMP echo requests with spoofed source addresses.

Actually, it is weaker than echo attack, because packets to XXX is
never received by any IP layer and ICMP host unreachable will
be returned.

> stream to continue uninterrupted, since it can fake

See above.

> accept the mail.  Hence, in that case application

Only after the resource of transport and application layers is
wasted, which means a successful DoS attack.

							Masataka Ohta

---

From: Pekka Nikander <[email-masked]>
Date: Fri, 25 Jul 2003 08:37:37 +0300

> send acks slowly enough, maybe.

The attacker doesn't need to send the acks very slowly. See

Stefan Savage, Neal Cardwell, David Wetherall, and Tom Anderson,
"TCP Congestion Control with a Misbehaving Receiver",
CCR, 1999.

Note especially that after some initial data stream,
the attacker can ignore incoming data (attack 3).

--Pekka Nikander

---

From: Pekka Nikander <[email-masked]>
Date: Fri, 25 Jul 2003 08:49:25 +0300

Ohta-san,

As so many times before, I am getting tired, since
this discussion is getting more or less ridiculous.
But that may be my fault, of course.

> and the shared secret is shared OOB.

It is good that you think that we need a 3-way handshake
for a cookie.  There we may agree.

Assuming a shared secret, exchanged OOB, between any two
arbitrary hosts in the Internet, is, well, interesting.
But apparently you are not claiming that.

> configured to MH when a HA address is configured.

What is a HA in a multi-homing situation?  Are you assuming
some kind of infrastructure at the Internet, i.e. outside
of the multi-homed network?  If so, you open up the space
for zillions of interesting solutions, most of which have
very interesting single-point-of-failures or bottlenecks.
And even in the simple case bootstrapping the shared secret
between the multi-homed host and the infrastructure may
turn out much more challenging than what you seem to assume.

--Pekka

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Fri, 25 Jul 2003 07:18:31 +0200

Ohta-san,

> I am aware that some people are stupid enough to believe it possible.

This is not a very professional remark, actually quite the opposite. 
Please try and keep this discussion on a professional level. Everyone 
have their right to their view, even if that is not in line with what 
you think.

- - kurtis -

---

From: Pekka Nikander <[email-masked]>
Date: Fri, 25 Jul 2003 09:20:26 +0300

Marcelo,

> other possibility is some sort of RR check, as you mention below. Other

I am not aware of other possibilities, but of course there may
be others.

What comes to crypto binding, I am only aware of two possibilities:
Using asymmetric keys (or something similar) as primary identifiers,
or using CGA (or something similar).  All the other solutions that
I know about require some kind of infrastructure, some kind of
an enrollment procedure, or both.

CGA is encumbered with IPRs, as we know.

Using public keys as primary identifiers is basically HIP.
Of course, you can design the exact details to be fairly
different from what HIP currently is, but it is most probably
very hard to do without a kind of four-way handshake without
opening serious DoS vulnerabilities.

> advance. 

Hmm.  Good points.  The real question is whether the verifying peer
is able to make a distinction between a mobility and multi-homing
situation.  That is, if there is a real multi-homed host, it probably
has a set of fairly stable addresses.  However, there might be an
attacker that has a transient address but that claims that the transient
address is one of its stable addresses.  If it is able to convince
the verifying party that the transient address is a stable address,
that seems to open up time shifting attacks.

--Pekka Nikander

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 25 Jul 2003 17:16:53 +0859 ()

Pekka Nikander;

Yes, it does.

Wrong.

As the paper says:

	Moreover, if an ACK arrives for data that has not yet
	been sent, this is generally ignored by the sending TCP

the attacker must be able to know the current sequence number of
a sender and reply ACKs with a sequence number a little more
than that, or the ACKs are ignored.

That is, the attacker should send ACKs slowly enough not to
exceed the sequence number currently used by the sender.

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 25 Jul 2003 17:25:14 +0859 ()

Kurt;

Could you quote with more context?

> This is not a very professional remark, actually quite the opposite. 

It is a remark on people observed in other WG believing in
autoconfigured security. As my remark continued, HIP, for
example, does not assume so.

On the other hand, statement like:

> Date: Wed, 16 Jul 2003 14:58:45 +0200
> Subject: More random and not so random thoughts
> From: Iljitsch van Beijnum <[email-masked]>
> Message-Id: <[email-masked]>

> About the roadmap/more desing teams thing: I'm afraid of a situation 
> where a good core idea doesn't take some limitations in consideration 
> so the resulting proposal is flawed. It looks like this is already the 
> case with e2e/lin6,

is not a very professional remark, actually quite the opposite,
because it is a unfounded and weak remark contributing nothing
constructive.

							Masataka Ohta

---

From: Pekka Nikander <[email-masked]>
Date: Fri, 25 Jul 2003 11:48:41 +0300

...

Exactly.
> exceed the sequence number currently used by the sender.

Right, but that is not very slowly.  Indeed, it may induce
a faster data rate from the sender than the receiver is
able to receive.

--Pekka Nikander

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 25 Jul 2003 17:45:51 +0859 ()

Pekka;

> But that may be my fault, of course.

That, seemingly, is because you are agreeing with me.

> But apparently you are not claiming that.

So, there is no disagreement.

> What is a HA in a multi-homing situation?

Good question.

> Are you assuming
> of the multi-homed network?

Not at all.

HA is a server serving mobile hosts.

As is stated in my presentation of e2emh:

	IPv4 home agent is an end system

		provided by end users, just as WWW servers

		Foreign agent is intelligence in the network

HA is an end system, a server host, and does not belong to an
infrastructure of the Internet, just as WWW servers does not
belong to the infrastructure.

Thus, HA in a multi-homed site, of course, have multiple locators.

In addition, a mobile host may be served by multiple HAs.

It is already designed, implemented and running.

> If so, you open up the space

So, there is no disagreement.

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 25 Jul 2003 17:59:27 +0859 ()

Pekka;

> Right, but that is not very slowly.

I never said "very slowly", though the attacker should behave
conservatively to keep the attack continuing.

> Indeed, it may induce

As I said, there is no "receiver", a host with ID XXX.

						Masataka Ohta

---

From: "marcelo bagnulo" <[email-masked]>
Date: Fri, 25 Jul 2003 15:26:01 +0200

> that seems to open up time shifting attacks.

Yes. However, the attack is only possible at the begining of the
communication and it is not possible for the rest of the communication
lifetime (which would be the mobility case)

This is still less secure than regular IPv6 but the time that the nodes are
exposed to attacks is much more limited. I do not know if this would be good
enough, though.

Regards, marcelo

---

From: Pekka Nikander <[email-masked]>
Date: Fri, 25 Jul 2003 21:11:11 +0300

> lifetime (which would be the mobility case)

Right.  However, the attacker is most probably able to select
the most convenient time to initiate communication.  Hence, I don't
see this much changing the situation.

> exposed to attacks is much more limited. I do not know if this would be good

The real question is whether there are attacks against standard
non-multi-homed hosts or flooding attacks against networks.
It looks like there might be.

I am starting to think that we would need a proper security
analysis on multi-address multi-homing.  I might be willing
to spend some cycles on writing a draft on that, but only
later in the fall  (starting from mid September or so).

--Pekka NIkander

---

From: "marcelo bagnulo" <[email-masked]>
Date: Mon, 28 Jul 2003 10:04:58 +0200

> De: Pekka Nikander [mailto:[email-masked]]
> Enviado el: viernes, 25 de julio de 2003 20:11
> Para: marcelo bagnulo
> CC: [email-masked]
> Asunto: Re: Reasonable to use crypto in all communications? (Re: Fwd:
> Minutes/Notes)
>
>
> marcelo bagnulo wrote:

I think there is an important difference. As you mention, the attacker can
initiate a new communication whenever he wants, but he cannot hijack an
already initiated communication, which would be possible in the mip scenario
by just sending a BU in an existent communication.

> later in the fall  (starting from mid September or so).

I think that this would be really usefull. I am willing to try to comment if
you write something.

Thanks, marcelo

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 28 Jul 2003 17:12:49 +0200 (CEST)

> later in the fall  (starting from mid September or so).

I think that would be very useful.

  Erik

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 29 Jul 2003 10:35:20 +0859 ()

Marcelo;

> by just sending a BU in an existent communication.

You are too optimistic. There is no meaningful difference.

A reasonable attacker will act as a MITM always hijacking new
communications. As the MITM relay them to legitimate peers most
of the time, you won't notice the presense of MITM.

Then, the attacker, at will, can suspend relaying and insert any
forged data into an already initiated communication.

> > analysis on multi-address multi-homing.

So far, it is just a well known MITM attack no specific to multihoming.

							Masataka Ohta

---

From: "marcelo bagnulo" <[email-masked]>
Date: Tue, 29 Jul 2003 11:15:02 +0200

> So far, it is just a well known MITM attack no specific to multihoming.

Again, have you heard about time shifting attacks?
This type of attack is not possible in regular IPv6 communications and
multi-homing mechanisms can enable them.
The same goes for some flooding attacks.
But you still are not interested in reading Pekka' s draft, i guess :-(
Regards, marcelo

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Tue, 29 Jul 2003 12:59:45 +0200

> example, does not assume so.

No, but you are attributing a view on the intelligence of people 
proposing a certain solution. This is what I am telling you to stop.

> because it is a unfounded and weak remark contributing nothing

This does not attribute anything to anyone. It talks about a specific 
proposal.

Please refrain from comments on other members of the WG. Feel free to 
argue over their proposals as long as you include reasoning for your 
own views.

Best regards,

- - kurtis -

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 29 Jul 2003 20:31:04 +0859 ()

Marcelo;

> Again, have you heard about time shifting attacks?

Have you ever serached the phrase "time shifting attacks" on the web?

There is no such attack.

Please don't try to invent new terminology for nothing.

Wrong.

> The same goes for some flooding attacks.

By inventing "time shifting attack", you ignore two facts, at least.

One is that DoS can not be prevented.

The other is that there is timeout on bindings.

							Masataka Ohta

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Tue, 29 Jul 2003 14:19:23 +0200

> Have you ever serached the phrase "time shifting attacks" on the web?

Google gives me 14 hits for that exact spelling. "time shifting" 
attacks gives me 948 hits.

> There is no such attack.

The links from Google seems to indicate otherwise.

- - kurtis -

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 29 Jul 2003 21:33:39 +0859 ()

Kurt;

> proposing a certain solution. This is what I am telling you to stop.

The stupidity is of those people merely stating their vague desire
not proposing any kind of solution to satisfy it.

I understand that is not what you wrongly told me to stop.

> This does not attribute anything to anyone. It talks about a specific 

It attributes something to someon who made the proposal.

> Please refrain from comments on other members of the WG.

You please refrain from comments on other members of the WG.

							Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 29 Jul 2003 21:52:08 +0859 ()

> Google gives me 14 hits for that exact spelling.

Haven't you checked them originated from Marcelo and his party?

It is trivially easy to have 14 bits with google that it means
nothing.

							Massataka Ohta

---

From: "marcelo bagnulo" <[email-masked]>
Date: Tue, 29 Jul 2003 15:47:11 +0200

This is my last mail on this thread.

please read draft-nikander-mobileip-v6-ro-sec-01.txt

and then we can continue this exchange (probably when you read the draft
there will be no need to continue this, though)

i cannot say that i have invented those attacks, not even the terminology,
these are described in the draft and i am not one the authors.
I guess that the google hits that Kurt discovered are not my responsability
neither.

marcelo

> Enviado el: martes, 29 de julio de 2003 13:32
> Para: marcelo bagnulo
> CC: Pekka Nikander; [email-masked]

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 30 Jul 2003 14:37:18 +0859 ()

Marcelo;

> This is my last mail on this thread.

That should be wise for you.

Never try to use a strange terminlogy on such a common attack
mode merely to use a compromised entity for latter attacks.

						Masataka Ohta

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 30 Jul 2003 13:52:19 +0200 (CEST)

> an enrollment procedure, or both.

I guess I don't really understand your categorization.

If one wants to have the IP packets be bound to some existing identity
(like something one would find in a PKI: subject-name [email-masked]
with some particular trust anchor) then one would always need something
at least approximating a PKI.

If one is only concerned about the IP packets be bound to some ephemeral
(and meaningless to higher level protocols?) identity than one can either
have the primary identifier be variable length (e.g. a public key; 
a (self-signed) certificate), or fixed length (e.g. a hash of a public key
or a hash of a (self-signed) certificate).
That still allows the identifiers to be long-term stable, as well as new
identifiers being fabricated on the fly to get "anonymity".

Finally, if one only is concerned about being able to verify that some IP
packet is sent by the same entity that sent some previous IP packet, then
PBK type approaches would seem to fit (e.g. do an anonymous DH exchange up
front and use the resulting key to protect changes to the id/loc mapping.)

  Erik

---

From: S Woodside <[email-masked]>
Date: Wed, 30 Jul 2003 14:00:34 -0400

Please attack the ideas that people express and not the people.

simon

--
www.simonwoodside.com -- 99% Devil, 1% Angel

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 31 Jul 2003 06:45:03 +0859 ()

simon;

> Please attack the ideas that people express and not the people.

There is no idea to attack expressed.

There are people insisting on their terminology on nothing.

							Masataka Ohta

---

From: S Woodside <[email-masked]>
Date: Wed, 30 Jul 2003 22:52:10 -0400

> There is no idea to attack expressed.

Then attack the non-existence of the idea and not the people ...

simon

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 31 Jul 2003 12:49:05 +0859 ()

simon;

: There is no idea to attack expressed.

: There are people insisting on their terminology on nothing.

> Then attack the non-existence of the idea and not the people ...

That is an attack only on the first problem but, yes, I did so,
but Marcelo insisted.

						Masataka Ohta