headers
Rob Austein | 1 Aug 06:00
Favicon
Gravatar

Weekly posting summary for multi6 <at> ops.ietf.org

    Messages   |      Bytes        | Who
--------+------+--------+----------+------------------------
 24.39% |   10 | 37.33% |    75388 | pekka.nikander <at> nomadiclab.com
 17.07% |    7 | 12.22% |    24684 | iljitsch <at> muada.com
 14.63% |    6 | 13.03% |    26310 | brc <at> zurich.ibm.com
  9.76% |    4 | 12.75% |    25737 | marcelo <at> it.uc3m.es
  7.32% |    3 |  4.89% |     9874 | kurtis <at> kurtis.pp.se
  4.88% |    2 |  3.64% |     7347 | erik.nordmark <at> sun.com
  4.88% |    2 |  3.03% |     6124 | spencer <at> mcsr-labs.org
  2.44% |    1 |  3.73% |     7538 | lear <at> cisco.com
  2.44% |    1 |  1.96% |     3961 | jordi.palet <at> consulintel.es
  2.44% |    1 |  1.87% |     3776 | jari.arkko <at> piuha.net
  2.44% |    1 |  1.60% |     3226 | john.loughney <at> nokia.com
  2.44% |    1 |  1.41% |     2854 | pekkas <at> netcore.fi
  2.44% |    1 |  1.40% |     2817 | vijayd <at> iprg.nokia.com
  2.44% |    1 |  1.14% |     2297 | sra <at> hactrn.net
--------+------+--------+----------+------------------------
100.00% |   41 |100.00% |   201933 | Total

Grunchweather Associates provides this automatic summary on an at-whim
basis at the request of the MULTI6 WG chairs.  Your mileage may vary.
We decline responsibilities, all shapes, all sizes, all colors.
If this script produces broken output, you get to keep both pieces.
Permalink | Reply | 0 comments |
headers
Pekka Savola | 1 Aug 17:02
Picon

comments on draft-ietf-multi6-v4-multihoming-01

Hi,

FWIW, I think section 3 on multihoming motivations is useful.  If we
skip that, I think a relevant part of the v4 background motivations
may get forgotten.  And if we can't formulate well enough our past
mistakes, .....

(Yes, I think it would take some amount of work to boost the section a 
bit, but it'd probably still be very useful.  On the other hand, some 
of those clarifications should already be added to section 5 if not in 
section 3.)

semi-editorial
--------------

5.  Features of IPv4 Multihoming

==> actually, don't these depend quite a bit on the v4 multihoming mechanism
used.  Especially it would be worth pointing out that RFC2260/NAT -based
mechanisms have a significantly smaller subset of these features.

editorial
---------

==> throughout the document, s/enterprise/site/ ?

   again, and as a result some providers decided to start filtering
   prefixes it accepted from peers based on prefix length.  This broke

==> s/it/they/
(Continue reading)

Permalink | Reply | 0 comments |
headers
Erik Nordmark | 1 Aug 20:20
Picon

