headers
Pekka Nikander | 1 Oct 09:11

Re: Security requirements for identification

Marcelo,

>> In my opinion, strongly protecting the adding mechanism is really
>> the most important point.  It may be also useful to include a
>> check whenever you start to use a locator after a long period of
>> inactivity, even if the locator is already in the pool.
>>
>> Arranging an attack where you use a given address and stop using
>> it just before your victim arrives and starts to use it seems
>> to be very hard, and probably not worth worrying about.
> 
> Well, then why don't we just extend mip BCE maximum lifetime then?
> If i understand correctly, this is exaclty the type of attack that the
> maximum BCE lifetime bound prevents.

Well, the MIPv6 RO case is more complicated, since the home address
is used as the identifier, too.  In my statement above, I was merely
referring to IP addresses that are used as locators.  If you use an
address as an identifier, there are additional complications.

The biggest burden is probably that all new connections will use
an existing BCE binding.  Hence, if you have once managed to convince
a node that a given *identifier* (home address) is reachable at a
given *locator* (care-of address), you could launch attacks based on
that unless the binding is periodically checked.

Consequently, we would not need the periodic checks on the care-of
address.  However, it is much simpler to just use the base mechanism
and check both care-of and home addresses periodically than to have
a separate mechanism that only checks reachability through the home
(Continue reading)

Permalink | Reply | 0 comments |
headers
Pekka Nikander | 1 Oct 09:28

Properties for identifiers (was Re: Security requirements for identification)

[Dropping HIP ML since this does not concern HIP any more,
  and fixing the subject.]

Tony Li wrote:
> Ok, let me see if I can give a taxonomy of possible
> identifier properties:
> 
> 1. Syntax
> 2. Global Semantics
> 3. Local Semantics
> 3. Generation

In my humble opinion, we should most probably first have
some kind of idea of the semantics, before starting to
consider syntax or generation.  On the other hand, all the
four issues are intertwined, and therefore considering
pure semantics before syntax or generation may be pretty hard.

What comes to semantics, I don't see much value in any
*long* *term* solution where the identifiers have *considerably*
different local and global semantics.  (The only difference I
possibly see is that an ID may be globally anonymous or
pseudonymous while locally well known and linkable to the
real world.)  Personally, I don't mcy want to consider short
term solutions, since I am lacking both interest and expertese
in that area.

 From my long term point of view, I also don't believe in
identifiers that are have any kind of topological semantics.
 From my point of view, one of the most important aspects of the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Juan Rodriguez Hervella | 1 Oct 12:03
Picon

Re: Security requirements for identification

On Wednesday 01 October 2003 00:31, Erik Nordmark wrote:
> > As you mention, there are multiple times that i don't really need to know
> > the identifier of the end-point that i want to communicate to, but what i
> > want is the identifier of the service that i want to contact (is this
> > what you meant?)
>
> Yep.

Hello,

I'm trying to follow this thread, which seems very interesting, but I'm 
surprised with this statement. IMO when you make a DNS query
you want to get the identifier of the end-point, to be able to start
the communication. Although it's true that the name usually
gives hints about the service, this isn't always true. If you
need "www.google.com", you already know that the service will
be "HTTP". You don't ask the DNS for the service, what you really
need to know is the address of "google" to start the HTTP transfer.

Don't you agree with this ?

Cheers.

--

-- 
JFRH
Permalink | Reply | 3 comments |
headers
Spencer Dawkins | 1 Oct 16:18
Favicon

Re: Security requirements for identification

Dear Juan,

I'm also a little confused by the discussion, but I had assumed that
we had a service name and were using DNS SRV records, which also
include port numbers, etc. Not sure how a computer knows
www.google.com is HTTP - or how travel.yahoo.com is also HTTP, if
you're keying off the name...

But somebody can tell us what they REALLY meant now.

Spencer

----- Original Message ----- 
From: "Juan Rodriguez Hervella" <jrh <at> it.uc3m.es>
To: "Erik Nordmark" <Erik.Nordmark <at> sun.com>; <mbagnulo <at> ing.uc3m.es>
Cc: "Erik Nordmark" <Erik.Nordmark <at> sun.com>; "Pekka Nikander"
<pekka.nikander <at> nomadiclab.com>; "Multi6 WG" <multi6 <at> ops.ietf.org>;
<hipsec <at> honor.trusecure.com>
Sent: Wednesday, October 01, 2003 5:03 AM
Subject: Re: Security requirements for identification

> Hello,
>
> I'm trying to follow this thread, which seems very interesting, but
I'm
> surprised with this statement. IMO when you make a DNS query
> you want to get the identifier of the end-point, to be able to start
> the communication. Although it's true that the name usually
> gives hints about the service, this isn't always true. If you
> need "www.google.com", you already know that the service will
(Continue reading)

Permalink | Reply | 1 comment |
headers
Juan Rodriguez Hervella | 1 Oct 18:00
Picon

Re: Security requirements for identification

On Wednesday 01 October 2003 16:18, Spencer Dawkins wrote:
> Dear Juan,
>
> I'm also a little confused by the discussion, but I had assumed that
> we had a service name and were using DNS SRV records, which also
> include port numbers, etc. Not sure how a computer knows
> www.google.com is HTTP - or how travel.yahoo.com is also HTTP, if
> you're keying off the name...

Uh I didn't realize of the existence of DNS SRV records... they
might be talking about that. 

I was thinking about human-machine
interaction which is what most users daily do with computers, i. e,
they open IExplore, they usually type a name and everything ends up well...
IExplore knows the service because it reads the URL. IMO applications
know in advance the service that has to be used (service = port),
so they only need to find the "remote end-point" to start the communication 
with. Not 100% of the applications behave like this, I know, but what I 
wanted to note is that the DNS is used mainly for identification/location
purposes, it is *not* a service lookup....

