headers
Kurt Erik Lindqvist | 1 Jul 09:57
Picon

Re: identifiers and security


[Catching up a bit]

On 2004-06-28, at 13.52, Erik Nordmark wrote:

>
> Thus something which is quite insecure (weaker than NOID as above) when
> IPsec isn't used, but when IPsec is used it is as strong as with IPsec 
> in
> today's Internet.
> Is anybody interested in exploring these ideas further?

Personally I think that we at some point need to clarify the "do no 
harm" view. I.e do we want to try and achieve something better than 
today? Or is relying on the security extension headers of IPv6 give us 
some slack? Or do we just agree that the world is ok today and trying 
to do better is shooting for the stars?

I personally wouldn't mind aiming for something a bit higher than today.

kurtis -
Permalink | Reply | 5 comments |
headers
Kurt Erik Lindqvist | 1 Jul 10:05
Picon

Re: about Wedgelayer 3.5 / Fat IP approaches


On 2004-06-28, at 14.35, Erik Nordmark wrote:

>> In this case, the multi6 layer could provide enhanced services and
>> preserve connectivity even if the locator used on the refferral or 
>> call
>> back becomes unreachable.
>> So i guess that we can have 4 cases:
>> a- non multi6 aware app running on a non multi6 aware host: in this
>> case a locator must be used for refferals
>> b- non multi6 aware app running on a multi6 aware host: in this case
>> the app will pass the 128 bit string that it is using to the other 
>> end.
>> So the multi6 layer has to be capable to obtain the locator set form
>> this 128 bit string i.e. we need an id to locator mapping mechanism
>
> It is actually more constrained than that since other instances of
> the application might be running on non-multi6 aware hosts.
> So the conservative approach would be to always hand an IP 
> address/locator
> to unmodified applications, that way the application can use it
> for callbacks and referrals without any constraints on which hosts the
> different instances of the app is running.

For a transition scenario this will most likely more be the rule than 
the exception. SIP comes to mind of an application where you would do 
referrals and you can not trust that all "nodes" are of the same 
"instance"/protocol version/awareness.

kurtis -
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jeff Williams | 1 Jul 11:58
Picon

Court Says Customers May Take IPs Away From ISP - profound impact on RIR's as well?

All,

  "Huston, I think we have a problem"!
 http://www.merit.edu/mail.archives/nanog/msg05815.html

  Could this perhaps have an impact on the current allocation
and Multihoming in IPv6 in the near term?  Seems so.

Regards,

--
Jeffrey A. Williams
Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!)
"Be precise in the use of words and expect precision from others" -
    Pierre Abelard

"If the probability be called P; the injury, L; and the burden, B;
liability depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security
IDNS. div. of Information Network Eng.  INEG. INC.
E-Mail jwkckid1 <at> ix.netcom.com
 Registered Email addr with the USPS
Contact Number: 214-244-4827
Permalink | Reply | 1 comment |
headers
Kurt Erik Lindqvist | 1 Jul 10:10
Picon

Re: identity persistence and comparison issues


On 2004-06-28, at 14.45, Erik Nordmark wrote:

>> What if we just always show the application a long-lived identifier,
>> even though when it sets up a session we use ephemeral identifiers?
>
> That's part of what Jukka and I were pondering a bit.
> I think it is very interesting; just need to make sure that
> the additional local mapping on the host from the long-lived to
> the ephemeral doesn't introduce attacks that we don't know how to
> handle.

Without having thought this through very much I have a few questions on 
this,

As you would need to keep state that would be very much like a cache. 
Would you not open your self up for "cache-poisoning" very much like 
todays DNS?

kurtis -
Permalink | Reply | 1 comment |
headers
Kurt Erik Lindqvist | 1 Jul 10:31
Picon

Re: Court Says Customers May Take IPs Away From ISP - profound impact on RIR's as well?


On 2004-07-01, at 11.58, Jeff Williams wrote:

> All,
>
>   "Huston, I think we have a problem"!
>  http://www.merit.edu/mail.archives/nanog/msg05815.html
>
>   Could this perhaps have an impact on the current allocation
> and Multihoming in IPv6 in the near term?  Seems so.

No.

And there is a lot more to this story than what is in that email. And 
it is all very off-topic for this list.

kurtis -
Permalink | Reply | 0 comments |
headers
Erik Nordmark | 1 Jul 10:49
Picon

RE: about Wedgelayer 3.5 / Fat IP approaches


> So, assuming that HIP hosts started to use low order bits of the
> HIT in their locators, and then used such a locator as an AID,
> the main differences I see are in the use of/reliance on PK crypto
> in the context establishment handshakes, as well as IPsec reliance 
> (HIP relies on PK signings for handshakes, and relies on IPsec, 
> while CB64 relies on neither), and some of the basic protocol 
> mechanisms of the two proposals (which one might argue are just
> details):
> - CB64 handshake occurs in parallel with start of data transfer
> (actually, after first data packet has been sent), while HIP holds
> the first packet waiting for HIP handshake to complete (or
> possibly piggybacks it on the HIP exchange). 