RE: how much privacy do we need? (was Re: Advantages and disadvantages of using CB64 type of identifiers

[Catching up]

> > So, i agree with Erik that there are three roles that an app can play:
> > - Server
> > - Client
> > - p2p participant
> 
> We have to be careful when using this terminology. The definition of
> server, for example, has two common meanings. For the general public, a
> server is some machine that seats in a computer center and provides a
> set of services. In many protocol definitions, the server is the party
> in the communication that accepts a TCP connection. Obviously, the
> privacy requirements are derived from the first definition, not the
> second one, and we should make that very clear.

I agree it would be confusing.
*If* we need to use terms in this space, I'd suggest we use different
terms than client and server. Initiator and responder (and both) are
the roles the applications play with respect to different ways they
communicate so those might be reasonable terms to use.

Then the actual privacy requirements are derived from the intent of
the user; a single desktop/laptop might have applications that
work as initiators (such as web browsing) as well as responders (a VoIP for
incoming calls).

> The draft states:
> 
>    Today when a site is multihomed to multiple ISPs the common setup is
>    that a single IP address prefix is used with all the ISPs.  As a
(Continue reading)

Permalink | Reply | 2 comments |
headers
Erik Nordmark | 1 Aug 20:31
Picon

Re: Unique identifiers and privacy

> I am concerned with the general statement that we should merely "do no
> worse than the current state of the art". I am specifically concerned
> with the use of long lived unique identifiers. We have already got
> significant feedback on such identifiers in a number of products, e.g.
> identifiers of CPU chips, identifiers of users of audio-video players,
> host identifiers in IPv6, use of social security numbers in data bases,
> and the list goes on. Any unique identifier is a privacy time bomb.

I was confused by your use of "unique" until I realized it can have two
different meanings:
 - unique as in one host having only one identifier
 - unique as in "globally unique" i.e. not being assigned to any other host

For a privacy attacker to be able to correlate different communication
to a single host (which might in turn be used by a single or a few
users) the host would need to use only a single identifier and that
identifier can't be used by too many other hosts in the Internet.
(But global uniqueness probably isn't required since the attacker
might very well be able to cope with a handful of hosts using the same
identifier.)

> Obviously, there are places where unique identifiers are unavoidable.
> For example, one cannot receive mail without publishing a mail address
> of some kind. But there are many places where identifiers are in fact
> not needed. For example, a vast majority of Internet connections involve
> resolving the name of a server, obtaining the server address or
> "locator", and exchanging a few packets between a single pair of
> locators. A cautious design would not mandate use of any identifier in
> such circumstances.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Joe Touch | 2 Aug 15:45
Picon
Favicon

Re: Install DNS mappings based on TLS/IPsec?


Iljitsch van Beijnum wrote:

> On 4-jul-04, at 10:43, Brian E Carpenter wrote:
> 
>> Are you suggesting that the multi6 solution should have a strict
>> dependency on using TLS or IPSEC?
> 
> 
> Certainly not. I'm saying two things:
> 
> - if the DNS doesn't work, discover information that would normally be 
> in the DNS through the TLS or IKE negotiation, and

Sorry for the late addition to the thread, but the use of the DNS for 
forward and reverse lookups is often to provide confirmation of identity.

To that end, DNSSEC is useful, by removing the assumption of trust with 
true trust. The presumption in either case is that if the DNS tree 
verifies fwd/rev, then things are reasonable.

IKE relies either on X.509 keys (a different hierarchy) or preshared 
secrets. At best, all this does is move the problem (DNSSEC certificate 
hierarchy -> X.509 certificate hierarchy); at worst, it exposes the 
endpoint to assuming identity when the pre-shared key could be open 
(compromised, or deliberate).

I.e., it would be necessary (IMO) to limit this to identities exchanged 
by IKE/TLS based on CAs, not based on preshared keys. That may not be 
feasible.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Kurt Erik Lindqvist | 2 Aug 23:46
Picon

Jabber log


The Jabber log of todays session can be found at 
http://www.xmpp.org/ietf-logs/multi6 <at> ietf.xmpp.org/2004-08-02.html

kurtis -
Permalink | Reply | 0 comments |
headers
Iljitsch van Beijnum | 3 Aug 00:07
Favicon

Re: Install DNS mappings based on TLS/IPsec?

On 2-aug-04, at 15:45, Joe Touch wrote:

> the use of the DNS for forward and reverse lookups is often to provide 
> confirmation of identity.

Yes.

> To that end, DNSSEC is useful,

Sure, but that's not the point. The point is that requiring the 
presence of a working DNS is dangerous. Obviously the set of working 
DNSSEC implementations is smaller than the set of working DNS 
implementations so adding DNSSEC only makes this part worse.

> IKE relies either on X.509 keys (a different hierarchy) or preshared 
> secrets. At best, all this does is move the problem (DNSSEC 
> certificate hierarchy -> X.509 certificate hierarchy);

This is an improvement as the X.509 hierarchy doesn't have to be 
traversed in real time (barring caching).

> at worst, it exposes the endpoint to assuming identity when the 
> pre-shared key could be open (compromised, or deliberate).

> I.e., it would be necessary (IMO) to limit this to identities 
> exchanged by IKE/TLS based on CAs, not based on preshared keys. That 
> may not be feasible.

I disagree. The ability to configure trust manually is very useful. 
Obviously when trust is configured using a preshared key this means
(Continue reading)

Permalink | Reply | 1 comment |
headers
Joe Touch | 3 Aug 01:37
Picon
Favicon

Re: Install DNS mappings based on TLS/IPsec?


Iljitsch van Beijnum wrote:

> On 2-aug-04, at 15:45, Joe Touch wrote:
> 
>> the use of the DNS for forward and reverse lookups is often to provide 
>> confirmation of identity.
> 
> Yes.
> 
>> To that end, DNSSEC is useful,
> 
> Sure, but that's not the point. The point is that requiring the presence 
> of a working DNS is dangerous. Obviously the set of working DNSSEC 
> implementations is smaller than the set of working DNS implementations 
> so adding DNSSEC only makes this part worse.

OK.

>> IKE relies either on X.509 keys (a different hierarchy) or preshared 
>> secrets. At best, all this does is move the problem (DNSSEC 
>> certificate hierarchy -> X.509 certificate hierarchy); 
> 
> This is an improvement as the X.509 hierarchy doesn't have to be 
> traversed in real time (barring caching).

How so? If the CA Certs aren't already imported, IKE won't accept them 
until they're verified. If they are, that's equivalent to DNS caching 
its keys, isn't it?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jukka Ylitalo | 3 Aug 03:55

Re: Unique identifiers and privacy

> I am concerned with the general statement that we should merely "do no
> worse than the current state of the art". I am specifically concerned
> with the use of long lived unique identifiers. We have already got
> significant feedback on such identifiers in a number of products, e.g.
> identifiers of CPU chips, identifiers of users of audio-video players,
> host identifiers in IPv6, use of social security numbers in data bases,
> and the list goes on. Any unique identifier is a privacy time bomb.

Hi Christian,

We have presented a HIP variant (see below) in our latest Cambridge
Security Workshop paper that offers identity privacy protection for
long lived unique identifiers, e.g., for HITs. I believe that it is
possible to apply the same mechanism with other wedge layer 3.5
identifiers.

"Jukka Ylitalo, and Pekka Nikander,  "BLIND: A Complete Identity 
Protection Framework for End-points", to appear in Proceedings of the 
Twelfth International Workshop on Security Protocols,  (Cambridge'04), 
Sidney Sussex College, Cambridge, England, April 26-28, 2004."

http://www.hut.fi/~jylitalo/publications/Cam04-Ylitalo-Nikander.pdf

br, Jukka
Permalink | Reply | 0 comments |
headers
Jeff Williams | 3 Aug 07:20
Picon

Re: Install DNS mappings based on TLS/IPsec?

Joe and all,

  It would seem that following what is more and and more recognized
in the commercial world that a need to do better with Bind and the
latest version being more broadly implemented would be more helpful.
See:

    0. http://www.defcon.org/html/defcon-12/dc-12-index.html
    1. http://www.defcon.org/html/defcon-12/dc-12-speakers.html#kaminsky
    2. http://news.com.com/2100-1002_3-5291874.html?tag=nefd.top

Joe Touch wrote:

> Iljitsch van Beijnum wrote:
>
> > On 4-jul-04, at 10:43, Brian E Carpenter wrote:
> >
> >> Are you suggesting that the multi6 solution should have a strict
> >> dependency on using TLS or IPSEC?
> >
> >
> > Certainly not. I'm saying two things:
> >
> > - if the DNS doesn't work, discover information that would normally be
> > in the DNS through the TLS or IKE negotiation, and
>
> Sorry for the late addition to the thread, but the use of the DNS for
> forward and reverse lookups is often to provide confirmation of identity.
>
> To that end, DNSSEC is useful, by removing the assumption of trust with
(Continue reading)

Permalink | Reply | 0 comments |

Gmane