Anyway, I think this talk  is to be "off topic" in this thread. What I really
would like to know is what they REALLY meant, cause I'm not understanding
a thing (lol)

Cheers ^--^

> But somebody can tell us what they REALLY meant now.
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Erik Nordmark | 2 Oct 00:28
Picon

Terminology

> We clearly need two different words for two different actions:
> 
>    1. Handing over an "identifier" from one end-point to another,
>       with the intention of the receiving end-point being able to
>       contact the "identified" end-point in the future.
> 
>    2. Handing over an end of an (active) association from one
>       end-point to another.
> 
> I was using the term "referral" in the first sense, while you
> seem to be using in the second sense.

FWIW I've been thinking of #2 as "rehoming" while calling #1 "referral".

I think there is also overlapping terminology around "rendez-vous".
I've seen Keith More use this term for the case when applications on
node A and B communicate for a while, and A ends by saying "please contact 
me at A when done". At some later point in time B will use this to get back to
A.

But we are also using it to describe the process where one host finds
another; there are clearly elements of this more general finding
which could instead be described as "lookup".

  Erik
Permalink | Reply | 2 comments |
headers
Erik Nordmark | 2 Oct 00:56
Picon

Re: Security requirements for identification

> I'm trying to follow this thread, which seems very interesting, but I'm 
> surprised with this statement. IMO when you make a DNS query
> you want to get the identifier of the end-point, to be able to start
> the communication. Although it's true that the name usually
> gives hints about the service, this isn't always true. If you
> need "www.google.com", you already know that the service will
> be "HTTP". You don't ask the DNS for the service, what you really
> need to know is the address of "google" to start the HTTP transfer.

Perhaps the "service" vs. "hostname" is confusing. It isn't about the upper
layer protocols in any case.

The issue is that today when you ask for A (or AAAA) records for a given fqdn
you might get back multiple answers, but it isn't clear whether the multiple
answers are
 - multiple IP address for the same host/endpoints (i.e. the entity which
holds 
   the TCP and application state),
 - multiple IP addresses for the service but implemented by different endpoints
 - some combination (6 IP addresses for 3 hosts which each have 2 IP addresses)
 This distinction is important for multi6, since you don't want to try to
failover your TCP/application communication to an endpoint which doesn't have
the  TCP/application state.

Is that more clear?

  Erik
Permalink | Reply | 0 comments |
headers
Pekka Nikander | 2 Oct 07:07

Re: Terminology

Erik Nordmark wrote:

>>We clearly need two different words for two different actions:
>>
>>   1. Handing over an "identifier" from one end-point to another,
>>      with the intention of the receiving end-point being able to
>>      contact the "identified" end-point in the future.
>>
>>   2. Handing over an end of an (active) association from one
>>      end-point to another.
>>
>>I was using the term "referral" in the first sense, while you
>>seem to be using in the second sense.
> 
> FWIW I've been thinking of #2 as "rehoming" while calling #1 "referral".

Oh well.  English seems to be hard language.  I think that we
have at least three different scenarios here.

  1)  Node A has an A-B session with node B.  A sends an identifier
      of node C over the A-B session, allowing B to start a new
      session with C.

      This is what I originally thought that referral means.  This
      is what seems to happen in FTP when you use a PORT command
      that refers to a third host.

  2)  Node A has an A-B session with node B.  A starts a new A-C
      session with node C, and hands over its (A's) end of the
      active A-B session to C, so that the A-B session now becomes
(Continue reading)

Permalink | Reply | 1 comment |
headers
Dave Crocker | 3 Oct 00:13

Re: Terminology

Pekka,

PN> Oh well.  English seems to be hard language.  I think that we
PN> have at least three different scenarios here.

Unfortunately, I think that the problem is not with the language we are
using. I do not think that any of this would go more smoothly in
spanish, japanese or tamil.

Rather, I think we have been using non-technical terms without defining
their technical use. Consequently the use has not been precise.

Although I'd like the words to have a "natural" meaning that is
reasonable, I am more concerned with having precise terms used
consistently.

Unfortunately, the way to deal with a pattern of imprecise use is not to
re-define existing terms, but to throw them away. As Erik notes, we
should mostly not use "address" but should instead use "locator" and
(perhaps) identifier. We need to do the same thing for these other
terms.

So let's stop using _Rendezvous_.

PN>   1)  Node A has an A-B session with node B.  A sends an identifier
PN>       of node C over the A-B session, allowing B to start a new
PN>       session with C.

I think this is consistent with Erik's usage.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Kurt Erik Lindqvist | 3 Oct 19:36
Picon

Fwd: To the attention of all WG Chairs


	
If you haven't seen this.

kurtis -

Begin forwarded message:

> From: Internet-Drafts Administrator <internet-drafts <at> ietf.org>
> Date: fre okt 3, 2003  13:30:24 Europe/Stockholm
> To: IETF-Announce: ;
> Subject: To the attention of all WG Chairs
>
>
>   In order to process the many version 00 I-Ds that are received
> before an IETF meeting in a timely manner, we ask that you send a LIST 
> OF
> THE NAMES of the drafts you expect to have submitted and have approved 
> for
> publication as WG documents to internet-drafts <at> ietf.org  no later than 
> five
> (5) business days prior to the cutoff date for the meeting.
>
>    Please include the word "Permission" in the Subject field.
>
>    This procedure will expedite the posting of version 00 I-Ds, 
> allowing
>    more time for review by the public.
>
>    Thank you you for your cooperation in this matter.
(Continue reading)

Permalink | Reply | 5 comments |

Gmane