I think this is the only issue which is tied to the type of ID that
is used. In HIP as defined, since the ID used by the transport is not a
locator, the handshake must occur before ULP packets can be exchange.
But with a CB64 AID that is also a locator one has the option
to do them concurrently or even defer the handshake.

> - CB64 uses flow IDs and locators as keys to find context state
> for the session, while HIP uses IPsec SPIs

And Pekka Nikander has told me that it wouldn't be hard to have HIP
optionally use the same scheme if HIP wanted to support the case when
the payload is not encrypted.

> - CB64 adds new locator for peer upon discovering it as a source
> address in a packet (and issuing PK-signed challenge/response), 
> while HIP explicitly signals the new locator in a signed HIP
(Continue reading)

Permalink | Reply | 2 comments |
headers
marcelo bagnulo braun | 1 Jul 11:07
Picon

Re: about Wedgelayer 3.5 / Fat IP approaches

>
>> Another difference is length of the hash of the key, which may
>> cause some subtle differences.  With 64 bit IDs (or, strictly
>> speaking, ID tags, since the public keys are the actual
>> identifiers), we can provide an embedded stack name in the AID,
>> whereas with HITs, we can only provide a mapping between
>> (truncated) stack name and AIDs.  When we have discussed
>> shortening HITs to accommodate some structure to aid reverse
>> lookups, there have been concerns raised that 64 bit IDs might
>> not be strong enough to withstand server farm attacks in the
>> future (generating different key that hashes to same ID).
>> If a larger hash is used as the identifier, then the AID with
>> truncated HIT can be viewed as a slightly less secure
>> identifier used for support of referrals for non-multi6/HIP
>> aware apps, which keeps the door open for future HIP-aware
>> apps to directly use the full IDs.
>
> But there are some cases where the larger ID (that doesn't fit in the 
> AID
> seen by the ULPs) does not help.
>
> Example: busy server receives a context from a client with large ID = X
> and AID=P1 | hash(X)
> Server later receives a context from a client with large ID = Y
> and AID=P1 | hash(Y)
> and the hash values are identical.
>
> Even though the multihoming layer can disambiguate the two contexts, it
> can not handle both at the same time because the ULP can not tell them 
> apart.
(Continue reading)

Permalink | Reply | 1 comment |
headers
marcelo bagnulo braun | 1 Jul 11:24
Picon

Re: identifiers and security

>> I think if the redirection problem by attackers that are on-path
>> temporarily is limited to individual unprotected sessions, we are not
>> materially worse off than today as the same attacker could break the
>> sessions today also, and redirecting an unprotected session presumably
>> isn't worse than breaking it as the contents aren't secret.
>
> I think there is a difference between
>  - someone breaking into to office looking at the pieces of paper on
>    my desk
>  - someone breaking into my office and installing a device which allows
>    them to look at all future pieces of paper I will place on my desk
>
> Thus there is a difference between looking at unprotected communication
> while being on the path, and looking at unprotected communication
> long after having left the path.
> But this might be a case where we can make things be slightly worse 
> than
> in today's Internet since this communication was unprotected in any 
> case.
>

I am not sure how slightly this is...

suppose a host A with Locator LA
A server B with locator LB
and an attacker X with locator LX

A usually connects to B to get some information, for instance the news.

Now, X manages to be on the path between A and B for a while.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Kurt Erik Lindqvist | 1 Jul 11:40
Picon

Re: Engaging apps folks


On 2004-06-29, at 14.08, Erik Nordmark wrote:

> My experience, and I think Kurt said something similar, is that it
> is hard to engage application folks without something concrete like
> a proposal that they look at. This makes it tricky to get feedback 
> before
> we have nailed down enough of the approach to be able write down how it
> will affect applications, unless we do the work to present the apps 
> folks
> with a menu having different choices.

I think the other approach is for me and Brian (and perhaps David) to 
actually ask the Apps ADs for help. I think that we are fairly deep 
into the discussion on what properties what get's passed to the ULPs 
can have. In order to understand this better I think we need some input 
from Apps. But let's discuss this off-line and see what we can do. I 
have got some comments off-line from some apps people I know. I tried 
to convince them to join the mailinglist, but with not much success so 
far :-(

kurtis -
Permalink | Reply | 0 comments |
headers
marcelo bagnulo braun | 1 Jul 11:46
Picon

how secure mh should be? Re: identifiers and security

Hi Kurtis,

imho is important to reach a common criteria here.

i think that the minimum goal should be that the resulting solution 
should be as secure as current fixed, single homed IPv6 internet.

As you say, i wouldn't mind if the result is a bit more secure, but i 
wouldn't require it

Regards, marcelo

El 01/07/2004, a las 9:57, Kurt Erik Lindqvist escribió:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> [Catching up a bit]
>
> On 2004-06-28, at 13.52, Erik Nordmark wrote:
>
>>
>> Thus something which is quite insecure (weaker than NOID as above) 
>> when
>> IPsec isn't used, but when IPsec is used it is as strong as with IPsec
>> in
>> today's Internet.
>> Is anybody interested in exploring these ideas further?
>
(Continue reading)

Permalink | Reply | 4 comments |

Gmane