Subject: Re: IPsec !?, was: Re: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006
From: Francis Dupont <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
Cc: "Christian Huitema" <[email-masked]>, "shim6-wg" <[email-masked]>, "Iljitsch van Beijnum" <[email-masked]>
Date: Mon, 31 Jul 2006 15:31:32 +0200

In your previous mail you wrote:

   so, saying that IPSec provides much more benefits than HBA/CGA but that 

=> IPsec (cf RFC 4301 introduction).

   cannot be used because they rely in an infrastructure that is 
   impossiible to deploy in a reasonable time frame is as good than to say 
   that IPSec is not a viable alternative, which imho should be the 
   conclusion from this exchange, would you agree with that?
   
=> I agree if you add the word "general" in front of "alternative".
To make the use of IPsec impossible as a limited alternative is more
arguable. To make shim6 and IPsec compatible is a third topics, the
question was opened by Jim and is not yet closed.
   
Regards

[email-masked]

Delivery-date: Mon, 31 Jul 2006 12:33:24 +0000
Cc: [email-masked], "Bound, Jim" <[email-masked]>, "Pekka Savola" <[email-masked]>, "Iljitsch van Beijnum" <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006 
Date: Mon, 31 Jul 2006 15:32:38 +0300
To: Francis Dupont <[email-masked]>

El 31/07/2006, a las 15:01, Francis Dupont escribi=F3:

>    would you agree with the following:
>
>    from the persepctive of the shim6 protocol, HBAs and CGAs provide=20=

> the
>    same protection. i.e. the shim6 protocol security is the same when=20=

> HBA
>    and CGA are used to protect it
>
> =3D> yes.

ok, this was my point

the rest of the discussion is moot imho (interesting maybe, but moot=20
for this stage of the wg)

regards, marcelo

Delivery-date: Mon, 31 Jul 2006 12:20:05 +0000
Cc: "Christian Huitema" <[email-masked]>, "shim6-wg" <[email-masked]>, "Iljitsch van Beijnum" <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: IPsec !?, was: Re: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006 
Date: Mon, 31 Jul 2006 15:19:29 +0300
To: Francis Dupont <[email-masked]>

El 31/07/2006, a las 15:07, Francis Dupont escribi=F3:

>  In your previous mail you wrote:
>
>>    there is no general any-to-any mechanism to prove address =
ownership
>>    using IPsec which is what is provided by CGA/HBA,
>>
>> =3D> I strongly disagree: we don't need such a mechanism because =
IPsec
>> is based on mutual authentication which is a stronger property than
>> what is provided by CGA/HBA.
>
>    but in order to do that you need or a shared secret or an PKI =
right?
>
> =3D> yes but this is not the subject of my answer: you argued IPsec
> doesn't provide the right service, I argued it provides it and
> perhaps (surely in fact) a lot of other services. The way IPsec can
> (cannot in fact) be used is another topics.
>

it seems we are in fact discussing different topics

imho the only relevant topic of this whole discussions are not the=20
theoretical capabilities of different protocols, but possible=20
alternative security mechanisms for the shim6 protocol (it is not that=20=

other discussion are not interesting, only that at this point in the wg=20=

what we need to understand is if we have viable  alternatives for=20
CGA/HBA in the shim6 protocol)

so, saying that IPSec provides much more benefits than HBA/CGA but that=20=

cannot be used because they rely in an infrastructure that is=20
impossiible to deploy in a reasonable time frame is as good than to say=20=

that IPSec is not a viable alternative, which imho should be the=20
conclusion from this exchange, would you agree with that?

regards, marcelo

> Regards
>
> [email-masked]
>

Envelope-to: [email-masked]
Delivery-date: Mon, 31 Jul 2006 12:14:57 +0000
Message-Id: <[email-masked]>
From: Francis Dupont <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
cc: Iljitsch van Beijnum <[email-masked]>, shim6-wg <[email-masked]>
Subject: Re: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006 
Date: Mon, 31 Jul 2006 14:13:59 +0200

 In your previous mail you wrote:

   so for multihoming purposes, which is the scope of this working group, 
   the security of the shim6 protocol provided by HBA and CGA are exactly 
   equivalent right?
   
=> HBA is the weaker mechanism providing the required security for
multi-homing. This doesn't change my argument saying than
HBA < CGA < IPsec or address sharing < ownership < authentication.

   > => I am afraid you believe any bit string is a valid public key, this 
   > is
   > not the case for RSA. It does not matter for real brute force attacks
   > (the modifier is long enough) but should matter for more sophisticate
   > attacks using some vulnerabilities in the hash function.
   
   but this is exactly why the modifier is included in the initial part of 
   the string, in order to prevent other type of attacks (i.e. the part 
   that is easy to change is at the begining, so the attacker cannot 
   benefit from precomputed parts of the hash)
   
=> you do an assumption about possible more sophisticate attacks
which can be false (and nobody knows as they are possible and likely
not yet known), i.e., this detail in the design is good but perhaps far
from to be enough.

Regards
   
[email-masked]

Envelope-to: [email-masked]
Delivery-date: Mon, 31 Jul 2006 12:08:04 +0000
Message-Id: <[email-masked]>
From: Francis Dupont <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
cc: "Christian Huitema" <[email-masked]>, "shim6-wg" <[email-masked]>, "Iljitsch van Beijnum" <[email-masked]>
Subject: Re: IPsec !?, was: Re: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006 
Date: Mon, 31 Jul 2006 14:07:32 +0200

 In your previous mail you wrote:

   >    there is no general any-to-any mechanism to prove address ownership
   >    using IPsec which is what is provided by CGA/HBA,
   >
   > => I strongly disagree: we don't need such a mechanism because IPsec
   > is based on mutual authentication which is a stronger property than
   > what is provided by CGA/HBA.
   
   but in order to do that you need or a shared secret or an PKI right?
   
=> yes but this is not the subject of my answer: you argued IPsec
doesn't provide the right service, I argued it provides it and
perhaps (surely in fact) a lot of other services. The way IPsec can
(cannot in fact) be used is another topics.

Regards
   
[email-masked]

Envelope-to: [email-masked]
Delivery-date: Mon, 31 Jul 2006 12:04:02 +0000
Message-Id: <[email-masked]>
From: Francis Dupont <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
cc: [email-masked], "Bound, Jim" <[email-masked]>, "Pekka Savola" <[email-masked]>, "Iljitsch van Beijnum" <[email-masked]>
Subject: Re: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006 
Date: Mon, 31 Jul 2006 14:01:59 +0200

 In your previous mail you wrote:

   but in this attack, the attacker is not changing the prefix set right?
   
=> yes, it keeps the parameters as they are.

   so basically the attacker is not attacking the shim6 signalling,

=> no, it is just an impersonization attack.

   is just located in every path,

=> at least one path.

   so the attacker can do exactly the same if 
   the shim6 protocol is secured using CGA (since the attacker is not 
   really changing the locator set), right?
   
=> not if the protection includes a signature check (not necessary for
shim6 signaling but as one has it there is no reason to skip it).

   so from the shim6 signalling perspective, the security achieved against 
   this attack is exactly the same wether you use CGA or HBA
   
=> only from the shim6 signaling perspective.

   Of course i agree that you could use CGA to protect data packets but 
   this wouldn't be shim6 signalling protection but data packets 
   protection, and this is out of the scope of the shim6 protocol
   
=> IMHO you don't put the things in the right order: when you have a
protection mechanism, you verify it provides enough, you apply it
and you drop all invalid packets. You don't try to just pick up the
sercurity service you need. So when shim6 is protected by a CGA and
not a HBA only (i.e., P flag is set) the hashes and the signature will
be checked, this provides strictly stronger security (or if you prefer
unnecessary defense for other than shim6 protocols).

   > => CGA has a RSA key pair too...
   
   yes, but the resulting security is the security of the weakest link, 
   so, even if you add a very long/strong key pair, the easier attack 
   would be the attack on the hash
   
=> the theorical complexity of the attack against RSA is very low...
Your assymption can become false one day. And BTW the functions of
the hash and the key pairs are not the same.

   > => no, either the attacker has to find a key pair giving the same hash
   > or to inverse the public key into the private one. Both problems are
   > harder than for HBAs.
   
   not really
   
=> the first one is in addition of the HBA one (find a collision),
the second is similar to the HBA theft with the addition of the
inversion of the public key.

   In the CGA case, the attacker needs to find an alternative CGA 
   parameter data structure with an alternative public key (the attacker's 
   public key).

=> perhaps also other values for some other fields.

   > => and ther is nothing private too. This is enough for multi-homing
   > where the property we're looking for is weaker than ownership.
   
   agree
   
   would you agree with the following:
   
   from the persepctive of the shim6 protocol, HBAs and CGAs provide the 
   same protection. i.e. the shim6 protocol security is the same when HBA 
   and CGA are used to protect it
   
=> yes.

   > => no, the properties have different strength: this is not directly
   > related to the complexity of theorical attacks.
   
   i guess is both things
   
=> you don't want to understand: a 58 bit authentication is stronger
even if it is easier to attack by brute force.

Regards
   
[email-masked]

Delivery-date: Mon, 31 Jul 2006 10:12:01 +0000
Cc: Jari Arkko <[email-masked]>, shim6-wg <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: Security Module for shim6 or hip really
Date: Mon, 31 Jul 2006 12:11:11 +0200
To: marcelo bagnulo braun <[email-masked]>

On 31-jul-2006, at 11:44, marcelo bagnulo braun wrote:

>> it's possible that an implementation supports a certain security  
>> mechanism for authenticating its own stuff but not for checking  
>> the authentication of the other side,

> i am not following this...

> a host don't need security to check its own locator set, we assume  
> that it has some local means to verify which its own locators  
> are... (but i guess this is not what you were thinking about...)

No, what I mean is: suppose only generating a HBA/CGA iid is covered  
by the claimed Ericsson patent, but checking the HBA/CGA isn't. Or  
the other way around. Then someone may want to implement only the  
part that isn't covered by the patent. Obviously in this case that's  
unlikely and not very useful because we need something that both ends  
can handle, but in the case of PKI-derived security this is a normal  
situation: if I don't have certificate for myself but I do have the  
root certificates I can check someone else's certificate but I can't  
protect my own locators with this security mechanism. So when we  
exchange capabilities, for the security stuff we need to have  
separate lists for what we support for outgoing locator sets and what  
we support for incoming locator sets.

>>> (the reception of packet is done solely based on the context tag,  
>>> so it doesn't matter which source locator is used).

>> I don't like this assumption...

> why not?

Because then you can't get rid of the context tag.

>> Does it make sense to have different authentication mechanisms for  
>> different locators?

> well, i think so

> suppose you have a CGA/HBA address

> you can use the HBA mechanisms to move among a stable set of  
> locators and you can use the CGA method to add new locators that  
> were not present initially to the locator set

Ok.

But is it worth the trouble to support this? We could say that if you  
want to add any locators outside your HBA set you must use CGA for  
the whole set. This way all locators share the same security  
mechanism which should make life a bit simpler.  :-)

On the other hand the trouble with CGA is that you need to send a  
challenge to make sure the other side really holds the secret key so  
validating the HBA locators using HBA has the advantage that you can  
use those while waiting for the response to your challenge to  
validate the CGA-only locators.

Iljitsch

Delivery-date: Mon, 31 Jul 2006 09:49:20 +0000
Cc: [email-masked]
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: Security Module for shim6 or hip really
Date: Mon, 31 Jul 2006 12:48:54 +0300
To: Jari Arkko <[email-masked]>

El 31/07/2006, a las 12:15, Jari Arkko escribi=F3:

> marcelo bagnulo braun wrote:
>
>> well, what we have in the current protocol is that the Locator List
>> Option Format has a one octet of Verification Method per locator
>> included in the option, so that we can specify the mechanism used to
>> validate each of the locators (currently only HBA and CGA methods are
>> defined in the draft)
>
> Ah, I missed that. This may be enough.
>
>> however, it is not obvious at this point what a host can do if the
>> validation method for the locators is not supported.
>
> Behave as if you did not support multihoming for this set of locators?
>
> But it is necessary to let the other end know about this.
>

yes, especally becuase the other could convey the locator set using an=20=

alternative mechanism

For instance suppose a host that supports both HBA and CGA and the=20
other end only supports CGA

The HBA/CGA host can initially send the locator set validated with HBA=20=

(because is cheaper). If the CGA only host only ignores this locators,=20=

then we may have no alternative locators to fall back the=20
communication. However, if the CGA only host informs the CGA/HBA host=20
that he doesn't support HBA the CGA/HBA host could send the locator set=20=

again using CGA validation and the result is that the alternative=20
locator set will be non empty

OTOH, i wouldn't want to have a full security mechanisms capabilities=20
exchange in the shim6 protocol, since the complexity would raise=20
considerably (and after all, shim6 is not a security protocol , i think=20=

:-)

Regards, marcelo

> --Jari
>
>

Delivery-date: Mon, 31 Jul 2006 09:45:05 +0000
Cc: Jari Arkko <[email-masked]>, shim6-wg <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: Security Module for shim6 or hip really
Date: Mon, 31 Jul 2006 12:44:32 +0300
To: Iljitsch van Beijnum <[email-masked]>

El 31/07/2006, a las 12:14, Iljitsch van Beijnum escribi=F3:

> On 31-jul-2006, at 9:31, marcelo bagnulo braun wrote:
>
>>> First, it is customary to require a mandatory to implement
>>> security mechanism for IETF specs. Without this, there will be very
>>> little interoperability. But it doesn't rule out pluggable security
>>> mechanisms, just that one of them has to be mandatory.
>
> Well, if people feel the patent issues with CGA/HBA are such that they=20=

> can't implement those, should we prohibit them from implementing shim6=20=

> altoghether? That doesn't make too much sense...
>
>> moreover, i think it would be interesting to understand how the=20
>> protocol would behave, if for instance, one end supports only HBA and=20=

>> the other end only supports CGA (or other two different security=20
>> mechanisms)
>
> And: it's possible that an implementation supports a certain security=20=

> mechanism for authenticating its own stuff but not for checking the=20
> authentication of the other side,

i am not following this...

a host don't need security to check its own locator set, we assume that=20=

it has some local means to verify which its own locators are... (but i=20=

guess this is not what you were thinking about...)

so afaict, a host only need security means to verify the peers locator=20=

set

>  or the other way around. So we need to exchange capabilities for both=20=

> send and receive.
>
>> (the reception of packet is done solely based on the context tag, so=20=

>> it doesn't matter which source locator is used).
>
> I don't like this assumption...
>

why not? this results in similar security that the current=20
non-multihomed-IP and it simplifies considerably the processing of=20
incoming packets...

>> perhaps one option would be to include something like the Locator=20
>> List Option in the ack message where the receiver of the update=20
>> message can  ack each locator separately  and also specify the reason=20=

>> why it doesn't ack a given locator (including a code for validation=20=

>> method not supported)
>
> Does it make sense to have different authentication mechanisms for=20
> different locators?
>

well, i think so

suppose you have a CGA/HBA address

you can use the HBA mechanisms to move among a stable set of locators=20
and you can use the CGA method to add new locators that were not=20
present initially to the locator set

Regards, marcelo

> Iljitsch
>

Delivery-date: Mon, 31 Jul 2006 09:16:46 +0000
Cc: shim6-wg <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006 
Date: Mon, 31 Jul 2006 11:16:14 +0200
To: Francis Dupont <[email-masked]>

On 31-jul-2006, at 8:09, Francis Dupont wrote:

>    traffic, you need to find an alternative prefix+index set that
>                                 ^^^^^^^^^^^

> => this issue is this word "alternative": an attack is to use the
> same set, i.e., HBAs just extend the steal of address to the steal
> of address set. It does not matter for multi-homing but only for
> multi-homing. This is why I say HBA+CGA is a strictly stronger
> mechanism than HBA.

I'm sorry, but this text just doesn't parse for me...

Delivery-date: Mon, 31 Jul 2006 09:16:41 +0000
Cc: Jari Arkko <[email-masked]>, shim6-wg <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: Security Module for shim6 or hip really
Date: Mon, 31 Jul 2006 11:14:32 +0200
To: marcelo bagnulo braun <[email-masked]>

On 31-jul-2006, at 9:31, marcelo bagnulo braun wrote:

>> First, it is customary to require a mandatory to implement
>> security mechanism for IETF specs. Without this, there will be very
>> little interoperability. But it doesn't rule out pluggable security
>> mechanisms, just that one of them has to be mandatory.

Well, if people feel the patent issues with CGA/HBA are such that  
they can't implement those, should we prohibit them from implementing  
shim6 altoghether? That doesn't make too much sense...

> moreover, i think it would be interesting to understand how the  
> protocol would behave, if for instance, one end supports only HBA  
> and the other end only supports CGA (or other two different  
> security mechanisms)

And: it's possible that an implementation supports a certain security  
mechanism for authenticating its own stuff but not for checking the  
authentication of the other side, or the other way around. So we need  
to exchange capabilities for both send and receive.

> (the reception of packet is done solely based on the context tag,  
> so it doesn't matter which source locator is used).

I don't like this assumption...

> perhaps one option would be to include something like the Locator  
> List Option in the ack message where the receiver of the update  
> message can  ack each locator separately  and also specify the  
> reason why it doesn't ack a given locator (including a code for  
> validation method not supported)

Does it make sense to have different authentication mechanisms for  
different locators?

Iljitsch

Delivery-date: Mon, 31 Jul 2006 09:16:10 +0000
Date: Mon, 31 Jul 2006 12:15:02 +0300
From: Jari Arkko <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
CC:  [email-masked]
Subject: Re: Security Module for shim6 or hip really

marcelo bagnulo braun wrote:

> well, what we have in the current protocol is that the Locator List
> Option Format has a one octet of Verification Method per locator
> included in the option, so that we can specify the mechanism used to
> validate each of the locators (currently only HBA and CGA methods are
> defined in the draft)

Ah, I missed that. This may be enough.

> however, it is not obvious at this point what a host can do if the
> validation method for the locators is not supported. 

Behave as if you did not support multihoming for this set of locators?

But it is necessary to let the other end know about this.

--Jari

Delivery-date: Mon, 31 Jul 2006 07:32:41 +0000
Cc: [email-masked], "Bound, Jim" <[email-masked]>, Iljitsch van Beijnum <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: Security Module for shim6 or hip really
Date: Mon, 31 Jul 2006 10:31:49 +0300
To: Jari Arkko <[email-masked]>

Hi Jari,

El 30/07/2006, a las 23:58, Jari Arkko escribi=F3:

> Iljitsch van Beijnum wrote:
>
>> On 19-jul-2006, at 16:19, Bound, Jim wrote:
>>
>>> A suggestion proposed at the Montreal IETF SHIM6 WG meeting was to
>>> treat
>>> the security of ULIDs as module (abstractly speaking) for SHIM6 =
where
>>> the user or implementer can plug in different solutions.
>>
>>
>> Right.
>>
>> This is attractive in some ways, but it does require us to come up
>> with an interface for exchanging this information between the shim
>> layer and the different providers of security. How would that work?
>
> Three notes:
>
> First, it is customary to require a mandatory to implement
> security mechanism for IETF specs. Without this, there will be very
> little interoperability. But it doesn't rule out pluggable security
> mechanisms, just that one of them has to be mandatory.
>
> Second, I believe the specs already support the idea of multiple
> mechanisms; the -hba draft allows either HBA, CGA, or HBA/CGA
> addresses. However, I can not see a mandatory to implement
> (or any other comformance statement) in the draft. Perhaps this
> should be added.
>

i think you are right

moreover, i think it would be interesting to understand how the=20
protocol would behave, if for instance, one end supports only HBA and=20
the other end only supports CGA (or other two different security=20
mechanisms) do we need to include some form of security mechanisms=20
declaration at the establishment?

i guess we could simply not ack those locators validated with non=20
supported security mechanisms, but the current draft only acccept to=20
ack or not ack the update message as a whole (not per locator)

> Third, I think adding new mechanisms is harder than merely
> designing an interface. An extension spec for an alternate
> security mechanism, describing impact to Shim6 control
> signaling, payload protection, security considerations, etc.
> I am sure we can do it, but I am not sure if we need to
> develop anything new today to support such extensions.
> Even if we did, it is not clear to me that, say, TLS and IPsec
> based mechanisms would be able to use the same interface.
> But one question: do we have a capability negotiation of
> the used security mechanism in the current protocol?
> Adding this may be prudent.
>

well, what we have in the current protocol is that the Locator List=20
Option Format has a one octet of Verification Method per locator=20
included in the option, so that we can specify the mechanism used to=20
validate each of the locators (currently only HBA and CGA methods are=20
defined in the draft)

however, it is not obvious at this point what a host can do if the=20
validation method for the locators is not supported. One option is to=20
not ack the whole update. The other option is to not use those locators=20=

for sending packets (the reception of packet is done solely based on=20
the context tag, so it doesn't matter which source locator is used).=20
But this leaves no chance for the other end to use a different=20
validation mechanism to validate those locators.

perhaps one option would be to include something like the Locator List=20=

Option in the ack message where the receiver of the update message can =20=

ack each locator separately  and also specify the reason why it doesn't=20=

ack a given locator (including a code for validation method not=20
supported)

Regards, marcelo

> --Jari
>
>

Delivery-date: Mon, 31 Jul 2006 07:07:13 +0000
Cc: Iljitsch van Beijnum <[email-masked]>, shim6-wg <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006 
Date: Mon, 31 Jul 2006 10:06:47 +0300
To: Francis Dupont <[email-masked]>

El 31/07/2006, a las 9:09, Francis Dupont escribi=F3:

>  In your previous mail you wrote:
>
>    The fact that there are no secrets is exactly the beauty of HBA. =
You
>    can easily determine what the real user's prefixes are, and also =
the
>    extra index or whatever it's called, and then you can compute the
>    hash. But that doesn't buy you anything: in order to redirect
>    traffic, you need to find an alternative prefix+index set that
>                                 ^^^^^^^^^^^
>
> =3D> this issue is this word "alternative": an attack is to use the
> same set, i.e., HBAs just extend the steal of address to the steal
> of address set. It does not matter for multi-homing but only for
> multi-homing.

so for multihoming purposes, which is the scope of this working group,=20=

the security of the shim6 protocol provided by HBA and CGA are exactly=20=

equivalent right?

>  This is why I say HBA+CGA is a strictly stronger
> mechanism than HBA.
>
>    resolves to the same hash. This requires 2^58 tries on average
>    without using sec.
>
> =3D> as 2^(20*sec+58) is greater the hash extension is or will be
> a necessary addition.

yes, buy again this is exactly the same for HBA and for CGAs

>
>    CGA is exactly the same, except that here, you don't put in a =
prefix
>    set of your own, but a public key for which you have the private=20
> key.
>
> =3D> no, CGA has the RSA part too.
>
>> =3D> no, either the attacker has to find a key pair giving the same =
hash
>> or to inverse the public key into the private one. Both problems are
>> harder than for HBAs.
>
>    CGA and HBA use the same hash, you can break CGA by breaking the=20
> hash
>    and substituting your own keys, rather than break the public key=20
> crypto.
>
> =3D> I am afraid you believe any bit string is a valid public key, =
this=20
> is
> not the case for RSA. It does not matter for real brute force attacks
> (the modifier is long enough) but should matter for more sophisticate
> attacks using some vulnerabilities in the hash function.

but this is exactly why the modifier is included in the initial part of=20=

the string, in order to prevent other type of attacks (i.e. the part=20
that is easy to change is at the begining, so the attacker cannot=20
benefit from precomputed parts of the hash)

Regards, marcelo

>
> Regards
>
> [email-masked]
>

Delivery-date: Mon, 31 Jul 2006 07:00:37 +0000
Cc: "Christian Huitema" <[email-masked]>, "shim6-wg" <[email-masked]>, "Iljitsch van Beijnum" <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: IPsec !?, was: Re: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006 
Date: Mon, 31 Jul 2006 09:59:53 +0300
To: Francis Dupont <[email-masked]>

El 31/07/2006, a las 1:13, Francis Dupont escribi=F3:

>  In your previous mail you wrote:
>
>    there is no general any-to-any mechanism to prove address ownership
>    using IPsec which is what is provided by CGA/HBA,
>
> =3D> I strongly disagree: we don't need such a mechanism because IPsec
> is based on mutual authentication which is a stronger property than
> what is provided by CGA/HBA.
>

but in order to do that you need or a shared secret or an PKI right?

or do you know a any to any mechanisms for providing mutual=20
authentication that does not requires either a pre-existent trust=20
relationship? (i.e. preshared secret or PKI)

>    this is why IPSec is not a possible substitute to HBA/CGA in shim
>
> =3D> I have exactly the opposite conclusion: we need a proof the=20
> alternate
> address belongs to the same node, with a proper use of IPsec we have
> a proof the traffic (including signaling) comes from the node we=20
> believe
> it comes from, and than nobody can have modified it. And we can even=20=

> have
> more like confidentiality...

but in order to provide this you need preshared secret or PKI in all=20
the hosts, right?

Regards, marcelo

>
> Regards
>
> [email-masked]
>

Delivery-date: Mon, 31 Jul 2006 06:26:41 +0000
Cc: [email-masked], "Bound, Jim" <[email-masked]>, "Pekka Savola" <[email-masked]>, "Iljitsch van Beijnum" <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006 
Date: Mon, 31 Jul 2006 09:26:05 +0300
To: Francis Dupont <[email-masked]>

El 31/07/2006, a las 1:04, Francis Dupont escribi=F3:

>  In your previous mail you wrote:
>
>> =3D> HBAs are weaker than CGAs
>
>    DO you know any attack that is easier in HBAs than in CGAs? could=20=

> you
>    describe it?
>
> =3D> easy, you simply steal the whole set. There is nothing to find
> because the victim can give you everything. This can't happen with
> CGA because you should not know the private key.
>

but in this attack, the attacker is not changing the prefix set right?

so basically the attacker is not attacking the shim6 signalling, is=20
just located in every path, so the attacker can do exactly the same if=20=

the shim6 protocol is secured using CGA (since the attacker is not=20
really changing the locator set), right?

so from the shim6 signalling perspective, the security achieved against=20=

this attack is exactly the same wether you use CGA or HBA

Of course i agree that you could use CGA to protect data packets but=20
this wouldn't be shim6 signalling protection but data packets=20
protection, and this is out of the scope of the shim6 protocol

>    imho HBA and CGA are exactly equally strong, since the weakest=20
> point in
>    both schemes is determined by the number of hash bits contained in=20=

> the
>    iid of the IPv6 address.
>
> =3D> CGA has a RSA key pair too...

yes, but the resulting security is the security of the weakest link,=20
so, even if you add a very long/strong key pair, the easier attack=20
would be the attack on the hash

of course having very short key pair could indeed result in having cga=20=

security weaker than the hash, making CGAs weaker than CGAs... but the=20=

point is that this doesn't help to achieve better security that HBAs

>
>    In both schemes, an attacker must perform o(2^59) attempts in order=20=

> to
>    find an alternative CGA parameter data strucutre (with an=20
> alternative
>    PRefix set in the case of HBAs and with an alternative public key =
in
>    the case of CGA)
>
> =3D> no, either the attacker has to find a key pair giving the same =
hash
> or to inverse the public key into the private one. Both problems are
> harder than for HBAs.

not really

we do agree that the attacker will do the easier attack, right?

so, let's assume that the key pair was selected in order to be stronger=20=

than the hash (if not the CGA security would be weaker)

so we can focus on the attack against the hash

In the CGA case, the attacker needs to find an alternative CGA=20
parameter data structure with an alternative public key (the attacker's=20=

public key) In order to do that, the attacker will try with different=20
modifier (it is easier than to try with different public keys), so the=20=

attacker needs to perform O(2^59) attempts to find the alternative CGA=20=

parameter data structure

In the HBA case, the attacker needs to find an alternative CGA=20
parameter data structure that includes an alternative prefix set. In=20
order to do that, the attacker will try with different modifiers,  so=20
the attacker needs to perform O(2^59) attempts to find the alternative=20=

CGA parameter data structure

the difficulty of the attack, hence the resulting security is the same=20=

for HBA and for CGAs

>
>    moreover, imho CGAs are residually weaker than HBAs, since in CGAs=20=

> the
>    private key can be compromised while in HBAs there is no secret =
that
>    can be compromised
>
> =3D> and ther is nothing private too. This is enough for multi-homing
> where the property we're looking for is weaker than ownership.
>

agree

would you agree with the following:

from the persepctive of the shim6 protocol, HBAs and CGAs provide the=20
same protection. i.e. the shim6 protocol security is the same when HBA=20=

and CGA are used to protect it

>>  (which provide ownership using the signature),
>> and than standard strong authentication (using some kind of PKI).
>
>    agree that PKI is stronger, since the attacks may require more than
>    o(2^59) attempts
>
> =3D> no, the properties have different strength: this is not directly
> related to the complexity of theorical attacks.
>

i guess is both things

you can achieve better protection because you can provide other=20
security features (that are outside of the scope of the shim6 protocol=20=

protection) but if you use if for the shim6 protocol security, you=20
could potetially achieve better protection because you don't have the=20
limitation of the 59 bit long hash

>> Without the hash extension IMHO they would be too weak, now we have
>> to take advice from cryptographers to understand if/how to improve
>> them...
>
>    i am not sure what do you mean by hash extensions...
>
> =3D> reread the RFC (:-).
>
>    but anyway, we can change the hash function in HBA/CGA and we have=20=

> the
>    Sec parameter... this should be  enough for a few decades i =
heard...
>
> =3D> a better hash function should give nothing more: if you have an=20=

> ideal
> hash function giving 1000 bits and you take only 64 bits, the brute=20
> force
> attack is still in 2^32 attempts for a collision between two values
> and 2^64 for a collision with a given value. So as soon as the hash
> function is not too bad it is enough.
>

so, this is enough protection for the shim6 protocol i guess

regards, marcelo

> Regards
>
> [email-masked]
>

Envelope-to: [email-masked]
Delivery-date: Mon, 31 Jul 2006 06:11:17 +0000
Message-Id: <[email-masked]>
From: Francis Dupont <[email-masked]>
To: Iljitsch van Beijnum <[email-masked]>
cc: shim6-wg <[email-masked]>
Subject: Re: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006 
Date: Mon, 31 Jul 2006 08:09:10 +0200

 In your previous mail you wrote:

   The fact that there are no secrets is exactly the beauty of HBA. You  
   can easily determine what the real user's prefixes are, and also the  
   extra index or whatever it's called, and then you can compute the  
   hash. But that doesn't buy you anything: in order to redirect  
   traffic, you need to find an alternative prefix+index set that  
                                ^^^^^^^^^^^

=> this issue is this word "alternative": an attack is to use the
same set, i.e., HBAs just extend the steal of address to the steal
of address set. It does not matter for multi-homing but only for
multi-homing. This is why I say HBA+CGA is a strictly stronger
mechanism than HBA.

   resolves to the same hash. This requires 2^58 tries on average  
   without using sec.
   
=> as 2^(20*sec+58) is greater the hash extension is or will be
a necessary addition.

   CGA is exactly the same, except that here, you don't put in a prefix  
   set of your own, but a public key for which you have the private key.
   
=> no, CGA has the RSA part too.

   > => no, either the attacker has to find a key pair giving the same hash
   > or to inverse the public key into the private one. Both problems are
   > harder than for HBAs.
   
   CGA and HBA use the same hash, you can break CGA by breaking the hash  
   and substituting your own keys, rather than break the public key crypto.

=> I am afraid you believe any bit string is a valid public key, this is
not the case for RSA. It does not matter for real brute force attacks
(the modifier is long enough) but should matter for more sophisticate
attacks using some vulnerabilities in the hash function.

Regards

[email-masked]

Delivery-date: Sun, 30 Jul 2006 22:39:54 +0000
Cc: shim6-wg <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006 
Date: Mon, 31 Jul 2006 00:39:09 +0200
To: Francis Dupont <[email-masked]>

On 31-jul-2006, at 0:04, Francis Dupont wrote:

>>> => HBAs are weaker than CGAs

>>    DO you know any attack that is easier in HBAs than in CGAs?  
>> could you
>>    describe it?

> => easy, you simply steal the whole set. There is nothing to find
> because the victim can give you everything. This can't happen with
> CGA because you should not know the private key.

The fact that there are no secrets is exactly the beauty of HBA. You  
can easily determine what the real user's prefixes are, and also the  
extra index or whatever it's called, and then you can compute the  
hash. But that doesn't buy you anything: in order to redirect  
traffic, you need to find an alternative prefix+index set that  
resolves to the same hash. This requires 2^58 tries on average  
without using sec.

CGA is exactly the same, except that here, you don't put in a prefix  
set of your own, but a public key for which you have the private key.

>    In both schemes, an attacker must perform o(2^59) attempts in  
> order to
>    find an alternative CGA parameter data strucutre (with an  
> alternative
>    PRefix set in the case of HBAs and with an alternative public  
> key in
>    the case of CGA)

> => no, either the attacker has to find a key pair giving the same hash
> or to inverse the public key into the private one. Both problems are
> harder than for HBAs.

CGA and HBA use the same hash, you can break CGA by breaking the hash  
and substituting your own keys, rather than break the public key crypto.

Envelope-to: [email-masked]
Delivery-date: Sun, 30 Jul 2006 22:14:47 +0000
Message-Id: <[email-masked]>
From: Francis Dupont <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
cc: "Christian Huitema" <[email-masked]>, "shim6-wg" <[email-masked]>, "Iljitsch van Beijnum" <[email-masked]>
Subject: Re: IPsec !?, was: Re: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006 
Date: Mon, 31 Jul 2006 00:13:56 +0200

 In your previous mail you wrote:
   
   there is no general any-to-any mechanism to prove address ownership
   using IPsec which is what is provided by CGA/HBA,

=> I strongly disagree: we don't need such a mechanism because IPsec
is based on mutual authentication which is a stronger property than
what is provided by CGA/HBA.

   this is why IPSec is not a possible substitute to HBA/CGA in shim

=> I have exactly the opposite conclusion: we need a proof the alternate
address belongs to the same node, with a proper use of IPsec we have
a proof the traffic (including signaling) comes from the node we believe
it comes from, and than nobody can have modified it. And we can even have
more like confidentiality...
   
Regards
   
[email-masked]

Envelope-to: [email-masked]
Delivery-date: Sun, 30 Jul 2006 22:06:01 +0000
Message-Id: <[email-masked]>
From: Francis Dupont <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
cc: [email-masked], "Bound, Jim" <[email-masked]>, "Pekka Savola" <[email-masked]>, "Iljitsch van Beijnum" <[email-masked]>
Subject: Re: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006 
Date: Mon, 31 Jul 2006 00:04:44 +0200

 In your previous mail you wrote:

   > => HBAs are weaker than CGAs
   
   DO you know any attack that is easier in HBAs than in CGAs? could you 
   describe it?
   
=> easy, you simply steal the whole set. There is nothing to find
because the victim can give you everything. This can't happen with
CGA because you should not know the private key.

   imho HBA and CGA are exactly equally strong, since the weakest point in 
   both schemes is determined by the number of hash bits contained in the 
   iid of the IPv6 address.

=> CGA has a RSA key pair too...

   In both schemes, an attacker must perform o(2^59) attempts in order to 
   find an alternative CGA parameter data strucutre (with an alternative 
   PRefix set in the case of HBAs and with an alternative public key in 
   the case of CGA)
   
=> no, either the attacker has to find a key pair giving the same hash
or to inverse the public key into the private one. Both problems are
harder than for HBAs.

   moreover, imho CGAs are residually weaker than HBAs, since in CGAs the 
   private key can be compromised while in HBAs there is no secret that 
   can be compromised
   
=> and ther is nothing private too. This is enough for multi-homing
where the property we're looking for is weaker than ownership.

   >  (which provide ownership using the signature),
   > and than standard strong authentication (using some kind of PKI).
   
   agree that PKI is stronger, since the attacks may require more than 
   o(2^59) attempts
   
=> no, the properties have different strength: this is not directly
related to the complexity of theorical attacks.

   > Without the hash extension IMHO they would be too weak, now we have
   > to take advice from cryptographers to understand if/how to improve 
   > them...
   
   i am not sure what do you mean by hash extensions...
   
=> reread the RFC (:-).

   but anyway, we can change the hash function in HBA/CGA and we have the 
   Sec parameter... this should be  enough for a few decades i heard...
   
=> a better hash function should give nothing more: if you have an ideal
hash function giving 1000 bits and you take only 64 bits, the brute force
attack is still in 2^32 attempts for a collision between two values
and 2^64 for a collision with a given value. So as soon as the hash
function is not too bad it is enough.
   
Regards   
   
[email-masked]

Delivery-date: Sun, 30 Jul 2006 20:59:27 +0000
Date: Sun, 30 Jul 2006 23:58:24 +0300
From: Jari Arkko <[email-masked]>
To: Iljitsch van Beijnum <[email-masked]>,  "Bound, Jim" <[email-masked]>
CC:  [email-masked]
Subject: Re: Security Module for shim6 or hip really

Iljitsch van Beijnum wrote:

> On 19-jul-2006, at 16:19, Bound, Jim wrote:
>
>> A suggestion proposed at the Montreal IETF SHIM6 WG meeting was to 
>> treat
>> the security of ULIDs as module (abstractly speaking) for SHIM6 where
>> the user or implementer can plug in different solutions.
>
>
> Right.
>
> This is attractive in some ways, but it does require us to come up 
> with an interface for exchanging this information between the shim 
> layer and the different providers of security. How would that work?

Three notes:

First, it is customary to require a mandatory to implement
security mechanism for IETF specs. Without this, there will be very
little interoperability. But it doesn't rule out pluggable security
mechanisms, just that one of them has to be mandatory.

Second, I believe the specs already support the idea of multiple
mechanisms; the -hba draft allows either HBA, CGA, or HBA/CGA
addresses. However, I can not see a mandatory to implement
(or any other comformance statement) in the draft. Perhaps this
should be added.

Third, I think adding new mechanisms is harder than merely
designing an interface. An extension spec for an alternate
security mechanism, describing impact to Shim6 control
signaling, payload protection, security considerations, etc.
I am sure we can do it, but I am not sure if we need to
develop anything new today to support such extensions.
Even if we did, it is not clear to me that, say, TLS and IPsec
based mechanisms would be able to use the same interface.
But one question: do we have a capability negotiation of
the used security mechanism in the current protocol?
Adding this may be prudent.

--Jari

Delivery-date: Sun, 30 Jul 2006 19:54:21 +0000
Date: Sun, 30 Jul 2006 22:53:36 +0300
From: Jari Arkko <[email-masked]>
To: Iljitsch van Beijnum <[email-masked]>
CC: Francis Dupont <[email-masked]>, shim6-wg <[email-masked]>
Subject: Re: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006

Iljitsch van Beijnum wrote:

> On 24-jul-2006, at 10:02, Francis Dupont wrote:
>
>>    Too weak for what?
>
>
>> => direct attack against the hash (the O(2^56)).
>
>
> Hm, even if you build a machine that can test 1000 hashes in parallel 
> every microsecond, it will take you more than a year on average to 
> find a hash collision. And when you've found one, you get to redirect 
> traffic, which is only a denial of service attack. If you have enough 
> money to build such a hash breaking machine and enough patience to 
> wait for it to work, I'm sure other, more dangerous avenues of attack 
> are also open to you...

Yes.

> An interesting issue is that after some 10 million hosts start using 
> HBA, there is a 50% chance of two hosts using the same hash, i.e., 
> sort of a distributed birthday attack.

Yes (but only if the hosts are all on the same link. Otherwise the
prefixes will
be different).

Inclusion of prefixes in the hash computation was added in order to
prevent a precomputation attack. In this attack someone calculates
all possible hash values and stores the corresponding keys in a table.
A few years ago when we did the calculations, the required storage
space with highest possible density storage was in the order of several
World Trade Centers worth of office space. Storage technology has
improved since then, but with the prefix as a part of the input to the
hash, you'd have to compute the table for every prefix.

--Jari

Delivery-date: Sun, 30 Jul 2006 19:01:41 +0000
Cc: "Christian Huitema" <[email-masked]>, "shim6-wg" <[email-masked]>, "Iljitsch van Beijnum" <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: IPsec !?, was: Re: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006 
Date: Sun, 30 Jul 2006 21:09:54 +0300
To: Francis Dupont <[email-masked]>

El 28/07/2006, a las 9:45, Francis Dupont escribi=F3:

>  In your previous mail you wrote:
>
>>> Of course, we would have a very simple way out of this debate by
>>> mandating IPSEC, or more precisely only solving the "session
>>> continuity"
>>> problem if IPSEC is used.
>>
>> IPsec keeps coming up but so far, nobody has been able to explain how
>> to make IPsec work between random hosts connected to the internet =
that
>> don't have any shared state yet.
>
>    And how exactly is that harder than convincing random hosts that=20
> have no
>    shared state to trust HBA or CGA information?
>
> =3D> HBA or CGA are self contained, IKE requires strong authentication
> which can work only with an infrastructure or shared state.
>
>    In theory, one can use the same validation for IKE that one is
>    ready to use for SHIM6,
>
> =3D> no, this is the opposite: authentication is stronger than =
ownership,
> which is stronger than address sharing, so IKE > CGA > HBA, and one
> idea is to use IPsec/IKE to provide SHIM6 security when for other=20
> reasons
> IPsec/IKE is already available (exactly the same limited applicability
> than the IPsec to protect MIPv6 MN-CN routing optimization).
>
>    and reuse IKEv2,
>
> =3D> I agree for a "reuse" when we have already the "use".
>

i think i fully agree here, but just to state things clear, there is no=20=

general any-to-any mechanism to prove address ownership using IPSec=20
which is what is provided by CGA/HBA, this is why IPSec is not a=20
possible substitute to HBA/CGA in shim

regards, marcelo

>    MOBIKE
>
> =3D> MOBIKE has in fact not directly usable for multihoming (which was=20=

> not
> in its real (i.e., not the IETF) charter).
>
>    and the like.
>
> Regards
>
> [email-masked]
>

Delivery-date: Sun, 30 Jul 2006 18:58:42 +0000
Cc: [email-masked], "Bound, Jim" <[email-masked]>, "Pekka Savola" <[email-masked]>, "Iljitsch van Beijnum" <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006 
Date: Sun, 30 Jul 2006 17:10:33 +0300
To: Francis Dupont <[email-masked]>

Hi Francis,

sorry for the late reply...

El 23/07/2006, a las 18:20, Francis Dupont escribi=F3:

>  In your previous mail you wrote:
>
>> Here we are in trouble because the main threat is hard: the best =
known
>> defense, mutual strong authentication, is not deployable. So we get
>> poor mechanisms (like RR) and we try to improve them (like CBA)=20
>> against
>> secondary threats when the main one still remains... I really like
>> to see shim far better than mip!
>>
>
>    but do you think that the security resulting with HBAs and the
>    additional mechanisms available in shim are good enough?
>
> =3D> HBAs are weaker than CGAs

i don't agree with this

DO you know any attack that is easier in HBAs than in CGAs? could you=20
describe it?

imho HBA and CGA are exactly equally strong, since the weakest point in=20=

both schemes is determined by the number of hash bits contained in the=20=

iid of the IPv6 address.
In both schemes, an attacker must perform o(2^59) attempts in order to=20=

find an alternative CGA parameter data strucutre (with an alternative=20
PRefix set in the case of HBAs and with an alternative public key in=20
the case of CGA)

moreover, imho CGAs are residually weaker than HBAs, since in CGAs the=20=

private key can be compromised while in HBAs there is no secret that=20
can be compromised

>  (which provide ownership using the signature),
> and than standard strong authentication (using some kind of PKI).

agree that PKI is stronger, since the attacks may require more than=20
o(2^59) attempts

> Without the hash extension IMHO they would be too weak, now we have
> to take advice from cryptographers to understand if/how to improve=20
> them...

i am not sure what do you mean by hash extensions...

but anyway, we can change the hash function in HBA/CGA and we have the=20=

Sec parameter... this should be  enough for a few decades i heard...

regards, marcelo

>
> Regards
>
> [email-masked]
>
> PS: BTW my employer when I implemented HBAs was "GET/ENST Bretagne".
>

Envelope-to: [email-masked]
Delivery-date: Fri, 28 Jul 2006 06:46:02 +0000
Message-Id: <[email-masked]>
From: Francis Dupont <[email-masked]>
To: "Christian Huitema" <[email-masked]>
cc: "Iljitsch van Beijnum" <[email-masked]>, "shim6-wg" <[email-masked]>
Subject: Re: IPsec !?, was: Re: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006 
Date: Fri, 28 Jul 2006 08:45:09 +0200

 In your previous mail you wrote:

   > > Of course, we would have a very simple way out of this debate by
   > > mandating IPSEC, or more precisely only solving the "session
   > > continuity"
   > > problem if IPSEC is used.
   > 
   > IPsec keeps coming up but so far, nobody has been able to explain how
   > to make IPsec work between random hosts connected to the internet that
   > don't have any shared state yet.
   
   And how exactly is that harder than convincing random hosts that have no
   shared state to trust HBA or CGA information?

=> HBA or CGA are self contained, IKE requires strong authentication
which can work only with an infrastructure or shared state.

   In theory, one can use the same validation for IKE that one is
   ready to use for SHIM6,

=> no, this is the opposite: authentication is stronger than ownership,
which is stronger than address sharing, so IKE > CGA > HBA, and one
idea is to use IPsec/IKE to provide SHIM6 security when for other reasons
IPsec/IKE is already available (exactly the same limited applicability
than the IPsec to protect MIPv6 MN-CN routing optimization).

   and reuse IKEv2,

=> I agree for a "reuse" when we have already the "use".

   MOBIKE

=> MOBIKE has in fact not directly usable for multihoming (which was not
in its real (i.e., not the IETF) charter).

   and the like.
   
Regards

[email-masked]

Delivery-date: Fri, 28 Jul 2006 04:20:08 +0000
Content-class: urn:content-classes:message
Subject: RE: IPsec !?, was: Re: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006 
Date: Thu, 27 Jul 2006 21:18:53 -0700
From: "Christian Huitema" <[email-masked]>
To: "Iljitsch van Beijnum" <[email-masked]>
Cc: "Francis Dupont" <[email-masked]>, "shim6-wg" <[email-masked]>

> > Of course, we would have a very simple way out of this debate by
> > mandating IPSEC, or more precisely only solving the "session
> > continuity"
> > problem if IPSEC is used.
>=20
> IPsec keeps coming up but so far, nobody has been able to explain how
> to make IPsec work between random hosts connected to the internet that
> don't have any shared state yet.

And how exactly is that harder than convincing random hosts that have no
shared state to trust HBA or CGA information? In theory, one can use the
same validation for IKE that one is ready to use for SHIM6, and reuse
IKEv2, MOBIKE and the like.

-- Christian Huitema

Delivery-date: Thu, 27 Jul 2006 18:36:27 +0000
Cc: "Francis Dupont" <[email-masked]>, "shim6-wg" <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: IPsec !?, was: Re: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006 
Date: Thu, 27 Jul 2006 20:35:50 +0200
To: Christian Huitema <[email-masked]>

On 27-jul-2006, at 19:04, Christian Huitema wrote:

> Of course, we would have a very simple way out of this debate by
> mandating IPSEC, or more precisely only solving the "session  
> continuity"
> problem if IPSEC is used.

IPsec keeps coming up but so far, nobody has been able to explain how  
to make IPsec work between random hosts connected to the internet  
that don't have any shared state yet.

Delivery-date: Thu, 27 Jul 2006 17:05:27 +0000
Content-class: urn:content-classes:message
Subject: RE: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006 
Date: Thu, 27 Jul 2006 10:04:19 -0700
From: "Christian Huitema" <[email-masked]>
To: "Iljitsch van Beijnum" <[email-masked]>, "Francis Dupont" <[email-masked]>
Cc: "shim6-wg" <[email-masked]>

Of course, we would have a very simple way out of this debate by
mandating IPSEC, or more precisely only solving the "session continuity"
problem if IPSEC is used.=20

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Iljitsch van Beijnum
> Sent: Monday, July 24, 2006 2:27 AM
> To: Francis Dupont
> Cc: shim6-wg
> Subject: Re: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006
>=20
> On 24-jul-2006, at 10:02, Francis Dupont wrote:
>=20
> >    Too weak for what?
>=20
> > =3D> direct attack against the hash (the O(2^56)).
>=20
> Hm, even if you build a machine that can test 1000 hashes in parallel
> every microsecond, it will take you more than a year on average to
find
> a hash collision. And when you've found one, you get to redirect
> traffic, which is only a denial of service attack. If you have enough
> money to build such a hash breaking machine and enough patience to
wait
> for it to work, I'm sure other, more dangerous avenues of attack are
> also open to you...
>=20
> An interesting issue is that after some 10 million hosts start using
> HBA, there is a 50% chance of two hosts using the same hash, i.e.,
sort
> of a distributed birthday attack.
>=20
>=20

Delivery-date: Mon, 24 Jul 2006 09:27:39 +0000
Cc: shim6-wg <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006 
Date: Mon, 24 Jul 2006 11:26:43 +0200
To: Francis Dupont <[email-masked]>

On 24-jul-2006, at 10:02, Francis Dupont wrote:

>    Too weak for what?

> => direct attack against the hash (the O(2^56)).

Hm, even if you build a machine that can test 1000 hashes in parallel  
every microsecond, it will take you more than a year on average to  
find a hash collision. And when you've found one, you get to redirect  
traffic, which is only a denial of service attack. If you have enough  
money to build such a hash breaking machine and enough patience to  
wait for it to work, I'm sure other, more dangerous avenues of attack  
are also open to you...

An interesting issue is that after some 10 million hosts start using  
HBA, there is a 50% chance of two hosts using the same hash, i.e.,  
sort of a distributed birthday attack.

Delivery-date: Sun, 23 Jul 2006 21:04:17 +0000
Date: Mon, 24 Jul 2006 07:02:13 +1000
To: shim6-wg <[email-masked]>
From: Geoff Huston <[email-masked]>
Subject: Re: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006 
Cc: [email-masked]

Resent for Francis Dupont, as his pointing was bounced by the him6 
list manager (non-member submission

======================
In your previous mail you wrote:

    > => STARTTLS (the mechanism which encrypts the SMTP session) has
    > authentication and this doesn't solve what you believe this solves.

    Well, not if you turn off authentication:

=> this is a particular setup implied by an operational consideration:
authentication can be done only with a global PKI when unknown peers
should be accepted.

    There has been a lot of debate on whether having authentication in
    email

=> STARTTLS is not email, it is only about MTA-MTA transport.

    will solve the various problems that plague it. It won't solve
    some (spam will remain to some degree if you want to be able to
    receive messages from people you don't know) but it will solve others
    (all those bounces from spam messages that use my domain).

=> this has nothing to do with real authentication, it is more
related to ingress filtering. And as you can see, it is pretty
inefficient because any action at the MTA-MTA transport level is
defeated by indirect delivery (it is the same for grey listing,
and unfortunately it will be the same with real authentication using
a global PKI).

    But encryption won't help with any of this.

=> encryption is in this context the defense against eavesdroppers.

Regards

[email-masked]
==================

Delivery-date: Sun, 23 Jul 2006 21:03:47 +0000
Date: Mon, 24 Jul 2006 07:02:12 +1000
To: shim6-wg <[email-masked]>
From: Geoff Huston <[email-masked]>
Subject: Re: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006 
Cc: [email-masked]

Resent for Francis Dupont, as his pointing was bounced by the him6 
list manager (non-member submission

======================

In your previous mail you wrote:

    > => I strongly disagree about the first point (the main threat of mip
    > is the remote redirection, time shifted attacks and similar things are
    > second order issues),

    i agree that the main threat is redirection attacks and this is
    reflected in 4218, but my point was that the most dificult attacks to
    prevent are the time-shifted attacks and this is why we end up with
    things like _periodic_ RR in mip and HBA/CGA in shim.

=> IMHO the periodic RR in mip is more to get the attacker staying
on the path than to defend against the steal of future addresses...
But the real issue here is about the method: in security one has to
provide a defense against main threats, *then* secondary threats, etc.
As perfect security is impossible one has to accept some remaining
vulnerabilities...
Here we are in trouble because the main threat is hard: the best known
defense, mutual strong authentication, is not deployable. So we get
poor mechanisms (like RR) and we try to improve them (like CBA) against
secondary threats when the main one still remains... I really like
to see shim far better than mip!

    If time shifted
    attacks were not an issue, we could have used cookies for instance or
    hash chains to protect the shim in conjuction the already existent
    routing based security (meaning the asumption that the routing system
    delivers packets to the rightful "owners" of the addresses)

=> again IMHO you miss the real issue...

    So, the hypothesis of 4218 and of mip security is of course as you say
    that the fundamental threat is redirection attacks, but also that time
    shifted attacks need to be prevented... agree with this?

=> no: I really prefer to get time shifted attacks as a remaining
vulnerability than redirection. Of course it should be better to
have none but it is enough hard to choose between acceptable level
of security and deployable solutions to be at least as possible
disturbed by secondary threats.

    >  and I don't fully agree with the second because
    > the only issue is the global PKI (ie., issuing client certificates is
    > again second order).

    global PKI is a big obstacle for deployment but imho the generation of
    client certificates it is also. I mean imagine having to create client
    certificate for every host in the internet. Imagine that for those, you
    need to verify the rightful ownership of the IP address included in the
    certificate. Technically this may be simple, but logistically, this
    requires a lot of effort imho

=> by a global PKI I mean global certification *and* registration
authorities. The problem is not technical at all even I don't believe
we know how to do it in a reasonable timeframe at this scale today.

Regards

[email-masked]

Delivery-date: Sun, 23 Jul 2006 21:03:16 +0000
Date: Mon, 24 Jul 2006 07:02:08 +1000
To: shim6-wg <[email-masked]>
From: Geoff Huston <[email-masked]>
Subject: Re: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006 
Cc: [email-masked]

Resent for Francis Dupont, as his pointing was bounced by the him6 
list manager (non-member submission

======================

In your previous mail you wrote:

    > Here we are in trouble because the main threat is hard: the best known
    > defense, mutual strong authentication, is not deployable. So we get
    > poor mechanisms (like RR) and we try to improve them (like CBA) against
    > secondary threats when the main one still remains... I really like
    > to see shim far better than mip!
    >

    but do you think that the security resulting with HBAs and the
    additional mechanisms available in shim are good enough?

=> HBAs are weaker than CGAs (which provide ownership using the signature),
and than standard strong authentication (using some kind of PKI).
Without the hash extension IMHO they would be too weak, now we have
to take advice from cryptographers to understand if/how to improve them...

Regards

[email-masked]

PS: BTW my employer when I implemented HBAs was "GET/ENST Bretagne".

Delivery-date: Sun, 23 Jul 2006 20:37:30 +0000
Date: Mon, 24 Jul 2006 06:36:38 +1000
To: shim6-wg <[email-masked]>
From: Geoff Huston <[email-masked]>
Subject: Notes from the IETF 66 WG Meeting

Site multi-homing by IPv6 Intermediation WG (SHIM6)
IETF 66, 2006-07-10 15:20

CHAIRS:

   Geoff Huston & Kurtis Lindqvist

NOTES:

   Shinta Sugimoto

SUMMARY:

   The base specification document set was considered by the Working 
Group and there are considerations of IPR and the interaction between 
Shim6 and IPSEC that require some further effort at achieving WG 
consensus prior to undertaking a WG Last call on these documents.

   The Working Group reviewed progress with implementations of this protocol

   The WG considered areas of potential extension of this protocol, 
as well as the overall direction of the work in this working group.

   WG is still on the progress of making the base documents as 
Proposed Standard on the basis that we can resolve remaining issues 
to the WG's satisfaction.

   Proposed adoption of new WG documents. Applicability statement and 
API document

ACTIONS:

   Last call of HBA / Proto / Failure Detection document set

     - IPR issues with HBA and CGA use in Shim6

     - IPSEC and ULID issues

     - Re circulate Security Directorate review of SHim6

   Applicability draft

     - Revise draft per WG comments

   Locator Pair Selection draft

     - Revise draft per WG comments
     - KJeep this separate from  draft-bagnulo-rfc3484-update-00.txt

   Ingress Filtering

     - Adopt draft-bagnulo-shim6-ingress-filtering-00.txt as a WG document?

   Extended Shim6 Design

     - Adopt draft-nordmark-shim6-esd-00.txt as a WG document?

   Privacy Analysis

     - Adopt draft-bagnulo-shim6-privacy-00.txt as a WG document?

   Socket API

     - Adopt draft-sugimoto-multihome-shim-api-00.txt as a WG document?

AGENDA:

  1) Administrivia

    - Mailing list: http://ops.ietf.org/lists/shim6/
    - Scribe?
    - Blue Sheets
    - Agenda Bashing

  2) Status of "base specification" document set

     1. Level 3 multi-homing shim protocol
        http://www.ietf.org/internet-drafts/draft-ietf-shim6-proto-05.txt

     2. Hash Based Addresses (HBA)
        http://www.ietf.org/internet-drafts/draft-ietf-shim6-hba-01.txt

     3. Failure Detection and Locator Pair Exploration Protocol for IPv6
        multi-homing
        http://www.ietf.org/internet-drafts/draft-ietf-shim6-failure-detection-05

  3) SHIM6 Applicability

     1. Applicability (Marcelo Bagnulo, Joe Abley)

        Applicability Statement for the Level 3 multi-homing Shim Protocol
        http://www.ietf.org/internet-drafts/draft-ietf-shim6-applicability-01.txt

   4) SHIM6 Implementation Reports

      1. Implementation Report (Marcelo Bagnulo)

      2. Progress report on ETRI SHIM6 Implementation (Taewan You)

   5) SHIM6 Extension Drafts

      1. Locator Pair Selection (Marcelo Bagnulo)

         Default Locator-pair selection algorithm for the SHIM6 protocol
         http://www.ietf.org/internet-drafts/draft-ietf-shim6-locator-pair-selection-00.txt

      2. ESD (Erik Nordmark)

         Extended Shim6 Design for ID/loc split and Traffic Engineering
         http://www.ietf.org/internet-drafts/draft-nordmark-shim6-esd-00.txt

      3. Ingress Filtering (Marcelo Bagnulo)

         Ingress filtering compatibility for IPv6 multihomed sites
         http://www.ietf.org/internet-drafts/draft-bagnulo-shim6-ingress-filtering-00.txt

      4. Privacy Analysis (Marcelo Bagnulo)

         Privacy Analysis for the SHIM6 protocol
         http://www.ietf.org/internet-drafts/draft-bagnulo-shim6-privacy-00.txt

      5. Socket API (Shinta Sugimoto)

         Socket Application Program Interface (API) for multi-homing Shim
         http://www.ietf.org/internet-drafts/draft-sugimoto-multihome-shim-api-00.txt

  6) WG Direction

      Illjitsch van Beijnum

NOTES:

  - Status of "base specification" document set (Chairs)

    [no presentation slides]

    The WG chair's report noted that Hash Based Address draft has 
passed a WG Last Call in October 2005, the Protocol Specification has 
passed a WG Last Call early 2006, and the Failure Detection and 
Locator Pair Exploration has not been Last Called as yet.

    The WG chairs noted that the ADs have requested that the base 
protocol specification documents be reviewed by the IESG as a set, 
and it made sense to perform a Working Group Last Call for the set of 
these three documents.

    The chairs proposed a Working Group Last Call on these three 
documents, if there is no objection. The chairs asked for comments on 
these 3 base specification documents.

    [WG Comments on the Protocol Specification Document Set]

    Jim Bound: I intend to await the IETF Last Call, but at that 
stage I will object to these documents on the basis of considerations 
of IPR and the interaction of this protocol with IPSEC. These are 
serious and unacceptable problems. I see no further value in 
discussing this in the WG, and would prefer to outline my case to the IESG.

    Chair (Geoff Huston): For the benefit of WG members could you 
elaborate on your issues with IPR?

    Jim: CGA - Ericsson's IPR statement is not acceptable. It says 
that Ericsson will interfere with your right to use these, unless the 
user imposes a patent condition on Ericsson. This is not acceptable. 
HBA is based on CGAs. I want to make this an IETF issue and that's 
why I prefer to raise this at IETF Last Call time.

    Chair (Geoff Huston): Ask the WG for some guidance here as to 
what to do. We have consulted with the ADs on this topic, and we've 
been advised that the ADs will follow the WG's advice and guidance 
here. Is there further comment on the IPR issues on the use of 
cryptographic material in the identity part of the address as it 
pertains to HBA use in SHIM6, now would be a good time to say so, as 
the WG view is one that the IESG will note. I would like to hear 
other views on this.

    Jim: This is a much bigger issue than shim6. I would like to use 
this as grounds for an appeal to amend the way in which we operate in 
the IEF. This is unacceptable and we cannot go on like this in the 
IETF. I would hope that the Shim6 Working Group proceeds with these 
document as I would prefer that this issue was raised at the IESG level.

    Kurtis: Noted that this is not an unique IPR condition, and 
similar IPR constraints are in other parts of IETF work.

    Jim: So this is not an issue that is unique to this WG.

    Jim: The IPSEC issue is that the ULIDS should be encrypted by 
IPSEC. I'm going to object to this.

    Chair (Geoff Huston): Could we divide the two issues and collect 
IPR issues first.

    Jari Arkko: AS a process comment, it's WG's responsibility to 
decide based on various factors (technical, IPR, etc.) with regard to 
the documents. WGLC would be a good place for WG members to give 
opinions. When it comes to IETF LC, it's also IETF issue not just a 
WG issue. The WG members should voice their preferences at Working 
Group Last Call time.

    Illjitsch van Beijnum: Does Ericsson's IPR cover also HBA not only CGA?

    Jari Arkko: [author and Ericsson employee] The intent of the IPR 
declaration is to make if possible to use the public key versions 
without problems and it does not intend to collect money from 
companies. The constraints are defensive in nature. I am personally 
not sure if the patent covers HBA or not. The IPR claim states that 
it may apply.

    Illjitsch van Beijnum: This point is important. We should know 
this in advance. If the CGAs are the problem, then we could change 
HBAs not to be dependent on HBAs

    Kurtis: But to establish this may entail some form of legal action

    Illjitsch: Is there someone who could advise us here?

    Kurtis: That's not the way IPR works.

    Bob Hinden: I think this is general IETF issue. This type of IPR 
statement is fairly common. My suggestion to Jim is that appeals will 
not produce what you are looking for. This form of IPR is allowed 
with the current process documents. You may want to consider a BOF 
and then chartering a WG to examine this issue in detail.

    Dave Thaler: There is an IPR WG already meeting this week.

    Jim Bound: SeND is also based on CGA. Think that IPsec works fine 
for SeND. Its good that there is an IPR WG in the IETF, but I still 
intend to appeal this on IPR grounds.

    Suresh Krishnan: The IPR is Non Assert (NA) just for the SEND 
specification, and seems not to apply to HBA implementations.

    Hannes Tschofenig: We should be careful about the coverage of the 
IPR as in many cases it's not clear. It's not good for WG to solve legal issue.

    Chair (Geoff Huston): Chairs are not expecting WG to solve legal 
issue. But the ADs would like to sense the level of comfort of the WG 
members to pass the documents to the IESG for RFC publication.

    Pekka Savola: This is a more generic issue. We had similar 
situation with Cisco in the NEMO WG.

    John Loughney: I would be more comfortable if this (HBA) is not 
the key part of the protocol. For SHIM6 to be successful, we need to 
see a lot of open source implementations, and this IPR may inhibit 
open source projects to implement the specification. My comfort level 
would be higher without the IPR.

    Chair (Geoff Huston): HBA is one of the core documents. HBA is 
certainly part of specification.

    Speaker (the person who actually submitted the IPR statement from 
Ericsson): Discussions made so far only cover one side. Those who 
feel uncomfortable with Non Assertion, free-of-charge statement, can 
actually take a license and sue if they want. There are two options, not one.

    Vijay Devarapalli: Think RAND (Reasonable And Non-Discrimatory 
terms) is good enough and Ericsson's IPR claim does give you RAND. It 
would be good if royalty free to open source implementations were 
available and give RAND for any other companies. This has been used 
for other protocols in the IETF.

    Jari Arkko: Yes, Ericsson's IPR statement actually provides this. 
Anyone can use this technology free as far as we (Ericsson) are 
concerned. And RAND condition can also be applied.

    Jim Bound: As a Working Group member I object to this. People 
representing company and dealing with IPRs make IETF more 
complicated. We should stop this. People should attend IETF as 
individuals. If you are presenting corporate work that has patents, 
then this should not be part of the IETF. I do want patented 
technology to be in the IETF. we should stop this.

    Marcelo Bagnulo: I am author of the HBA document and I don't work 
for any company and I didn't come here with any kind of patents.

    Illjitsch van Beijnum: Maybe we would be more comfortable is we 
had an alternative to HBA. For proxy, HBA is hard to do.

    Chair (Geoff Huston): I'm asking for a show of hands: based on 
the spec we have now and the IPR knowledge we have now, then I'm 
asking as chair for a show of hands on the level of comfort and the 
level of discomfort in proceeding to a Working Group Last Call on 
these documents.

    *** Voting ***

    asking WG members for comfort level to the base documents as it 
is now. Not for making a Working Group decision but for feeling the 
sense of the WG members

    Results of the straw poll:

        Comfortable: 18
        Not Comfortable: 20

    Summary:

    No consensus. WG will not going to the WGLC for the base 
documents. Need to solve these issue with IPR to the WG's satisfaction.

    ***

    Chair (Geoff Huston): As in current SHIM6 architecture, IPsec is 
based on ULID, not on locator. But Jim Bound suggested that the order 
of ULID substitution and IPsec processing should be reversed. Any 
comments on this? [no further WG comment] Jim, could you explain the 
reasons for your position?

    Jim Bound: IPSEC architecture takes addresses based on the 
addresses in the packet. Jim asserts that the IPSEC in shim6 needs to 
take the addresses that are nested within the packet, and not the 
outer packet header addresses. Does not know how decrypt IPsec 
protected packet can be done. In the current IPsec model, decryption 
is done based on the IP address not by locator.

    Dave Thaler: (for inbound packet processing) Demux of SHIM6 
header will be done based on context ID. All that appears in the data 
packet is the context identifier. This context identifier then allows 
ULID substitution into the packet header.Then IPsec processing is 
done based on ULID pair.

    Jim Bound: In the past decision was made not to do out-of-band 
signaling. We chose not to do this out-of-band signaling some years 
back. IN shim6 we are reversing the architecture decision.

    Dave Thaler: The issue you (Jim Bound) is raising is in-band 
signaling vs. out-of-band signaling ?

    Jim Bound: Yes. It has an affect on implementation.

    Illjitsch van Beijnum: But you can see in the packet the IPsec 
header first or SHIM6 header first, in either case, one should 
coordinate to the other end.

    Chair (Geoff Huston): Please write down concerns on this topic 
and post them to the mailing list.

    Pekka Savola: Clarification on HBA. What was the results of 
security directorate?

    Jari Arkko: Feedback from security directorate: Seems to work. 
Concern about relation with other existing mechanisms like CGA. Also 
what about implications using HBA together with IPsec based on public 
key. What would that mean? No conclusion made on what exactly we 
should do made by the WG.

    Summary by the chairs:

    WG will not go for WGLC. Following issues need to be solved:

        1) IPR issue (CGA and HBA)
        2) IPsec and ULID
        3) Consideration of security review of HBA

  - SHIM6 Applicability (Joe Abley)

    Vijay Devarapalli: One objection to the use of SHIM6 for route 
optimization in MIP6. Prefer using SHIM6 for MIPv6 node which has 
multihomed home network.

    Marcelo Bagnulo: Ok with removing it (route optimization based on SHIM6).

    Shinta Sugimoto: Just want to mention that socket API that we 
define also touches some interactions between SHIM and upper layer 
protocols, namely application.

    Joe Abley: It's for application. But what specifically mentioned 
in the presentation is about interaction between shim and transport 
layer protocol.

    Chris Wood: Why SHIM6 is doing this at host-level, not by network-level?

    Chair (Geoff Huston): In the past activity on multi-homing and 
IPv6 was done in the Multi6 WG. This work terminated in the last 
August with a recommendation to IESG to proceed with a protocol, 
which is a SHIM6. The WG is chartered to develop the protocol for 
particular architecture.

  - SHIM6 Implementation Reports

    Implementation reports (Marcelo Bagnulo)

      Ericsson - based on HIP4BSD, timeframe is 2006.
      UCL - already have an alpha version. September 2006.
      OpenHIP - planning to work on SHIM6. GPL.

    ETRI - Progress Report on Shim6 Implementation" (Taewan You)

      Working on development of SHIM6 implementation on Linux.

      Phase-1:
        - SHIM6 stack based on Netfilter
        - Library for SHIM6
        - Simplified testbed
      Phase-2:
        - Direct kernel patch for SHIM6
        - API for cross layer
        - Extended socket API for SHIM

  - Default locator-pair selection algorithm (Marcelo Bagnulo)

    How to select locator pair after the outage. Why not 3484? Need 
to consider additional preference information is provided by SHIM6 
protocol itself.

    Jari Arkko: High level comment about the rule set. What is your 
plan to proceed these rules? Incorporate them into reachability protocol?

    Marcelo Bagnulo: I have no plan.

    Jari Arkko: It may be better to incorporate them later, after 
issues are solved. There are a number of rules and some open issues 
are still there. This appears to be future work for Shim6.

    Tim Shepherd: There is potential for considerable complexity 
here. Did you include site administrator's preferences? For instance, 
campus network. When should this decision (preference on locator) 
should be made? This is an interesting issue. Also the locator choice 
has path implications. Should path characteristics have an impact on 
locator selection rules? Is trying to make the right thing happen in 
scope for this working group?

    Chair (Geoff Huston): yes

    Marcelo Bagnulo: Draft takes into account for local 
priority/weight, local pair preference table. How to distribute the 
priority (preference) is outside scope. Dynamic adaptation based on a 
kind of measurement would be hard to do. Protocol is needed to 
perform the measurement.

    Illjitsch van Beijnum: There is the option of inclusion of 
timestamp information in the packet for measuring RTT. The trouble is 
that it would become necessary to perform measurement experiments for 
all available combinations of locators.

    Tim Shepherd: If the task is to download a large object, then 
there is some real value in selection of a high volume path. Is this 
in scope for the working group?

    Geoff Huston: (not chair) The base spec has made a number of 
simplifying assumptions to get a working model specified, and part of 
that assumption set is that all applications are the same and all 
locators are equivalent in terms of their properties. However, its 
recognized that different applications have different desires for 
underlying path characteristics. Context forking allows application 
to specify locator preference. Richer API may allow application to 
allow "fork" the context and gather more information about the path 
and greater levels of preference setting by the upper protocol 
entity. For example VOIP may have different desires than bulk transfer.

    Tim Shepherd: This is a reassuring response.

    Geoff Huston: Shim6 gives you a set of abilities in terms of 
forked contexts.

    John Loughney: Good potential for unbounded problem space. There 
are lots of factors (bandwidth, RTT, price etc.) to consider in terms 
of making choice of locator.

    Dave Thaler: What's the relation with this work to the RFC3484 
update? In SHIM6, application basically does not know if there is 
shim or not. API may be required for application to make the initial 
selection but what's the difference? How much of them can be common? 
Does it make sense to combine them?

    Marcelo Bagnulo: This draft specifies rules that takes into 
account for the information provided by the SHIM6 protocol itself. 
This is not the case in normal(non-shim6) case which is discussed in 
RFC3484. Secondly, some of the choices are not exactly the same for 
identifier selection and locator selection.

    Not sure if we want to add complexity which results from locator 
information into RFC3484 update.

    RFC3484 refinement is treated in INTAREA.

    Illjitsch van Beijnum: Think it's good to separate the two 
documents. In locator-pair selection, we focus on reachability. On 
the other hand, in RFC3484 you assume everything works.

    Dave Thaler: Maybe information from locator-pair selection 
algorithm may be useful for normal source and destination address 
selection (RFC3484).

    Illjitsch van Beijnum: Actually there are other things that can 
also be used too. TCP knows reachability of the two endpoints. SCTP too.

    Dave Thaler: NUD in IPv6 takes account for information from upper 
layer protocol to determine reachability. Abstract API can be used to 
handle this information.

    Greg Daley: Existing document which describes protocol 
independent transmission control block. Can also be used to figure 
out reachability to the destination.

    Summary by Chair:

      - Locator-pair document will be worked in SHIM6 WG and RFC3484bis to
        be worked in INTAREA. (no objection was made)

  - Ingress Filtering and Exit Path Selection (Marcelo Bagnulo)

    [presentation]

    Chair (Geoff Huston): If there is no objection, the WG will take 
this document as WG item.

    [no objection and the document was proposed to be adopted as a WG document]

  - Socket API for multi-homing Shim" (Shinta Sugimoto)

    [presentation]

    Francis Dupont: See common issue with mobility case. This kind of 
extensions are not necessary for all application. So, the effect 
should be limited to the application that requests it.

  - Shim6 WG direction (Illjitsch van Beijnum)

    [presentation]

    Kurt Lindqvist: (not as chair) I disagree with the suggestion 
here about going for experimental track documents in preference to 
standards track. If there is any feature that should be included in 
the spec and must work from the first day for shim6 to work, then 
those should be included in the specification. This is the purpose of 
a last call. If there are additional features required ion the base 
spec then list them for the working group and allow the working group 
to consider them. This has been the way we've operated in shim6 to date.

    Jari Arkko: The threads that you (Illjitsch) mentioned on the 
mailing list are valid but I disagree with adding new features to the 
protocol at this stage. Would rather do these as extensions, and move 
forward the current spec, without making a big initial spec.

    Marcelo Bagnulo: My main concern with additional stuff is 
complexity. Base spec is already big at 150 pages of documentation. 
Adding to the specification should be only on the condition that its 
really necessary.

    Bob Hinden: I disagree with the suggestion Illjitsch is making. 
Think that WG should go full speed ahead. Get the standard and 
deployment. Don't spend time spinning.

    Illjitsch van Beijnum: refer to the M&O bits in IPv6. Not 
proposing to take 2-3 more years or making the spec twice as big as 
it is, but providing right features would save time in the end.

    Jari Arkko: Spending more time on specification does not imply 
that the specification is any better. What is needed now is some 
feedback from implementations.

    Pekka Savola: We should be happy with applicability statement 
when we ship the spec.

Delivery-date: Sun, 23 Jul 2006 15:40:50 +0000
Cc: shim6-wg <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006 
Date: Sun, 23 Jul 2006 17:39:31 +0200
To: Francis Dupont <[email-masked]>

On 23-jul-2006, at 17:20, Francis Dupont wrote:

> => HBAs are weaker than CGAs (which provide ownership using the  
> signature),
> and than standard strong authentication (using some kind of PKI).
> Without the hash extension IMHO they would be too weak,

Too weak for what?

I would be interested to learn what kind of attacks that could be  
carried out on the internet as we know it today you feel HBA could be  
vulnerable to.

Delivery-date: Fri, 21 Jul 2006 16:33:15 +0000
Cc: shim6-wg <[email-masked]>, Iljitsch van Beijnum <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006 
Date: Fri, 21 Jul 2006 19:33:01 +0300
To: Francis Dupont <[email-masked]>

El 21/07/2006, a las 19:21, Francis Dupont escribi=F3:

>  In your previous mail you wrote:
>
>    i think there is a misunderstanding here... by verification i am =
not
>    talking about the protocol to perform the verification, but the=20
> actual
>    process carried on by the Registration authority to verify that the=20=

> one
>    that is requesting the certificate actually owns the ip address=20
> that it
>    wants to include in the certificate. It is not the protocol=20
> perspective
>    that i am refering to but the logistic perspective. What is the
>    administrative procedure to perform such verification. My point is=20=

> that
>    you need to build a different administrative setup to verify the
>    information included in this type of certificates...
>
> =3D> in fact I believe it is easier than for names because the address
> assignment is well organized: there is no choice because without
> an address and some routes to your box you can't receive a packet.
> I.e., there is no choice... The whole thing has to be provided by
> the IANA-RIR-LIR-ISPs chain, exactly as RFC 3779 for routing (and
> SEND) or as the reverse tree of the DNS.
> But we are talking about something we know it shan't happen and
> we really want to not rely on (:-)!
>

exactly

at least that it would imply an important deployment cost

regards, marcelo

> Regards
>
> [email-masked]
>

Delivery-date: Fri, 21 Jul 2006 16:32:34 +0000
Cc: [email-masked], "Bound, Jim" <[email-masked]>, "Pekka Savola" <[email-masked]>, "Iljitsch van Beijnum" <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006 
Date: Fri, 21 Jul 2006 19:31:59 +0300
To: Francis Dupont <[email-masked]>

El 21/07/2006, a las 19:13, Francis Dupont escribi=F3:

>  In your previous mail you wrote:
>
>> =3D> I strongly disagree about the first point (the main threat of =
mip
>> is the remote redirection, time shifted attacks and similar things =
are
>> second order issues),
>
>    i agree that the main threat is redirection attacks and this is
>    reflected in 4218, but my point was that the most dificult attacks=20=

> to
>    prevent are the time-shifted attacks and this is why we end up with
>    things like _periodic_ RR in mip and HBA/CGA in shim.
>
> =3D> IMHO the periodic RR in mip is more to get the attacker staying
> on the path than to defend against the steal of future addresses...

i guess that we have a terminology issue here... as i understand,=20
requiring the attaack to stay in the path is prevent time-shifting=20
attacks...

from RFC4225 section 2.2.  Timing

    Without proper
    protection, an attacker could attach itself between the home agent
    and a correspondent node for a while, create a BCE at the
    correspondent node, leave the position, and continuously update the
    correspondent node about the mobile node's whereabouts.

> But the real issue here is about the method: in security one has to
> provide a defense against main threats, *then* secondary threats, etc.

well, the other option is to find a tools that prevents both primary=20
and secondary and so on...

> As perfect security is impossible one has to accept some remaining
> vulnerabilities...

agree

> Here we are in trouble because the main threat is hard: the best known
> defense, mutual strong authentication, is not deployable. So we get
> poor mechanisms (like RR) and we try to improve them (like CBA) =
against
> secondary threats when the main one still remains... I really like
> to see shim far better than mip!
>

but do you think that the security resulting with HBAs and the=20
additional mechanisms available in shim are good enough?

>    If time shifted
>    attacks were not an issue, we could have used cookies for instance=20=

> or
>    hash chains to protect the shim in conjuction the already existent
>    routing based security (meaning the asumption that the routing=20
> system
>    delivers packets to the rightful "owners" of the addresses)
>
> =3D> again IMHO you miss the real issue...
>
>    So, the hypothesis of 4218 and of mip security is of course as you=20=

> say
>    that the fundamental threat is redirection attacks, but also that=20=

> time
>    shifted attacks need to be prevented... agree with this?
>
> =3D> no: I really prefer to get time shifted attacks as a remaining
> vulnerability than redirection.

of course... i mean time shifted attacks are a flavor of redirection=20
attack... i am assuming that a solution that does not provide=20
protection from the most basic forms of redirection attacks are simply=20=

non starters...

among those security mechanisms that provide security to some form of=20
redirection attacks, i am advocating for those that also cover the most=20=

diffult forms i.e. time shifted attacks...

I mean do you agree that we should deal with the threats described in=20
4218?

>  Of course it should be better to
> have none but it is enough hard to choose between acceptable level
> of security and deployable solutions to be at least as possible
> disturbed by secondary threats.

i think HBA mechansim provides protection against most forms of=20
redirection attacks, including tiem shifted attacks

>
>>  and I don't fully agree with the second because
>> the only issue is the global PKI (ie., issuing client certificates is
>> again second order).
>
>    global PKI is a big obstacle for deployment but imho the generation=20=

> of
>    client certificates it is also. I mean imagine having to create=20
> client
>    certificate for every host in the internet. Imagine that for those,=20=

> you
>    need to verify the rightful ownership of the IP address included in=20=

> the
>    certificate. Technically this may be simple, but logistically, this
>    requires a lot of effort imho
>
> =3D> by a global PKI I mean global certification *and* registration
> authorities. The problem is not technical at all even I don't believe
> we know how to do it in a reasonable timeframe at this scale today.

i guess we fully agree here

regards, marcelo

>
> Regards
>
> [email-masked]
>

Delivery-date: Fri, 21 Jul 2006 15:20:46 +0000
Cc: shim6-wg <[email-masked]>, Iljitsch van Beijnum <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006 
Date: Fri, 21 Jul 2006 18:20:31 +0300
To: Francis Dupont <[email-masked]>

Hi Francis,

El 21/07/2006, a las 17:54, Francis Dupont escribi=F3:

>  In your previous mail you wrote:
>
>    yes but the pki for issuing client certificates that bind IP=20
> addresses
>    with public keys may be significatly different from the one=20
> available
>    for TLS server certificates.
>
> =3D> one real world difference is for public TLS servers one is ready =
to=20
> pay...
>
>    In particular, the type of verification
>    that is needed is different since in one case you must verify that=20=

> the
>    fqdn contained in the certificate actually belongs to the server,
>
> =3D> in fact this is not a TLS property but something asks by the=20
> application
> (perhaps through an abstract "secure connection setup").
>

i think there is a misunderstanding here... by verification i am not=20
talking about the protocol to perform the verification, but the actual=20=

process carried on by the Registration authority to verify that the one=20=

that is requesting the certificate actually owns the ip address that it=20=

wants to include in the certificate. It is not the protocol perspective=20=

that i am refering to but the logistic perspective. What is the=20
administrative procedure to perform such verification. My point is that=20=

you need to build a different administrative setup to verify the=20
information included in this type of certificates...

>    while
>    in the other case you need to verify that the particular IP address
>    belongs to a given person, which imho may be harder (since today
>    addresses are not assigned as a unit but prefixes are allocated to=20=

> lirs
>    and lirs assign prefixes to end sites and then end sites assign
>    addresses to hosts, so the verification of the trust chain may be
>    harder imho
>
> =3D> if you want to stick the prefix delegation with the trust chain
> I suggest the RFC 3779 (I can share some code implementing it I did
> for a SEND prototype) but it works only for static assignments and
> perhaps does not well suit to this particular problem (a reverse
> DNSSEC seems better, RFC 3779 was designed for routing protocols).
>

again, i am not talking about certificate formats but the actual=20
administrative provedure and agreements that need to be in place to=20
issue this type of certificates and that they are needed to validate=20
the information included in them

makes sense now?

regards, marcelo

> Regards
>
> [email-masked]
>

Delivery-date: Fri, 21 Jul 2006 15:14:01 +0000
Cc: [email-masked], "Bound, Jim" <[email-masked]>, "Pekka Savola" <[email-masked]>, "Iljitsch van Beijnum" <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006 
Date: Fri, 21 Jul 2006 18:13:41 +0300
To: Francis Dupont <[email-masked]>

Hi Francis,

El 21/07/2006, a las 17:16, Francis Dupont escribi=F3:

>  In your previous mail you wrote:
>
>    It is quite clear for me now the discussion points.
>
>    I think these go way beyond the actual shim6 work, since you seem=20=

> to be
>    challenging some fundamental assumptions that we use to start=20
> working
>    on shim, namely:
>    - the threat model of mip (in particular time shifted attacks that=20=

> were
>    the base threat for requiring mip RR and shim HBAs)
>    - the difficulty in deploying a global PKI and issuing client
>    certificates
>
> =3D> I strongly disagree about the first point (the main threat of mip
> is the remote redirection, time shifted attacks and similar things are
> second order issues),

i agree that the main threat is redirection attacks and this is=20
reflected in 4218, but my point was that the most dificult attacks to=20
prevent are the time-shifted attacks and this is why we end up with=20
things like _periodic_ RR in mip and HBA/CGA in shim. If time shifted=20
attacks were not an issue, we could have used cookies for instance or=20
hash chains to protect the shim in conjuction the already existent=20
routing based security (meaning the asumption that the routing system=20
delivers packets to the rightful "owners" of the addresses)

So, the hypothesis of 4218 and of mip security is of course as you say=20=

that the fundamental threat is redirection attacks, but also that time=20=

shifted attacks need to be prevented... agree with this?

>  and I don't fully agree with the second because
> the only issue is the global PKI (ie., issuing client certificates is
> again second order).

global PKI is a big obstacle for deployment but imho the generation of=20=

client certificates it is also. I mean imagine having to create client=20=

certificate for every host in the internet. Imagine that for those, you=20=

need to verify the rightful ownership of the IP address included in the=20=

certificate. Technically this may be simple, but logistically, this=20
requires a lot of effort imho

Regards, marcelo

>
> Regards
>
> [email-masked]
>

Delivery-date: Fri, 21 Jul 2006 15:02:33 +0000
Cc: shim6-wg <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006 
Date: Fri, 21 Jul 2006 17:02:25 +0200
To: Francis Dupont <[email-masked]>

On 21-jul-2006, at 16:27, Francis Dupont wrote:

>>> => as TLS is in fact a session protocol this idea is good. The only
>>> issue is it can work only when TLS is used... Unfortunately IMHO
>>> we need a protocol at the network layer, no transport (aka SCTP) or
>>> session (aka TLS) even it is more (too?) easy.

>>    Why??

> => just because we don't want to rewrite all applications to use  
> SCTP or TLS.
> Or this is not your question?

My suggestion was to protect the shim signalling with TLS, not the  
ULP traffic.

Delivery-date: Fri, 21 Jul 2006 15:01:27 +0000
Cc: shim6-wg <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006 
Date: Fri, 21 Jul 2006 17:00:33 +0200
To: Francis Dupont <[email-masked]>

On 21-jul-2006, at 16:41, Francis Dupont wrote:

>    Authentication is much more important and even that is certainly  
> not
>    always required.

> => STARTTLS (the mechanism which encrypts the SMTP session) has
> authentication and this doesn't solve what you believe this solves.

Well, not if you turn off authentication:

Received: from laposte.rennes.enst-bretagne.fr  
([IPv6:2001:660:7301:3192:211:43ff:fea3:7e4b])
	by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id k6LEfbXD090899
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
                                                                 
^^^^^^^^^^^

There has been a lot of debate on whether having authentication in  
email will solve the various problems that plague it. It won't solve  
some (spam will remain to some degree if you want to be able to  
receive messages from people you don't know) but it will solve others  
(all those bounces from spam messages that use my domain). But  
encryption won't help with any of this.

Delivery-date: Fri, 21 Jul 2006 11:20:56 +0000
Cc: shim6-wg <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Patent issue, was: Re: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006
Date: Fri, 21 Jul 2006 13:19:36 +0200
To: marcelo bagnulo braun <[email-masked]>

On 20-jul-2006, at 13:56, marcelo bagnulo braun wrote:

[big snip]

> fwiw i don't expect patent problems

> HBA technology is not one where the inventor of the technology is  
> trying to push this technology in the standards so he can make  
> profit out of it. Instead is the case where the HBA technology  
> happens to fall inside a very broad patent claim made by other  
> company. BEsides, the patent holder of this broad claim is claiming  
> that it will not charge for the patent in case of HBA implementations.

Although I still think TLS can be useful, it does look like an uphill  
battle. So we should probably go back to the original question: are  
we comfortable moving forward with HBA even though there is a patent  
claim?

At this point, my answer would be: let's move forward with HBA as the  
only security mechanism or HBA as the primary security mechanism and  
CGA as an additional, optional one, but reserve the right to define  
new security mechanisms in the future, either in addition to HBA or  
as a replacement as the primary mechanism.

I.e., put the community on warning that even though we're comfortable  
with HBA _now_, we're recognizing that bad stuff can happen in the  
future.

It would be good to define how a new security mechanism would  
interact with the shim protocol, but I think this would be time  
consuming and difficult in the absence of additional security  
mechanisms, so it's not really realistic to expect to do this work now.

Delivery-date: Thu, 20 Jul 2006 21:03:41 +0000
To: shim6-wg <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: comments form Dave Meyer about the shim proto v5
Date: Fri, 21 Jul 2006 00:02:18 +0300

You can find them at

http://www.it.uc3m.es/marcelo/comments_draft-ietf-shim6-proto-05.txt

Thanks Dave for the review

we will be commenting this shortly

Regards, marcelo

Delivery-date: Thu, 20 Jul 2006 11:56:56 +0000
Cc: shim6-wg <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006
Date: Thu, 20 Jul 2006 14:56:32 +0300
To: Iljitsch van Beijnum <[email-masked]>

El 20/07/2006, a las 14:15, Iljitsch van Beijnum escribi=F3:

> On 20-jul-2006, at 10:57, marcelo bagnulo braun wrote:
>>> I guess I could live with either requiring a client certificate=20
>>> (especially as this could be one proxy certificate for a proxy that=20=

>>> handles a bunch of clients)
>
>> this is one option, yes, but it requires PKI
>
> We already have an infrastructure for TLS.
>

yes but the pki for issuing client certificates that bind IP addresses=20=

with public keys may be significatly different from the one available=20
for TLS server certificates. In particular, the type of verification=20
that is needed is different since in one case you must verify that the=20=

fqdn contained in the certificate actually belongs to the server, while=20=

in the other case you need to verify that the particular IP address=20
belongs to a given person, which imho may be harder (since today=20
addresses are not assigned as a unit but prefixes are allocated to lirs=20=

and lirs assign prefixes to end sites and then end sites assign=20
addresses to hosts, so the verification of the trust chain may be=20
harder imho

>>>  or that new sessions may only be initiated by the client (server=20
>>> dumps all shim state when it needs to set up a session towards the=20=

>>> client).
>
>> besides, this is kind of messy because the shime needs to be able to=20=

>> tell what a ulp session is, so that it is possible to distinguish=20
>> which packets are part of a new session. In the case of TCP it may be=20=

>> easy, but in the case of unconnected UDP this is much harder...
>
> Yes, this is a good point.
>
> So then it boils down to administratively controlling whether locator=20=

> updates from unauthenticated clients are allowed (in the case of a=20
> server that never connects to a client) or not.
>

this implies quite a few heuristics and special rules and interaction=20
between the shim and the ulps... it may be possible but it may quite=20
complex as well and it may require support from ulp

>>> I expect nearly everyone to implement HBA anyway, but if some people=20=

>>> really don't want it at least they have SOMETHING this way. Not=20
>>> having a mandatory security mechanism is possible here, IMO, as this=20=

>>> simply means no multihoming benefits.
>
>> Not sure i understand this last sentence.... why would anyone want to=20=

>> implement the shim if no multihoming benefits are achieved?
>
> If group A implements shim6+HBA and group B implements shim6+TLS, then=20=

> members of A can still communicate with members of B, but without=20
> being able to activate the shim.

agree, but from the shim perspective this is as good a nothing... i=20
mean, it is clear that ipv6 hosts can communicate without using the=20
shim...

>  While this is suboptimal, it's not problematic, so there is no reason=20=

> to _require_ a certain security mechanism, especially if we expect=20
> patent problems.
>
>

fwiw i don't expect patent problems

HBA technology is not one where the inventor of the technology is=20
trying to push this technology in the standards so he can make profit=20
out of it. Instead is the case where the HBA technology happens to fall=20=

inside a very broad patent claim made by other company. BEsides, the=20
patent holder of this broad claim is claiming that it will not charge=20
for the patent in case of HBA implementations.

The CGA case is a bit different since the inventor of the CGA=20
technology has patented it, but still the patent holder is claiming=20
that they will allow free of charge usage of the CGA technology for the=20=

shim protocol

regards, marcelo

Delivery-date: Thu, 20 Jul 2006 11:22:15 +0000
Cc: "marcelo bagnulo braun" <[email-masked]>, "Francis Dupont" <[email-masked]>, <[email-masked]>, "Pekka Savola" <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006 
Date: Thu, 20 Jul 2006 13:21:51 +0200
To: "Bound, Jim" <[email-masked]>

On 19-jul-2006, at 21:58, Bound, Jim wrote:

> I believe if we encrypt everything (not just shim6 and I did not  
> agree with all the mipv6 threats either and let it go and  
> emphatically disagree with RR strategy ) at the IP layer we are  
> going to be 90% secure most of the time world wide.

A lot of mail servers these days encrypt the SMTP session. We still  
see all kinds of bad stuff in email.

Simply encrypting everything only increases packet overhead, CPU  
requirements and makes debugging extremely hard without necessarily  
solving anything.

Authentication is much more important and even that is certainly not  
always required.

Delivery-date: Thu, 20 Jul 2006 11:17:14 +0000
Cc: shim6-wg <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006 
Date: Thu, 20 Jul 2006 13:17:01 +0200
To: Francis Dupont <[email-masked]>

On 19-jul-2006, at 23:31, Francis Dupont wrote:

>>    Also, I think it would make sense to do the shim negotiation  
>> inside a
>>    TLS protected TCP session, which should handle all the packet size
>>    issues.

> => as TLS is in fact a session protocol this idea is good. The only
> issue is it can work only when TLS is used... Unfortunately IMHO
> we need a protocol at the network layer, no transport (aka SCTP) or
> session (aka TLS) even it is more (too?) easy.

Why??

Delivery-date: Thu, 20 Jul 2006 11:16:46 +0000
Cc: shim6-wg <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006
Date: Thu, 20 Jul 2006 13:15:19 +0200
To: marcelo bagnulo braun <[email-masked]>

On 20-jul-2006, at 10:57, marcelo bagnulo braun wrote:

>>  Same for DNS (X could check whether reverse A -> forward A -> B)  
>> but this is pretty weak also, as long as we don't have DNSSEC.

> well, in addition is the added cost/latency of the additional DNS  
> query

Since shim setup happens when communication is already ongoing,  
latency isn't an issue and as for cost... Well, I can afford it, I  
hope you can too.  :-)

>> I guess I could live with either requiring a client certificate  
>> (especially as this could be one proxy certificate for a proxy  
>> that handles a bunch of clients)

> this is one option, yes, but it requires PKI

We already have an infrastructure for TLS.

>>  or that new sessions may only be initiated by the client (server  
>> dumps all shim state when it needs to set up a session towards the  
>> client).

> besides, this is kind of messy because the shime needs to be able  
> to tell what a ulp session is, so that it is possible to  
> distinguish which packets are part of a new session. In the case of  
> TCP it may be easy, but in the case of unconnected UDP this is much  
> harder...

Yes, this is a good point.

So then it boils down to administratively controlling whether locator  
updates from unauthenticated clients are allowed (in the case of a  
server that never connects to a client) or not.

>> I expect nearly everyone to implement HBA anyway, but if some  
>> people really don't want it at least they have SOMETHING this way.  
>> Not having a mandatory security mechanism is possible here, IMO,  
>> as this simply means no multihoming benefits.

> Not sure i understand this last sentence.... why would anyone want  
> to implement the shim if no multihoming benefits are achieved?

If group A implements shim6+HBA and group B implements shim6+TLS,  
then members of A can still communicate with members of B, but  
without being able to activate the shim. While this is suboptimal,  
it's not problematic, so there is no reason to _require_ a certain  
security mechanism, especially if we expect patent problems.

Delivery-date: Thu, 20 Jul 2006 08:58:23 +0000
Cc: shim6-wg <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006
Date: Thu, 20 Jul 2006 11:57:35 +0300
To: Iljitsch van Beijnum <[email-masked]>

El 19/07/2006, a las 21:59, Iljitsch van Beijnum escribi=F3:

> On 19-jul-2006, at 15:39, marcelo bagnulo braun wrote:
>
>>> Why? If one end has a certificate the communication can be secure.
>
>> but you still can provide identifier ownership proof, right?
>
>> I mean, in order to avoid future attacks agaisnt the identity we need=20=

>> more than just a secure channel but a secure binding between the=20
>> identifier and something that canbe used to prove ownership (like a=20=

>> public/private key pair)
>
>> so, such scheme would result in the posibilty of identity hijacking=20=

>> attacks
>
>> in order to avoid those, you need something else, like client=20
>> certificates
>
> Right, you'd have the situation where client A connects to server X=20
> and X's certificate is used to protect the exchange of A's locator B,=20=

> but then later X wants to talk to A and uses B but it turned out that=20=

> A wasn't really A but someone "borrowing" A's address on an insecure=20=

> link for a moment.
>

exactly

this one attack (imho the most interesting) but you could also think in=20=

attacks in only one direction (not only based in the server=20
establishing connections back to the server)

> Return routability should help a bit here but it's not particularly=20
> strong...

well, a single RR check was not enough for the mip guys, so they=20
actually imposed periodic RR checks (every 7 minutes) in order to=20
prevent time shifted attacks... of course we cannot do the same=20
approach here, because after a failure, the RR check is no longer=20
feasible...

>  Same for DNS (X could check whether reverse A -> forward A -> B) but=20=

> this is pretty weak also, as long as we don't have DNSSEC.

well, in addition is the added cost/latency of the additional DNS query

>
> I guess I could live with either requiring a client certificate=20
> (especially as this could be one proxy certificate for a proxy that=20
> handles a bunch of clients)

this is one option, yes, but it requires PKI

>  or that new sessions may only be initiated by the client (server=20
> dumps all shim state when it needs to set up a session towards the=20
> client).

this would eliminate some of the attacks indeed
we should analyze the impact of remaining attacks
and the limitation is that a server cannot initiate communication=20
towards client ever, right?

besides, this is kind of messy because the shime needs to be able to=20
tell what a ulp session is, so that it is possible to distinguish which=20=

packets are part of a new session. In the case of TCP it may be easy,=20
but in the case of unconnected UDP this is much harder...

>
> I expect nearly everyone to implement HBA anyway, but if some people=20=

> really don't want it at least they have SOMETHING this way. Not having=20=

> a mandatory security mechanism is possible here, IMO, as this simply=20=

> means no multihoming benefits.
>
>
Not sure i understand this last sentence.... why would anyone want to=20
implement the shim if no multihoming benefits are achieved?

Regards, marcelo

Delivery-date: Thu, 20 Jul 2006 07:58:12 +0000
Cc: "Francis Dupont" <[email-masked]>, <[email-masked]>, "Pekka Savola" <[email-masked]>, "Iljitsch van Beijnum" <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006 
Date: Thu, 20 Jul 2006 10:57:20 +0300
To: "Bound, Jim" <[email-masked]>

Hi Jim,

It is quite clear for me now the discussion points.

I think these go way beyond the actual shim6 work, since you seem to be=20=

challenging some fundamental assumptions that we use to start working=20
on shim, namely:
- the threat model of mip (in particular time shifted attacks that were=20=

the base threat for requiring mip RR and shim HBAs)
- the difficulty in deploying a global PKI and issuing client=20
certificates

I very much agree that if we change these assumptions the resulting=20
shim6 design would be very different

OTOH, it was/is my feeling that at the time of the design and even now,=20=

there seem to be consensus that these points are valid (in other words,=20=

we had lots of discussions here and in multi6, but not many folks=20
challenged these points, you are the first AFAICT)

So, i guess we can discuss these of course, and make a consensus call=20
on these items in the wg

Regards, marcelo

El 19/07/2006, a las 22:58, Bound, Jim escribi=F3:

> OK I have a lot of work to do for this now but that is cool as SHIM6=20=

> is important. day job is in the way at the moment.
>
> Here is a bottom line from Jim.  I believe if we encrypt everything=20
> (not just shim6 and I did not agree with all the mipv6 threats either=20=

> and let it go and emphatically disagree with RR strategy ) at the IP=20=

> layer we are going to be 90% secure most of the time world wide.  But=20=

> I do believe after decrypt that multi-layered security is important=20
> but I think the threats after IPsec are so reduced that given=20
> deployment it is of less concern from Jim's view of the world.  I also=20=

> believe PKI will get figured out and scale if not this year three=20
> years from now that it is not right for me to limit protocol views in=20=

> my head in the IETF because of deployment scenarios I cannot possible=20=

> know the answer to with axiomatic certainty.
>
> Disclaimer: This view does not represent the view of my company, the=20=

> IPv6 Forum, or any one I work with this solely a Jim view of the=20
> world, but I do have some in security world who are expert=20
> cryptographers and worry a lot about very important attacks I consult=20=

> with who do agree with this view.
>
> OK back to work we need to hear from you folks in the WG now for sure?=20=

>  Good discussion for sure but probably driving the chairs nuts :--)
>
> /jim
>
>> -----Original Message-----
>> From: marcelo bagnulo braun [mailto:[email-masked]]
>> Sent: Wednesday, July 19, 2006 3:43 PM
>> To: Bound, Jim
>> Cc: Francis Dupont; [email-masked]; Pekka Savola; Iljitsch van Beijnum
>> Subject: Re: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006
>>
>>
>> El 19/07/2006, a las 22:30, Bound, Jim escribi=F3:
>>
>>> I dont accept the threats in 4218 so that is a problem right there
>>
>> we have identified the core issue i think, great!!
>>
>> we have based the design of the shim6 security on the threats
>> identified on RFC4218, so if you don't agree with those, we
>> need to discuss those first and then move on to the security
>> solutions (since they are direct consequence of the threats
>> described there)
>>
>> proabably we should even also consider the threats of MIP described =
in
>> RFC4225 since RFC4218 is heavily based on this one...
>>
>>
>> But good we are making progress (at least in identifying the
>> disagreement points)
>>
>> regards, marcelo
>>
>>
>>> but I will do that but that is more than just a quick response on
>>> email and need to go do proper analysis.  I will respond to
>> where we
>>> disagree too later ok.  As I said email is not good for me
>> now I keep
>>> changing my location :--).
>>>
>>> thx
>>> /jim
>>>
>>>> -----Original Message-----
>>>> From: marcelo bagnulo braun [mailto:[email-masked]]
>>>> Sent: Wednesday, July 19, 2006 3:27 PM
>>>> To: Bound, Jim
>>>> Cc: Francis Dupont; [email-masked]; Pekka Savola; Iljitsch
>> van Beijnum
>>>> Subject: Re: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006
>>>>
>>>>
>>>> El 19/07/2006, a las 20:10, Bound, Jim escribi=F3:
>>>>
>>>>> Global PKI is not required for certificates that can be done with
>>>>> pre-shared keys too or as we are doing with shim6 out-of-band
>>>>> signaling.  If any here believe IPsec will not be used end-to-end
>>>>> think again please it will.  Ipsec is totally possible and
>>>> I will not
>>>>> repeat my mail on enclaves for end-to-end PKI as that is a
>>>> deployment
>>>>> and systems integration implementation issue.
>>>>>
>>>>
>>>> ok at this point it seems to me that we may start to
>>>> repeating ourselves, so at least let's try to identify where
>>>> do we disagree...
>>>>
>>>> What i am saying is that:
>>>>
>>>> - In order to use IPSec to protect the shim6 protocol (in
>>>> particular for providing a secure binding between identifier
>>>> and locators), there are two options: a) we use certificates
>>>> issued by a global PKI are needed in all shim6 peers or b) we
>>>> have preshared keys in all shim6 nodes
>>>>
>>>> do you disagree with this statement?
>>>>
>>>> I assume you do
>>>>
>>>> if you disagree could you explain to me how would you protect
>>>> the shim6 protocol from the threats described in RFC4218?
>>>>
>>>> in particular could you explain to me how would you protect
>>>> from the following attack:
>>>>
>>>> Suppose that Alice and Bob work in the same office and that
>>>> Alice reads the local newspaper web page every morning at
>>>> www.localpress.com Now, suppose that tomorrow is Alice
>>>> birthday and since Bob has a crush on Alice, Bob wants to
>>>> make Alice believe that tomorrow local newspaper headline is
>>>> "Happy Birthday Alice".
>>>>
>>>> In order to do that, Bob's plan is to hijack any future
>>>> communication that Alice initiates from her machine to Bob's
>>>> laptop, so Bob can substitute the local newspaper web page by
>>>> his own fake happy birthday greetings home page.
>>>>
>>>> So, in the DNS www.localpress.com has a single IP address IPlp.
>>>>
>>>> To launch the attack, the night before, Bob creates a shim6
>>>> state in alice machine. In order to do that, Bob initiates
>>>> the shim6 context establishment exchange.
>>>>
>>>> The created context, has IPlp as ULID and it has IPB (i.e.
>>>> Bob's laptop
>>>> IP) as preferred locator.
>>>>
>>>> In order to keep the context alive, Bob sends periodic
>> packets (e.g.
>>>> ping or UDP) to Alice machine. Note that the goal of these
>>>> packets is just to prevent the shim6 state at Alice machine
>>>> to be garbage collected, so there is no need to have a actual
>>>> application receiving those packets above the shim (i.e.
>>>> these packets can be perfectly discarded once they passed
>>>> above the shim, and they would still be fulfilling their goal
>>>> from the attack p.o.v.)
>>>>
>>>> The next morning (Alice birthday!!!) Alice arrives to the
>>>> office and she tries to connect to the local newspaper as
>>>> everyday. The only difference is that today, there is a shim6
>>>> state in Alice machine for IPlp.
>>>> Alice browser asks the resolver for www.localpress.com. the
>>>> resolver returns IPlp. The browser initiates a TCP connection
>>>> with IPlp, but the SYN packet is intercepted by the shim
>>>> layer (at Alice's machine) and the address is translated to
>>>> IPB. the result, the communication is redirected to Bob's
>>>> machine and Alice will be accessing Bob's web server while
>>>> she thinks that she is reaching the local newspaper web page
>>>>
>>>> Bob has managed to steal the local newspaper IP identity from
>>>> Alice p.o.v.
>>>>
>>>> This type of attack cannot be prevented by simply using
>>>> IPSec, because it is launched before the keys have been exchanged.
>>>>
>>>> In order to prevent these attacks, we need additional tools,
>>>> like global certificates, pre shared keys or crypto identities.
>>>>
>>>> reagrds, marcelo
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> thanks
>>>>> /jim
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: marcelo bagnulo braun [mailto:[email-masked]]
>>>>>> Sent: Wednesday, July 19, 2006 11:32 AM
>>>>>> To: Bound, Jim
>>>>>> Cc: Francis Dupont; [email-masked]; Pekka Savola; Iljitsch
>>>> van Beijnum
>>>>>> Subject: Re: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006
>>>>>>
>>>>>>
>>>>>> El 19/07/2006, a las 16:55, Bound, Jim escribi=F3:
>>>>>>
>>>>>>> I was assuming the node regardless will use IPsec as
>>>>>> required.  Thus
>>>>>>> it really is not shime6 concern.  But I do not believe no
>>>>>> one will not
>>>>>>> deploy IPsec because of PKI that is simply not true.
>>>>>>
>>>>>> i agree with this
>>>>>>
>>>>>>
>>>>>> but the problem is that if you want to use IPSEc to secure
>>>> the shim,
>>>>>> you need to use certificates, if not the security is not
>>>> acceptable.
>>>>>>
>>>>>> You need to provide a secure binding between the
>> identifer and the
>>>>>> locators. IPSec wihtout certificates does not provides
>>>> this feature.
>>>>>> If you want to use IPSec to secure the
>>>>>> shim6 protocol, you need the certificates hence you need
>>>> the global
>>>>>> PKI.
>>>>>>
>>>>>> So in order to evaluate a solution based on IPSec for
>> securing the
>>>>>> shim6, you need to consider the fact that a global PKI
>> is required
>>>>>> for this.
>>>>>>
>>>>>> Hence, the alternative solution for securing the shim at
>>>> this point
>>>>>> would be IPSec+PKI, agree?
>>>>>>
>>>>>> regards, marcelo
>>>>>>
>>>>>>
>>>>>>
>>>>>>>   IPsec is deployed today with PKI.
>>>>>>>
>>>>>>
>>>>>>
>>>>>>> /jim
>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: marcelo bagnulo braun [mailto:[email-masked]]
>>>>>>>> Sent: Wednesday, July 19, 2006 8:04 AM
>>>>>>>> To: Francis Dupont
>>>>>>>> Cc: [email-masked]; Bound, Jim; Pekka Savola; Iljitsch
>> van Beijnum
>>>>>>>> Subject: Re: CGA Use with HBA in Shim6 IETF Meeting
>> July 10, 2006
>>>>>>>>
>>>>>>>>
>>>>>>>> El 19/07/2006, a las 14:38, Francis Dupont escribi=F3:
>>>>>>>>
>>>>>>>>> I can't see where Jim proposed to base the Shim6 security
>>>>>>>> on IPsec...
>>>>>>>>
>>>>>>>> in message http://ops.ietf.org/lists/shim6/msg01511.html
>>>>>>>>
>>>>>>>> it is stated that:
>>>>>>>>
>>>>>>>> Suggestion is to simply embed ULIDs within the data
>>>>>> payload with new
>>>>>>>> option and secure all communications at least for now
>>>> for IP layer
>>>>>>>> communcatiions with IPsec encryption based on locator pair.
>>>>>>>>
>>>>>>>> meaning to use IPSec as an alternative to HBA security
>>>>>>>>
>>>>>>>>> (something which is known to require the impossible and
>>>> even not
>>>>>>>>> desirable global PKI :-)
>>>>>>>>>
>>>>>>>>
>>>>>>>> exactly
>>>>>>>>
>>>>>>>> Regards, marcelo
>>>>>>>>
>>>>>>>>
>>>>>>>>> Regards
>>>>>>>>>
>>>>>>>>> [email-masked]
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>

Delivery-date: Wed, 19 Jul 2006 19:59:28 +0000
Content-class: urn:content-classes:message
Subject: RE: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006 
Date: Wed, 19 Jul 2006 15:58:22 -0400
From: "Bound, Jim" <[email-masked]>
To: "marcelo bagnulo braun" <[email-masked]>
Cc: "Francis Dupont" <[email-masked]>, <[email-masked]>, "Pekka Savola" <[email-masked]>, "Iljitsch van Beijnum" <[email-masked]>

OK I have a lot of work to do for this now but that is cool as SHIM6 is =
important. day job is in the way at the moment.

Here is a bottom line from Jim.  I believe if we encrypt everything (not =
just shim6 and I did not agree with all the mipv6 threats either and let =
it go and emphatically disagree with RR strategy ) at the IP layer we =
are going to be 90% secure most of the time world wide.  But I do =
believe after decrypt that multi-layered security is important but I =
think the threats after IPsec are so reduced that given deployment it is =
of less concern from Jim's view of the world.  I also believe PKI will =
get figured out and scale if not this year three years from now that it =
is not right for me to limit protocol views in my head in the IETF =
because of deployment scenarios I cannot possible know the answer to =
with axiomatic certainty.

Disclaimer: This view does not represent the view of my company, the =
IPv6 Forum, or any one I work with this solely a Jim view of the world, =
but I do have some in security world who are expert cryptographers and =
worry a lot about very important attacks I consult with who do agree =
with this view.

OK back to work we need to hear from you folks in the WG now for sure?  =
Good discussion for sure but probably driving the chairs nuts :--)

/jim=20

> -----Original Message-----
> From: marcelo bagnulo braun [mailto:[email-masked]]=20
> Sent: Wednesday, July 19, 2006 3:43 PM
> To: Bound, Jim
> Cc: Francis Dupont; [email-masked]; Pekka Savola; Iljitsch van Beijnum
> Subject: Re: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006=20
>=20
>=20
> El 19/07/2006, a las 22:30, Bound, Jim escribi=F3:
>=20
> > I dont accept the threats in 4218 so that is a problem right there
>=20
> we have identified the core issue i think, great!!
>=20
> we have based the design of the shim6 security on the threats=20
> identified on RFC4218, so if you don't agree with those, we=20
> need to discuss those first and then move on to the security=20
> solutions (since they are direct consequence of the threats=20
> described there)
>=20
> proabably we should even also consider the threats of MIP described in
> RFC4225 since RFC4218 is heavily based on this one...
>=20
>=20
> But good we are making progress (at least in identifying the=20
> disagreement points)
>=20
> regards, marcelo
>=20
>=20
> > but I will do that but that is more than just a quick response on=20
> > email and need to go do proper analysis.  I will respond to=20
> where we=20
> > disagree too later ok.  As I said email is not good for me=20
> now I keep=20
> > changing my location :--).
> >
> > thx
> > /jim
> >
> >> -----Original Message-----
> >> From: marcelo bagnulo braun [mailto:[email-masked]]
> >> Sent: Wednesday, July 19, 2006 3:27 PM
> >> To: Bound, Jim
> >> Cc: Francis Dupont; [email-masked]; Pekka Savola; Iljitsch=20
> van Beijnum
> >> Subject: Re: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006
> >>
> >>
> >> El 19/07/2006, a las 20:10, Bound, Jim escribi=F3:
> >>
> >>> Global PKI is not required for certificates that can be done with
> >>> pre-shared keys too or as we are doing with shim6 out-of-band
> >>> signaling.  If any here believe IPsec will not be used end-to-end
> >>> think again please it will.  Ipsec is totally possible and
> >> I will not
> >>> repeat my mail on enclaves for end-to-end PKI as that is a
> >> deployment
> >>> and systems integration implementation issue.
> >>>
> >>
> >> ok at this point it seems to me that we may start to
> >> repeating ourselves, so at least let's try to identify where
> >> do we disagree...
> >>
> >> What i am saying is that:
> >>
> >> - In order to use IPSec to protect the shim6 protocol (in
> >> particular for providing a secure binding between identifier
> >> and locators), there are two options: a) we use certificates
> >> issued by a global PKI are needed in all shim6 peers or b) we
> >> have preshared keys in all shim6 nodes
> >>
> >> do you disagree with this statement?
> >>
> >> I assume you do
> >>
> >> if you disagree could you explain to me how would you protect
> >> the shim6 protocol from the threats described in RFC4218?
> >>
> >> in particular could you explain to me how would you protect
> >> from the following attack:
> >>
> >> Suppose that Alice and Bob work in the same office and that
> >> Alice reads the local newspaper web page every morning at
> >> www.localpress.com Now, suppose that tomorrow is Alice
> >> birthday and since Bob has a crush on Alice, Bob wants to
> >> make Alice believe that tomorrow local newspaper headline is
> >> "Happy Birthday Alice".
> >>
> >> In order to do that, Bob's plan is to hijack any future
> >> communication that Alice initiates from her machine to Bob's
> >> laptop, so Bob can substitute the local newspaper web page by
> >> his own fake happy birthday greetings home page.
> >>
> >> So, in the DNS www.localpress.com has a single IP address IPlp.
> >>
> >> To launch the attack, the night before, Bob creates a shim6
> >> state in alice machine. In order to do that, Bob initiates
> >> the shim6 context establishment exchange.
> >>
> >> The created context, has IPlp as ULID and it has IPB (i.e.
> >> Bob's laptop
> >> IP) as preferred locator.
> >>
> >> In order to keep the context alive, Bob sends periodic=20
> packets (e.g.
> >> ping or UDP) to Alice machine. Note that the goal of these
> >> packets is just to prevent the shim6 state at Alice machine
> >> to be garbage collected, so there is no need to have a actual
> >> application receiving those packets above the shim (i.e.
> >> these packets can be perfectly discarded once they passed
> >> above the shim, and they would still be fulfilling their goal
> >> from the attack p.o.v.)
> >>
> >> The next morning (Alice birthday!!!) Alice arrives to the
> >> office and she tries to connect to the local newspaper as
> >> everyday. The only difference is that today, there is a shim6
> >> state in Alice machine for IPlp.
> >> Alice browser asks the resolver for www.localpress.com. the
> >> resolver returns IPlp. The browser initiates a TCP connection
> >> with IPlp, but the SYN packet is intercepted by the shim
> >> layer (at Alice's machine) and the address is translated to
> >> IPB. the result, the communication is redirected to Bob's
> >> machine and Alice will be accessing Bob's web server while
> >> she thinks that she is reaching the local newspaper web page
> >>
> >> Bob has managed to steal the local newspaper IP identity from
> >> Alice p.o.v.
> >>
> >> This type of attack cannot be prevented by simply using
> >> IPSec, because it is launched before the keys have been exchanged.
> >>
> >> In order to prevent these attacks, we need additional tools,
> >> like global certificates, pre shared keys or crypto identities.
> >>
> >> reagrds, marcelo
> >>
> >>
> >>
> >>
> >>
> >>> thanks
> >>> /jim
> >>>
> >>>> -----Original Message-----
> >>>> From: marcelo bagnulo braun [mailto:[email-masked]]
> >>>> Sent: Wednesday, July 19, 2006 11:32 AM
> >>>> To: Bound, Jim
> >>>> Cc: Francis Dupont; [email-masked]; Pekka Savola; Iljitsch
> >> van Beijnum
> >>>> Subject: Re: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006
> >>>>
> >>>>
> >>>> El 19/07/2006, a las 16:55, Bound, Jim escribi=F3:
> >>>>
> >>>>> I was assuming the node regardless will use IPsec as
> >>>> required.  Thus
> >>>>> it really is not shime6 concern.  But I do not believe no
> >>>> one will not
> >>>>> deploy IPsec because of PKI that is simply not true.
> >>>>
> >>>> i agree with this
> >>>>
> >>>>
> >>>> but the problem is that if you want to use IPSEc to secure
> >> the shim,
> >>>> you need to use certificates, if not the security is not
> >> acceptable.
> >>>>
> >>>> You need to provide a secure binding between the=20
> identifer and the
> >>>> locators. IPSec wihtout certificates does not provides
> >> this feature.
> >>>> If you want to use IPSec to secure the
> >>>> shim6 protocol, you need the certificates hence you need
> >> the global
> >>>> PKI.
> >>>>
> >>>> So in order to evaluate a solution based on IPSec for=20
> securing the
> >>>> shim6, you need to consider the fact that a global PKI=20
> is required
> >>>> for this.
> >>>>
> >>>> Hence, the alternative solution for securing the shim at
> >> this point
> >>>> would be IPSec+PKI, agree?
> >>>>
> >>>> regards, marcelo
> >>>>
> >>>>
> >>>>
> >>>>>   IPsec is deployed today with PKI.
> >>>>>
> >>>>
> >>>>
> >>>>> /jim
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: marcelo bagnulo braun [mailto:[email-masked]]
> >>>>>> Sent: Wednesday, July 19, 2006 8:04 AM
> >>>>>> To: Francis Dupont
> >>>>>> Cc: [email-masked]; Bound, Jim; Pekka Savola; Iljitsch=20
> van Beijnum
> >>>>>> Subject: Re: CGA Use with HBA in Shim6 IETF Meeting=20
> July 10, 2006
> >>>>>>
> >>>>>>
> >>>>>> El 19/07/2006, a las 14:38, Francis Dupont escribi=F3:
> >>>>>>
> >>>>>>> I can't see where Jim proposed to base the Shim6 security
> >>>>>> on IPsec...
> >>>>>>
> >>>>>> in message http://ops.ietf.org/lists/shim6/msg01511.html
> >>>>>>
> >>>>>> it is stated that:
> >>>>>>
> >>>>>> Suggestion is to simply embed ULIDs within the data
> >>>> payload with new
> >>>>>> option and secure all communications at least for now
> >> for IP layer
> >>>>>> communcatiions with IPsec encryption based on locator pair.
> >>>>>>
> >>>>>> meaning to use IPSec as an alternative to HBA security
> >>>>>>
> >>>>>>> (something which is known to require the impossible and
> >> even not
> >>>>>>> desirable global PKI :-)
> >>>>>>>
> >>>>>>
> >>>>>> exactly
> >>>>>>
> >>>>>> Regards, marcelo
> >>>>>>
> >>>>>>
> >>>>>>> Regards
> >>>>>>>
> >>>>>>> [email-masked]
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>>
> >>>
> >>
> >>
> >
>=20
>=20

Delivery-date: Wed, 19 Jul 2006 19:45:59 +0000
Cc: "Brian E Carpenter" <[email-masked]>, <[email-masked]>, "Joe Abley" <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: IPsec Issue Discussed for Shim6 at IETF Meeting July 10, 2006
Date: Wed, 19 Jul 2006 22:45:23 +0300
To: "Bound, Jim" <[email-masked]>

El 19/07/2006, a las 22:35, Bound, Jim escribi=F3:

> I was speaking of HA and MN in context of BU excahnge for HA=20
> notification.  The rest below is really the same debate as the thread=20=

> I will respond to I just sent.

we are exachanging so many emails that i am not sure i understand this=20=

reference... are you saying that:
- IPSec processing in the case of RO MIP and shim6 are similar
- IPSec processing in the case of MN-HA signalling (BT mode of MIP) is=20=

different and does not have the out of band consideration that the=20
previous two (shim and ro mode)?

if this is what you are saying, we agree

regards, marcelo

> thx
> /jim
>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On
>> Behalf Of marcelo bagnulo braun
>> Sent: Wednesday, July 19, 2006 3:14 PM
>> To: Bound, Jim
>> Cc: Brian E Carpenter; [email-masked]; Joe Abley
>> Subject: Re: IPsec Issue Discussed for Shim6 at IETF Meeting
>> July 10, 2006
>>
>>
>> El 19/07/2006, a las 19:59, Bound, Jim escribi=F3:
>>
>>>
>>>>
>>>> The shim6 spec does have some words about this, in
>> particular section
>>>> 1.6 states:
>>>>
>>>>     Layering AH and ESP above the multihoming shim means
>> that IPsec
>>>> can
>>>>     be made to be unaware of locator changes the same way that
>>>> transport
>>>>     protocols can be unaware.  Thus the IPsec security associations
>>>>     remain stable even though the locators are changing.
>>>> This means that
>>>>     the IP addresses specified in the selectors should be
>> the ULIDs.
>>>>
>>>> however, it would be possible to add additional detailed
>> description
>>>> about how would IPSec processing look like in a shimmed
>> environment
>>>> (whether in the base spec or in the applicability statement)
>>>
>>> The above is really not enough it needs to speak to the
>> actual IPsec
>>> processing and discuss the out-of-band signaling required.
>>>
>>
>> i am not sure i understand...
>>
>> a description of the IPSec processing is what i mentioned
>> above, so i guess we agree here
>>
>> in addition, you suggest to include the out of band
>> processing, but if i understand correctly this IS the shim6
>> protocol, since this is the way the alternative locators and
>> associated security information is conveyed... we could put
>> it explicitely...
>>
>>>>
>>>>>   That would help yes.  But, the home agent address is
>> secured with
>>>>> the mobile node too by IPsec.
>>>>
>>>> i was not cosnidering the communication with the HA but
>>>> directly with the CN using RO mode
>>>
>>> Same thing from the HA side as it is proxy to the MN.
>>>
>>
>> No, the HA is not involved in the data path when RO mode is used,
>>
>> in RO mode the data packet flow directly between the MN and
>> the CN, so
>> the two cases RO and BT mode are different. The point is that RO mode
>> requires similar out of band signaling and result in a IPSEc
>> processing
>> equal to the one of the shim6 protocol
>>
>>>>
>>>>>  Making this word change in the spec and having a
>>>> discussion would be
>>>>> progress for sure, and we can then at least discuss security
>>>>> ramifications.  If you go to my very first mail on this the first
>>>>> input is that the text discussing this part of shim6 is not clear
>>>>> fixing that is a priori for sure then we can go to next
>> steps.  But
>>>>> the MIPv6 case is not out of band signaling per se
>> because the home
>>>>> agent address was kept with the node when it roamed and did
>>>> not have
>>>>> to be securely negotiated after going mobile.  That is a different
>>>>> network security scenario and property than CGA in shim6.
>>>>>
>>>>
>>>> indeed the communication between the HA and the mobile node
>>>> is a different scenario, but the communication between the MN
>>>> and the CN in RO mode is exactly the same scenario than a
>>>> shim6 communication AFAICT and it uses the exact same type of
>>>> out-band signalling, agree?
>>>
>>> It is not exactly the same all cohesive security containment is
>>> rigorous on the MN as it owns its HA address.
>>
>> the point is how oes it proves to the CN that it owns the
>> HoA... using
>> IPSec? no, because, similarly to the shim6 case, in order to
>> use IPSec
>> for this you would need global PKI. So alternative methods (the so
>> called out of band signalling) are needed. The result in
>> terms of IPSec
>> processing is the same than in shim. Both MIP and shim lie below the
>> IPSec layer and the translate the locator of received packet to the
>> original identifiers/home address, so that the IPSec SA can
>> be searched
>> using the identifiers and not the locators used to route the packets.
>>
>>
>>
>>>   Much different than what we are saying here.  Also the CN
>> still can
>>> perform IPsec processing at the IP layer without popping up to code
>>> for a shim layer.
>>>
>>
>> I don't see why do you day this... MIP needs to restore the
>> HoA before
>> the IPSec processing exactly the same that in the shim case,
>> where the
>> shim needs to restore the ulids before IPSec processing. In
>> both cases
>> the security of the binding between the identifier and the
>> locators is
>> not based in IPSec but is this out of band security.
>>
>> Regards, marcelo
>>
>>
>>> thanks
>>> /jim
>>>>
>>>> regards, marcelo
>>>>
>>>>
>>>>> /jim
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: marcelo bagnulo braun [mailto:[email-masked]]
>>>>>> Sent: Wednesday, July 19, 2006 4:32 AM
>>>>>> To: Bound, Jim
>>>>>> Cc: Brian E Carpenter; [email-masked]; Joe Abley
>>>>>> Subject: Re: IPsec Issue Discussed for Shim6 at IETF
>>>> Meeting July 10,
>>>>>> 2006
>>>>>>
>>>>>> Hi Jim,
>>>>>>
>>>>>>
>>>>>> El 18/07/2006, a las 18:23, Bound, Jim escribi=F3:
>>>>>>
>>>>>>> Brian and Joe, (thanks).
>>>>>>>
>>>>>>> If ULID is both ID and Locator that is fine.  Here is more
>>>>>> on my issue
>>>>>>> and sorry for late response traveling and email is a pain.
>>>>>>>
>>>>>>> If when the packet is transmitted and the Locator is not
>>>>>> the ULID, AND
>>>>>>> the ULID is the SA to decrypt the packet is my concern.
>>>>>>>
>>>>>>> Here is why.
>>>>>>>
>>>>>>> First that means some form of out-of-band signaling was done to
>>>>>>> identify a Locator to a ULID so the decrypt can even
>>>>>> happen. This is
>>>>>>> out of scope for the IPsec architecture we clearly did
>>>> not support
>>>>>>> out-of-band singaling for IPsec all the way back to the
>>>>>> 1994 or 1995
>>>>>>> Danvers IETF meeting when we decided to move to IPsec.
>>>>>>>
>>>>>>> Second I am concerned about implementations that now assume
>>>>>> per IPsec
>>>>>>> that in fact the Locator is the SA in the arriving or
>>>>>> sending packet
>>>>>>> to another node.
>>>>>>>
>>>>>>> Does that help?
>>>>>>>
>>>>>>
>>>>>>
>>>>>> but isn't the case that there are existent protocols that
>>>> also use an
>>>>>> out of band signaling that you mention below the IPSec layer in a
>>>>>> similar fashion that the shim6 protocol (and i think there
>>>> are valid
>>>>>> reasons why to do that)
>>>>>>
>>>>>> Let's consider that case of Mobile IPv6 and in particular
>>>> the case of
>>>>>> RO mode
>>>>>>
>>>>>> Suppose that we have a node M that is communicating with a node C
>>>>>>
>>>>>> Suppose that node M has a stable address IPH and that node
>>>> C has an
>>>>>> address IPC
>>>>>>
>>>>>> Suppose that M and C have established and IPSec protected
>>>>>> communication using IPH and IPC (hence the IPSec SA
>>>> contains IPH and
>>>>>> IPC)
>>>>>>
>>>>>> Suppose now that node M (which is a mobile node running
>>>>>> MIPv6) moves and it gets a new address CoA
>>>>>>
>>>>>> Suppose that the communication between M and C is in route
>>>>>> optimization mode
>>>>>>
>>>>>> Consider the case of packet flowing from M to node C.
>>>>>> In this case, packets flowing from M to the mobile node C will be
>>>>>> carrying CoA in the src address field of the IPv6 header and they
>>>>>> will carry the HoA dst option containing the IPH address
>>>> In addition,
>>>>>> the packets carry the ESP/AH header.
>>>>>> Since the IPSec SA contains IPH (and not CoA) the IPH must be
>>>>>> restored by the MIPv6 layer before the processing.
>>>>>>
>>>>>> Actually, RFC3775 states in page 110 that:
>>>>>>
>>>>>>        If route optimization is in use, the mobile node
>>>> inserts a Home
>>>>>>        Address destination option into the packet, replacing the
>>>>>> Source
>>>>>>        Address in the packet's IP header with the care-of
>>>> address used
>>>>>>        with this correspondent node, as described in
>>>> Section 11.3.1.
>>>>>> The
>>>>>>        Destination Options header in which the Home Address
>>>>>> destination
>>>>>>        option is inserted MUST appear in the packet after
>>>> the routing
>>>>>>        header, if present, and before the IPsec (AH [5]
>> or ESP [6])
>>>>>>        header, so that the Home Address destination option is
>>>>>> processed
>>>>>>        by the destination node before the IPsec header is
>>>> processed.
>>>>>>
>>>>>> This basically means, that upon reception, MIPv6 will restore the
>>>>>> original IPH address before the IPSec processing, so that the
>>>>>> original addresses/identifers can be used to search the IPSec SA.
>>>>>>
>>>>>> As far as i can see this is exactly the same behaviour
>>>> that is being
>>>>>> proposed for the shim, or do you see any difference
>>>> between the case
>>>>>> of the shim6 and mipv6?
>>>>>>
>>>>>> Regards, marcelo
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Thanks
>>>>>>> /jim
>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Brian E Carpenter [mailto:[email-masked]]
>>>>>>>> Sent: Tuesday, July 18, 2006 11:04 AM
>>>>>>>> To: Joe Abley
>>>>>>>> Cc: Bound, Jim; [email-masked]
>>>>>>>> Subject: Re: IPsec Issue Discussed for Shim6 at IETF
>>>>>> Meeting July 10,
>>>>>>>> 2006
>>>>>>>>
>>>>>>>> Joe Abley wrote:
>>>>>>>>>
>>>>>>>>> On 18-Jul-2006, at 07:24, Brian E Carpenter wrote:
>>>>>>>>>
>>>>>>>>>> Sure, in my shim6 world the ULID is an initially
>> valid locator.
>>>>>>>>>> Of course, it may become invalid dynamically during the
>>>>>>>> course of a
>>>>>>>>>> session, but that will not invalidate the SA as far as
>>>> I can see.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Surely the ULID is static for the lifetime of a session,
>>>>>>>> regardless
>>>>>>>>> of what happens to the locator set?
>>>>>>>>
>>>>>>>> Exactly my point; but if the ULID ceases to work as a
>>>>>> locator, it no
>>>>>>>> longer has its initial duality as both an ID and a locator.
>>>>>>>> And I want to be sure than Jim doesn't see a problem in that.
>>>>>>>>
>>>>>>>>      Brian
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>>
>

Delivery-date: Wed, 19 Jul 2006 19:43:30 +0000
Cc: "Francis Dupont" <[email-masked]>, <[email-masked]>, "Pekka Savola" <[email-masked]>, "Iljitsch van Beijnum" <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006 
Date: Wed, 19 Jul 2006 22:43:00 +0300
To: "Bound, Jim" <[email-masked]>

El 19/07/2006, a las 22:30, Bound, Jim escribi=F3:

> I dont accept the threats in 4218 so that is a problem right there

we have identified the core issue i think, great!!

we have based the design of the shim6 security on the threats=20
identified on RFC4218, so if you don't agree with those, we need to=20
discuss those first and then move on to the security solutions (since=20
they are direct consequence of the threats described there)

proabably we should even also consider the threats of MIP described in=20=

RFC4225 since RFC4218 is heavily based on this one...

But good we are making progress (at least in identifying the=20
disagreement points)

regards, marcelo

> but I will do that but that is more than just a quick response on=20
> email and need to go do proper analysis.  I will respond to where we=20=

> disagree too later ok.  As I said email is not good for me now I keep=20=

> changing my location :--).
>
> thx
> /jim
>
>> -----Original Message-----
>> From: marcelo bagnulo braun [mailto:[email-masked]]
>> Sent: Wednesday, July 19, 2006 3:27 PM
>> To: Bound, Jim
>> Cc: Francis Dupont; [email-masked]; Pekka Savola; Iljitsch van Beijnum
>> Subject: Re: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006
>>
>>
>> El 19/07/2006, a las 20:10, Bound, Jim escribi=F3:
>>
>>> Global PKI is not required for certificates that can be done with
>>> pre-shared keys too or as we are doing with shim6 out-of-band
>>> signaling.  If any here believe IPsec will not be used end-to-end
>>> think again please it will.  Ipsec is totally possible and
>> I will not
>>> repeat my mail on enclaves for end-to-end PKI as that is a
>> deployment
>>> and systems integration implementation issue.
>>>
>>
>> ok at this point it seems to me that we may start to
>> repeating ourselves, so at least let's try to identify where
>> do we disagree...
>>
>> What i am saying is that:
>>
>> - In order to use IPSec to protect the shim6 protocol (in
>> particular for providing a secure binding between identifier
>> and locators), there are two options: a) we use certificates
>> issued by a global PKI are needed in all shim6 peers or b) we
>> have preshared keys in all shim6 nodes
>>
>> do you disagree with this statement?
>>
>> I assume you do
>>
>> if you disagree could you explain to me how would you protect
>> the shim6 protocol from the threats described in RFC4218?
>>
>> in particular could you explain to me how would you protect
>> from the following attack:
>>
>> Suppose that Alice and Bob work in the same office and that
>> Alice reads the local newspaper web page every morning at
>> www.localpress.com Now, suppose that tomorrow is Alice
>> birthday and since Bob has a crush on Alice, Bob wants to
>> make Alice believe that tomorrow local newspaper headline is
>> "Happy Birthday Alice".
>>
>> In order to do that, Bob's plan is to hijack any future
>> communication that Alice initiates from her machine to Bob's
>> laptop, so Bob can substitute the local newspaper web page by
>> his own fake happy birthday greetings home page.
>>
>> So, in the DNS www.localpress.com has a single IP address IPlp.
>>
>> To launch the attack, the night before, Bob creates a shim6
>> state in alice machine. In order to do that, Bob initiates
>> the shim6 context establishment exchange.
>>
>> The created context, has IPlp as ULID and it has IPB (i.e.
>> Bob's laptop
>> IP) as preferred locator.
>>
>> In order to keep the context alive, Bob sends periodic packets (e.g.
>> ping or UDP) to Alice machine. Note that the goal of these
>> packets is just to prevent the shim6 state at Alice machine
>> to be garbage collected, so there is no need to have a actual
>> application receiving those packets above the shim (i.e.
>> these packets can be perfectly discarded once they passed
>> above the shim, and they would still be fulfilling their goal
>> from the attack p.o.v.)
>>
>> The next morning (Alice birthday!!!) Alice arrives to the
>> office and she tries to connect to the local newspaper as
>> everyday. The only difference is that today, there is a shim6
>> state in Alice machine for IPlp.
>> Alice browser asks the resolver for www.localpress.com. the
>> resolver returns IPlp. The browser initiates a TCP connection
>> with IPlp, but the SYN packet is intercepted by the shim
>> layer (at Alice's machine) and the address is translated to
>> IPB. the result, the communication is redirected to Bob's
>> machine and Alice will be accessing Bob's web server while
>> she thinks that she is reaching the local newspaper web page
>>
>> Bob has managed to steal the local newspaper IP identity from
>> Alice p.o.v.
>>
>> This type of attack cannot be prevented by simply using
>> IPSec, because it is launched before the keys have been exchanged.
>>
>> In order to prevent these attacks, we need additional tools,
>> like global certificates, pre shared keys or crypto identities.
>>
>> reagrds, marcelo
>>
>>
>>
>>
>>
>>> thanks
>>> /jim
>>>
>>>> -----Original Message-----
>>>> From: marcelo bagnulo braun [mailto:[email-masked]]
>>>> Sent: Wednesday, July 19, 2006 11:32 AM
>>>> To: Bound, Jim
>>>> Cc: Francis Dupont; [email-masked]; Pekka Savola; Iljitsch
>> van Beijnum
>>>> Subject: Re: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006
>>>>
>>>>
>>>> El 19/07/2006, a las 16:55, Bound, Jim escribi=F3:
>>>>
>>>>> I was assuming the node regardless will use IPsec as
>>>> required.  Thus
>>>>> it really is not shime6 concern.  But I do not believe no
>>>> one will not
>>>>> deploy IPsec because of PKI that is simply not true.
>>>>
>>>> i agree with this
>>>>
>>>>
>>>> but the problem is that if you want to use IPSEc to secure
>> the shim,
>>>> you need to use certificates, if not the security is not
>> acceptable.
>>>>
>>>> You need to provide a secure binding between the identifer and the
>>>> locators. IPSec wihtout certificates does not provides
>> this feature.
>>>> If you want to use IPSec to secure the
>>>> shim6 protocol, you need the certificates hence you need
>> the global
>>>> PKI.
>>>>
>>>> So in order to evaluate a solution based on IPSec for securing the
>>>> shim6, you need to consider the fact that a global PKI is required
>>>> for this.
>>>>
>>>> Hence, the alternative solution for securing the shim at
>> this point
>>>> would be IPSec+PKI, agree?
>>>>
>>>> regards, marcelo
>>>>
>>>>
>>>>
>>>>>   IPsec is deployed today with PKI.
>>>>>
>>>>
>>>>
>>>>> /jim
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: marcelo bagnulo braun [mailto:[email-masked]]
>>>>>> Sent: Wednesday, July 19, 2006 8:04 AM
>>>>>> To: Francis Dupont
>>>>>> Cc: [email-masked]; Bound, Jim; Pekka Savola; Iljitsch van Beijnum
>>>>>> Subject: Re: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006
>>>>>>
>>>>>>
>>>>>> El 19/07/2006, a las 14:38, Francis Dupont escribi=F3:
>>>>>>
>>>>>>> I can't see where Jim proposed to base the Shim6 security
>>>>>> on IPsec...
>>>>>>
>>>>>> in message http://ops.ietf.org/lists/shim6/msg01511.html
>>>>>>
>>>>>> it is stated that:
>>>>>>
>>>>>> Suggestion is to simply embed ULIDs within the data
>>>> payload with new
>>>>>> option and secure all communications at least for now
>> for IP layer
>>>>>> communcatiions with IPsec encryption based on locator pair.
>>>>>>
>>>>>> meaning to use IPSec as an alternative to HBA security
>>>>>>
>>>>>>> (something which is known to require the impossible and
>> even not
>>>>>>> desirable global PKI :-)
>>>>>>>
>>>>>>
>>>>>> exactly
>>>>>>
>>>>>> Regards, marcelo
>>>>>>
>>>>>>
>>>>>>> Regards
>>>>>>>
>>>>>>> [email-masked]
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>

Delivery-date: Wed, 19 Jul 2006 19:40:05 +0000
Cc: <[email-masked]>, "Pekka Savola" <[email-masked]>, "Iljitsch van Beijnum" <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006
Date: Wed, 19 Jul 2006 22:39:18 +0300
To: "Bound, Jim" <[email-masked]>

El 19/07/2006, a las 22:28, Bound, Jim escribi=F3:

> You and I are disagreeing on where the market is going to go=20
> technically.  I don't think we will compromise or that we can=20
> converge.  So trying to save a lot of email here.
>
> What we need the working group to discuss now is how much and when do=20=

> we worry about the market doing our engineering/scientist work to=20
> identify a protocol.

exactly

i think we (you and me) send enough emails about this point, the point=20=

is whether the wg thinks that basing the shim6 security in widespread=20
availability of certificates issued by a global PKI is acceptable or=20
not

comments form the wg?

regards, marcelo

>  I could provide quite a few examples from good IETF work that is RFC=20=

> that might never be deployed in production.  Also as I said SHIM6 will=20=

> not be pervasive for at least 5 years in the market and we have time=20=

> to think there is no rush here at all.
>
> /jim
>
>> -----Original Message-----
>> From: marcelo bagnulo braun [mailto:[email-masked]]
>> Sent: Wednesday, July 19, 2006 3:20 PM
>> To: Bound, Jim
>> Cc: [email-masked]; Pekka Savola; Iljitsch van Beijnum
>> Subject: Re: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006
>>
>>
>> El 19/07/2006, a las 20:01, Bound, Jim escribi=F3:
>>
>>> I don't agree it is huge deployment obstacle,
>>
>> i guess e need to agree to disagree here.
>>
>> I certainly think that requiring certificates issued by a
>> global PKIto all the nodes running shim6 is a huge deployment =
obstacle
>>
>> what do others think? does it seems an acceptable apporach to base
>> shim6 security in the availability of certificates issue by a
>> global PKI in all shim6 peers?
>>
>>>  but if it was it is not our issue here in IETF WG.
>>
>> yes it is. because if we propose a protocol that relies on
>> tools that require massive dpeloyment cost, then the protocol
>> is likely to not be deployed so it is a poor solution. As
>> engineers, we need to provide deployable solutions i.e
>> solutions with a reduced deployment costs (in other words,
>> the deployment cost is a factor to be taken into account when
>> evaluating different solutions)
>>
>>
>>>   Biometric, Smartcards, LinkIDs can all be preshared and
>> associated
>>> with enclaves per the other thread on end-to-end PKI.
>>>
>>
>> i am not sure what do you mean here, but i am afraid that of
>> all these abve, only preshared secret and global pki could be
>> used to secure the shim... i don't think biometrics or
>> smarcards can help here..
>>
>>
>> regards, marcelo
>>
>>
>>
>>> /jim
>>>
>>>> -----Original Message-----
>>>> From: marcelo bagnulo braun [mailto:[email-masked]]
>>>> Sent: Wednesday, July 19, 2006 11:28 AM
>>>> To: Bound, Jim
>>>> Cc: [email-masked]; Pekka Savola; Iljitsch van Beijnum
>>>> Subject: Re: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006
>>>>
>>>>
>>>> El 19/07/2006, a las 16:52, Bound, Jim escribi=F3:
>>>>
>>>>> Hi Marcello,
>>>>>
>>>>> Well my view is specs cannot make assumptions about market
>>>> deployment
>>>>> the question first to ask is would IPsec work.
>>>>
>>>> i agree with this
>>>>
>>>> however, it is imho completelly valid to evaluate
>> different solutions
>>>> based on their deployment costs.
>>>>
>>>> A solution based on IPSec requires either pre shared keys
>> between all
>>>> the nodes in the internet or certificates for all the nodes of the
>>>> internet. This is a huge deployment obstacle. So this
>> solution does
>>>> present this problem and needs to be taken into account when
>>>> evaluating different solutions. A solution that does not requires
>>>> this would require less deployment effort. Of course this
>> is not the
>>>> only (or even most important) consideration when evaluating
>>>> alternative solutions but it is indeed an important
>> element imho, do
>>>> you agree?
>>>>
>>>> regards, marcelo
>>>>
>>>>
>>>>>   None of us have a crystal ball and our engineering work here is
>>>>> usually focused on the protocol behavior and that it does
>>>> no harm and
>>>>> does not cause interoperability problems.
>>>>>
>>>>> /jim
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: marcelo bagnulo braun [mailto:[email-masked]]
>>>>>> Sent: Wednesday, July 19, 2006 5:57 AM
>>>>>> To: Bound, Jim
>>>>>> Cc: [email-masked]; Pekka Savola; Iljitsch van Beijnum
>>>>>> Subject: Re: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006
>>>>>>
>>>>>> Hi Jim,
>>>>>>
>>>>>>
>>>>>> El 11/07/2006, a las 17:25, Bound, Jim escribi=F3:
>>>>>>
>>>>>>> I see this point.  Clearly public or pre-shared PKI has to
>>>>>> exist yes.
>>>>>>> But enclaves of network users will have this association is the
>>>>>>> assumption.  So if we are not in some enclave we would
>>>> need to join
>>>>>>> one to send each other files via IPsec with encrypt.  The
>>>>>> enclaves are
>>>>>>> being built now.
>>>>>>
>>>>>>
>>>>>> As i understand it, the only way to make the shim6
>>>> security based on
>>>>>> IPSec is to assume that a global PKI is deployed,
>> including client
>>>>>> certificates (i.e. not only server
>>>>>> certificates) so that it is possible to secure any-to-any
>>>>>> communication.
>>>>>>
>>>>>>  =46rom what i understand such global pki is not in place
>> yet and it
>>>>>> doesn't looks like it will be anytime soon if ever.
>>>>>>
>>>>>> So, i really don't think it is reasonable to build the
>> security on
>>>>>> the
>>>>>> shim6 relying on such global pki deployment
>>>>>>
>>>>>> does anybody think that it would be acceptable to build the
>>>>>> shim6 security based on the  assumption of a global PKI
>> deployment?
>>>>>>
>>>>>> Regards, marcelo
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> Sorry I missed your point.
>>>>>>>
>>>>>>> /jim
>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Iljitsch van Beijnum [mailto:[email-masked]]
>>>>>>>> Sent: Tuesday, July 11, 2006 10:19 AM
>>>>>>>> To: Bound, Jim
>>>>>>>> Cc: Pekka Savola; [email-masked]
>>>>>>>> Subject: Re: CGA Use with HBA in Shim6 IETF Meeting
>> July 10, 2006
>>>>>>>>
>>>>>>>> On 11-jul-2006, at 10:13, Bound, Jim wrote:
>>>>>>>>
>>>>>>>>> IPsec is deployed end-to-end for v4 and v6 in production
>>>>>> not sure I
>>>>>>>>> agree no one knows how to do this and I think I
>>>>>> misunderstood your
>>>>>>>>> statement below?  Thanks.
>>>>>>>>
>>>>>>>> So if I want to send you a file and I want to encrypt it
>>>>>> with IPsec,
>>>>>>>> how do I do that, without making special arrangements first?
>>>>>>>>
>>>>>>>> IPsec is only used for VPN tunnels in practice today.
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>

Delivery-date: Wed, 19 Jul 2006 19:36:51 +0000
Content-class: urn:content-classes:message
Subject: RE: IPsec Issue Discussed for Shim6 at IETF Meeting July 10, 2006
Date: Wed, 19 Jul 2006 15:35:53 -0400
From: "Bound, Jim" <[email-masked]>
To: "marcelo bagnulo braun" <[email-masked]>
Cc: "Brian E Carpenter" <[email-masked]>, <[email-masked]>, "Joe Abley" <[email-masked]>

I was speaking of HA and MN in context of BU excahnge for HA =
notification.  The rest below is really the same debate as the thread I =
will respond to I just sent.
thx
/jim=20

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On=20
> Behalf Of marcelo bagnulo braun
> Sent: Wednesday, July 19, 2006 3:14 PM
> To: Bound, Jim
> Cc: Brian E Carpenter; [email-masked]; Joe Abley
> Subject: Re: IPsec Issue Discussed for Shim6 at IETF Meeting=20
> July 10, 2006
>=20
>=20
> El 19/07/2006, a las 19:59, Bound, Jim escribi=F3:
>=20
> >
> >>
> >> The shim6 spec does have some words about this, in=20
> particular section
> >> 1.6 states:
> >>
> >>     Layering AH and ESP above the multihoming shim means=20
> that IPsec=20
> >> can
> >>     be made to be unaware of locator changes the same way that=20
> >> transport
> >>     protocols can be unaware.  Thus the IPsec security associations
> >>     remain stable even though the locators are changing.
> >> This means that
> >>     the IP addresses specified in the selectors should be=20
> the ULIDs.
> >>
> >> however, it would be possible to add additional detailed=20
> description=20
> >> about how would IPSec processing look like in a shimmed=20
> environment=20
> >> (whether in the base spec or in the applicability statement)
> >
> > The above is really not enough it needs to speak to the=20
> actual IPsec=20
> > processing and discuss the out-of-band signaling required.
> >
>=20
> i am not sure i understand...
>=20
> a description of the IPSec processing is what i mentioned=20
> above, so i guess we agree here
>=20
> in addition, you suggest to include the out of band=20
> processing, but if i understand correctly this IS the shim6=20
> protocol, since this is the way the alternative locators and=20
> associated security information is conveyed... we could put=20
> it explicitely...
>=20
> >>
> >>>   That would help yes.  But, the home agent address is=20
> secured with
> >>> the mobile node too by IPsec.
> >>
> >> i was not cosnidering the communication with the HA but
> >> directly with the CN using RO mode
> >
> > Same thing from the HA side as it is proxy to the MN.
> >
>=20
> No, the HA is not involved in the data path when RO mode is used,
>=20
> in RO mode the data packet flow directly between the MN and=20
> the CN, so=20
> the two cases RO and BT mode are different. The point is that RO mode=20
> requires similar out of band signaling and result in a IPSEc=20
> processing=20
> equal to the one of the shim6 protocol
>=20
> >>
> >>>  Making this word change in the spec and having a
> >> discussion would be
> >>> progress for sure, and we can then at least discuss security
> >>> ramifications.  If you go to my very first mail on this the first
> >>> input is that the text discussing this part of shim6 is not clear
> >>> fixing that is a priori for sure then we can go to next=20
> steps.  But
> >>> the MIPv6 case is not out of band signaling per se=20
> because the home
> >>> agent address was kept with the node when it roamed and did
> >> not have
> >>> to be securely negotiated after going mobile.  That is a different
> >>> network security scenario and property than CGA in shim6.
> >>>
> >>
> >> indeed the communication between the HA and the mobile node
> >> is a different scenario, but the communication between the MN
> >> and the CN in RO mode is exactly the same scenario than a
> >> shim6 communication AFAICT and it uses the exact same type of
> >> out-band signalling, agree?
> >
> > It is not exactly the same all cohesive security containment is=20
> > rigorous on the MN as it owns its HA address.
>=20
> the point is how oes it proves to the CN that it owns the=20
> HoA... using=20
> IPSec? no, because, similarly to the shim6 case, in order to=20
> use IPSec=20
> for this you would need global PKI. So alternative methods (the so=20
> called out of band signalling) are needed. The result in=20
> terms of IPSec=20
> processing is the same than in shim. Both MIP and shim lie below the=20
> IPSec layer and the translate the locator of received packet to the=20
> original identifiers/home address, so that the IPSec SA can=20
> be searched=20
> using the identifiers and not the locators used to route the packets.
>=20
>=20
>=20
> >   Much different than what we are saying here.  Also the CN=20
> still can=20
> > perform IPsec processing at the IP layer without popping up to code=20
> > for a shim layer.
> >
>=20
> I don't see why do you day this... MIP needs to restore the=20
> HoA before=20
> the IPSec processing exactly the same that in the shim case,=20
> where the=20
> shim needs to restore the ulids before IPSec processing. In=20
> both cases=20
> the security of the binding between the identifier and the=20
> locators is=20
> not based in IPSec but is this out of band security.
>=20
> Regards, marcelo
>=20
>=20
> > thanks
> > /jim
> >>
> >> regards, marcelo
> >>
> >>
> >>> /jim
> >>>
> >>>> -----Original Message-----
> >>>> From: marcelo bagnulo braun [mailto:[email-masked]]
> >>>> Sent: Wednesday, July 19, 2006 4:32 AM
> >>>> To: Bound, Jim
> >>>> Cc: Brian E Carpenter; [email-masked]; Joe Abley
> >>>> Subject: Re: IPsec Issue Discussed for Shim6 at IETF
> >> Meeting July 10,
> >>>> 2006
> >>>>
> >>>> Hi Jim,
> >>>>
> >>>>
> >>>> El 18/07/2006, a las 18:23, Bound, Jim escribi=F3:
> >>>>
> >>>>> Brian and Joe, (thanks).
> >>>>>
> >>>>> If ULID is both ID and Locator that is fine.  Here is more
> >>>> on my issue
> >>>>> and sorry for late response traveling and email is a pain.
> >>>>>
> >>>>> If when the packet is transmitted and the Locator is not
> >>>> the ULID, AND
> >>>>> the ULID is the SA to decrypt the packet is my concern.
> >>>>>
> >>>>> Here is why.
> >>>>>
> >>>>> First that means some form of out-of-band signaling was done to
> >>>>> identify a Locator to a ULID so the decrypt can even
> >>>> happen. This is
> >>>>> out of scope for the IPsec architecture we clearly did
> >> not support
> >>>>> out-of-band singaling for IPsec all the way back to the
> >>>> 1994 or 1995
> >>>>> Danvers IETF meeting when we decided to move to IPsec.
> >>>>>
> >>>>> Second I am concerned about implementations that now assume
> >>>> per IPsec
> >>>>> that in fact the Locator is the SA in the arriving or
> >>>> sending packet
> >>>>> to another node.
> >>>>>
> >>>>> Does that help?
> >>>>>
> >>>>
> >>>>
> >>>> but isn't the case that there are existent protocols that
> >> also use an
> >>>> out of band signaling that you mention below the IPSec layer in a
> >>>> similar fashion that the shim6 protocol (and i think there
> >> are valid
> >>>> reasons why to do that)
> >>>>
> >>>> Let's consider that case of Mobile IPv6 and in particular
> >> the case of
> >>>> RO mode
> >>>>
> >>>> Suppose that we have a node M that is communicating with a node C
> >>>>
> >>>> Suppose that node M has a stable address IPH and that node
> >> C has an
> >>>> address IPC
> >>>>
> >>>> Suppose that M and C have established and IPSec protected
> >>>> communication using IPH and IPC (hence the IPSec SA
> >> contains IPH and
> >>>> IPC)
> >>>>
> >>>> Suppose now that node M (which is a mobile node running
> >>>> MIPv6) moves and it gets a new address CoA
> >>>>
> >>>> Suppose that the communication between M and C is in route
> >>>> optimization mode
> >>>>
> >>>> Consider the case of packet flowing from M to node C.
> >>>> In this case, packets flowing from M to the mobile node C will be
> >>>> carrying CoA in the src address field of the IPv6 header and they
> >>>> will carry the HoA dst option containing the IPH address
> >> In addition,
> >>>> the packets carry the ESP/AH header.
> >>>> Since the IPSec SA contains IPH (and not CoA) the IPH must be
> >>>> restored by the MIPv6 layer before the processing.
> >>>>
> >>>> Actually, RFC3775 states in page 110 that:
> >>>>
> >>>>        If route optimization is in use, the mobile node
> >> inserts a Home
> >>>>        Address destination option into the packet, replacing the
> >>>> Source
> >>>>        Address in the packet's IP header with the care-of
> >> address used
> >>>>        with this correspondent node, as described in
> >> Section 11.3.1.
> >>>> The
> >>>>        Destination Options header in which the Home Address
> >>>> destination
> >>>>        option is inserted MUST appear in the packet after
> >> the routing
> >>>>        header, if present, and before the IPsec (AH [5]=20
> or ESP [6])
> >>>>        header, so that the Home Address destination option is
> >>>> processed
> >>>>        by the destination node before the IPsec header is
> >> processed.
> >>>>
> >>>> This basically means, that upon reception, MIPv6 will restore the
> >>>> original IPH address before the IPSec processing, so that the
> >>>> original addresses/identifers can be used to search the IPSec SA.
> >>>>
> >>>> As far as i can see this is exactly the same behaviour
> >> that is being
> >>>> proposed for the shim, or do you see any difference
> >> between the case
> >>>> of the shim6 and mipv6?
> >>>>
> >>>> Regards, marcelo
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>> Thanks
> >>>>> /jim
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: Brian E Carpenter [mailto:[email-masked]]
> >>>>>> Sent: Tuesday, July 18, 2006 11:04 AM
> >>>>>> To: Joe Abley
> >>>>>> Cc: Bound, Jim; [email-masked]
> >>>>>> Subject: Re: IPsec Issue Discussed for Shim6 at IETF
> >>>> Meeting July 10,
> >>>>>> 2006
> >>>>>>
> >>>>>> Joe Abley wrote:
> >>>>>>>
> >>>>>>> On 18-Jul-2006, at 07:24, Brian E Carpenter wrote:
> >>>>>>>
> >>>>>>>> Sure, in my shim6 world the ULID is an initially=20
> valid locator.
> >>>>>>>> Of course, it may become invalid dynamically during the
> >>>>>> course of a
> >>>>>>>> session, but that will not invalidate the SA as far as
> >> I can see.
> >>>>>>>
> >>>>>>>
> >>>>>>> Surely the ULID is static for the lifetime of a session,
> >>>>>> regardless
> >>>>>>> of what happens to the locator set?
> >>>>>>
> >>>>>> Exactly my point; but if the ULID ceases to work as a
> >>>> locator, it no
> >>>>>> longer has its initial duality as both an ID and a locator.
> >>>>>> And I want to be sure than Jim doesn't see a problem in that.
> >>>>>>
> >>>>>>      Brian
> >>>>>>
> >>>>>
> >>>>
> >>>>
> >>>
> >>
> >>
> >
>=20
>=20
>=20

Delivery-date: Wed, 19 Jul 2006 19:30:39 +0000
Content-class: urn:content-classes:message
Subject: RE: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006 
Date: Wed, 19 Jul 2006 15:30:04 -0400
From: "Bound, Jim" <[email-masked]>
To: "marcelo bagnulo braun" <[email-masked]>
Cc: "Francis Dupont" <[email-masked]>, <[email-masked]>, "Pekka Savola" <[email-masked]>, "Iljitsch van Beijnum" <[email-masked]>

I dont accept the threats in 4218 so that is a problem right there but I =
will do that but that is more than just a quick response on email and =
need to go do proper analysis.  I will respond to where we disagree too =
later ok.  As I said email is not good for me now I keep changing my =
location :--).

thx
/jim=20

> -----Original Message-----
> From: marcelo bagnulo braun [mailto:[email-masked]]=20
> Sent: Wednesday, July 19, 2006 3:27 PM
> To: Bound, Jim
> Cc: Francis Dupont; [email-masked]; Pekka Savola; Iljitsch van Beijnum
> Subject: Re: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006=20
>=20
>=20
> El 19/07/2006, a las 20:10, Bound, Jim escribi=F3:
>=20
> > Global PKI is not required for certificates that can be done with=20
> > pre-shared keys too or as we are doing with shim6 out-of-band=20
> > signaling.  If any here believe IPsec will not be used end-to-end=20
> > think again please it will.  Ipsec is totally possible and=20
> I will not=20
> > repeat my mail on enclaves for end-to-end PKI as that is a=20
> deployment=20
> > and systems integration implementation issue.
> >
>=20
> ok at this point it seems to me that we may start to=20
> repeating ourselves, so at least let's try to identify where=20
> do we disagree...
>=20
> What i am saying is that:
>=20
> - In order to use IPSec to protect the shim6 protocol (in=20
> particular for providing a secure binding between identifier=20
> and locators), there are two options: a) we use certificates=20
> issued by a global PKI are needed in all shim6 peers or b) we=20
> have preshared keys in all shim6 nodes
>=20
> do you disagree with this statement?
>=20
> I assume you do
>=20
> if you disagree could you explain to me how would you protect=20
> the shim6 protocol from the threats described in RFC4218?
>=20
> in particular could you explain to me how would you protect=20
> from the following attack:
>=20
> Suppose that Alice and Bob work in the same office and that=20
> Alice reads the local newspaper web page every morning at=20
> www.localpress.com Now, suppose that tomorrow is Alice=20
> birthday and since Bob has a crush on Alice, Bob wants to=20
> make Alice believe that tomorrow local newspaper headline is=20
> "Happy Birthday Alice".
>=20
> In order to do that, Bob's plan is to hijack any future=20
> communication that Alice initiates from her machine to Bob's=20
> laptop, so Bob can substitute the local newspaper web page by=20
> his own fake happy birthday greetings home page.
>=20
> So, in the DNS www.localpress.com has a single IP address IPlp.
>=20
> To launch the attack, the night before, Bob creates a shim6=20
> state in alice machine. In order to do that, Bob initiates=20
> the shim6 context establishment exchange.
>=20
> The created context, has IPlp as ULID and it has IPB (i.e.=20
> Bob's laptop
> IP) as preferred locator.
>=20
> In order to keep the context alive, Bob sends periodic packets (e.g.=20
> ping or UDP) to Alice machine. Note that the goal of these=20
> packets is just to prevent the shim6 state at Alice machine=20
> to be garbage collected, so there is no need to have a actual=20
> application receiving those packets above the shim (i.e.=20
> these packets can be perfectly discarded once they passed=20
> above the shim, and they would still be fulfilling their goal=20
> from the attack p.o.v.)
>=20
> The next morning (Alice birthday!!!) Alice arrives to the=20
> office and she tries to connect to the local newspaper as=20
> everyday. The only difference is that today, there is a shim6=20
> state in Alice machine for IPlp.
> Alice browser asks the resolver for www.localpress.com. the=20
> resolver returns IPlp. The browser initiates a TCP connection=20
> with IPlp, but the SYN packet is intercepted by the shim=20
> layer (at Alice's machine) and the address is translated to=20
> IPB. the result, the communication is redirected to Bob's=20
> machine and Alice will be accessing Bob's web server while=20
> she thinks that she is reaching the local newspaper web page
>=20
> Bob has managed to steal the local newspaper IP identity from=20
> Alice p.o.v.
>=20
> This type of attack cannot be prevented by simply using=20
> IPSec, because it is launched before the keys have been exchanged.
>=20
> In order to prevent these attacks, we need additional tools,=20
> like global certificates, pre shared keys or crypto identities.
>=20
> reagrds, marcelo
>=20
>=20
>=20
>=20
>=20
> > thanks
> > /jim
> >
> >> -----Original Message-----
> >> From: marcelo bagnulo braun [mailto:[email-masked]]
> >> Sent: Wednesday, July 19, 2006 11:32 AM
> >> To: Bound, Jim
> >> Cc: Francis Dupont; [email-masked]; Pekka Savola; Iljitsch=20
> van Beijnum
> >> Subject: Re: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006
> >>
> >>
> >> El 19/07/2006, a las 16:55, Bound, Jim escribi=F3:
> >>
> >>> I was assuming the node regardless will use IPsec as
> >> required.  Thus
> >>> it really is not shime6 concern.  But I do not believe no
> >> one will not
> >>> deploy IPsec because of PKI that is simply not true.
> >>
> >> i agree with this
> >>
> >>
> >> but the problem is that if you want to use IPSEc to secure=20
> the shim,=20
> >> you need to use certificates, if not the security is not=20
> acceptable.
> >>
> >> You need to provide a secure binding between the identifer and the=20
> >> locators. IPSec wihtout certificates does not provides=20
> this feature.=20
> >> If you want to use IPSec to secure the
> >> shim6 protocol, you need the certificates hence you need=20
> the global=20
> >> PKI.
> >>
> >> So in order to evaluate a solution based on IPSec for securing the=20
> >> shim6, you need to consider the fact that a global PKI is required=20
> >> for this.
> >>
> >> Hence, the alternative solution for securing the shim at=20
> this point=20
> >> would be IPSec+PKI, agree?
> >>
> >> regards, marcelo
> >>
> >>
> >>
> >>>   IPsec is deployed today with PKI.
> >>>
> >>
> >>
> >>> /jim
> >>>
> >>>> -----Original Message-----
> >>>> From: marcelo bagnulo braun [mailto:[email-masked]]
> >>>> Sent: Wednesday, July 19, 2006 8:04 AM
> >>>> To: Francis Dupont
> >>>> Cc: [email-masked]; Bound, Jim; Pekka Savola; Iljitsch van Beijnum
> >>>> Subject: Re: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006
> >>>>
> >>>>
> >>>> El 19/07/2006, a las 14:38, Francis Dupont escribi=F3:
> >>>>
> >>>>> I can't see where Jim proposed to base the Shim6 security
> >>>> on IPsec...
> >>>>
> >>>> in message http://ops.ietf.org/lists/shim6/msg01511.html
> >>>>
> >>>> it is stated that:
> >>>>
> >>>> Suggestion is to simply embed ULIDs within the data
> >> payload with new
> >>>> option and secure all communications at least for now=20
> for IP layer=20
> >>>> communcatiions with IPsec encryption based on locator pair.
> >>>>
> >>>> meaning to use IPSec as an alternative to HBA security
> >>>>
> >>>>> (something which is known to require the impossible and=20
> even not=20
> >>>>> desirable global PKI :-)
> >>>>>
> >>>>
> >>>> exactly
> >>>>
> >>>> Regards, marcelo
> >>>>
> >>>>
> >>>>> Regards
> >>>>>
> >>>>> [email-masked]
> >>>>>
> >>>>
> >>>>
> >>>
> >>
> >>
> >
>=20
>=20

Delivery-date: Wed, 19 Jul 2006 19:29:32 +0000
Content-class: urn:content-classes:message
Subject: RE: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006
Date: Wed, 19 Jul 2006 15:28:13 -0400
From: "Bound, Jim" <[email-masked]>
To: "marcelo bagnulo braun" <[email-masked]>
Cc: <[email-masked]>, "Pekka Savola" <[email-masked]>, "Iljitsch van Beijnum" <[email-masked]>

You and I are disagreeing on where the market is going to go =
technically.  I don't think we will compromise or that we can converge.  =
So trying to save a lot of email here.

What we need the working group to discuss now is how much and when do we =
worry about the market doing our engineering/scientist work to identify =
a protocol.  I could provide quite a few examples from good IETF work =
that is RFC that might never be deployed in production.  Also as I said =
SHIM6 will not be pervasive for at least 5 years in the market and we =
have time to think there is no rush here at all. =20

/jim=20

> -----Original Message-----
> From: marcelo bagnulo braun [mailto:[email-masked]]=20
> Sent: Wednesday, July 19, 2006 3:20 PM
> To: Bound, Jim
> Cc: [email-masked]; Pekka Savola; Iljitsch van Beijnum
> Subject: Re: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006
>=20
>=20
> El 19/07/2006, a las 20:01, Bound, Jim escribi=F3:
>=20
> > I don't agree it is huge deployment obstacle,
>=20
> i guess e need to agree to disagree here.
>=20
> I certainly think that requiring certificates issued by a=20
> global PKIto all the nodes running shim6 is a huge deployment obstacle
>=20
> what do others think? does it seems an acceptable apporach to base
> shim6 security in the availability of certificates issue by a=20
> global PKI in all shim6 peers?
>=20
> >  but if it was it is not our issue here in IETF WG.
>=20
> yes it is. because if we propose a protocol that relies on=20
> tools that require massive dpeloyment cost, then the protocol=20
> is likely to not be deployed so it is a poor solution. As=20
> engineers, we need to provide deployable solutions i.e=20
> solutions with a reduced deployment costs (in other words,=20
> the deployment cost is a factor to be taken into account when=20
> evaluating different solutions)
>=20
>=20
> >   Biometric, Smartcards, LinkIDs can all be preshared and=20
> associated=20
> > with enclaves per the other thread on end-to-end PKI.
> >
>=20
> i am not sure what do you mean here, but i am afraid that of=20
> all these abve, only preshared secret and global pki could be=20
> used to secure the shim... i don't think biometrics or=20
> smarcards can help here..
>=20
>=20
> regards, marcelo
>=20
>=20
>=20
> > /jim
> >
> >> -----Original Message-----
> >> From: marcelo bagnulo braun [mailto:[email-masked]]
> >> Sent: Wednesday, July 19, 2006 11:28 AM
> >> To: Bound, Jim
> >> Cc: [email-masked]; Pekka Savola; Iljitsch van Beijnum
> >> Subject: Re: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006
> >>
> >>
> >> El 19/07/2006, a las 16:52, Bound, Jim escribi=F3:
> >>
> >>> Hi Marcello,
> >>>
> >>> Well my view is specs cannot make assumptions about market
> >> deployment
> >>> the question first to ask is would IPsec work.
> >>
> >> i agree with this
> >>
> >> however, it is imho completelly valid to evaluate=20
> different solutions=20
> >> based on their deployment costs.
> >>
> >> A solution based on IPSec requires either pre shared keys=20
> between all=20
> >> the nodes in the internet or certificates for all the nodes of the=20
> >> internet. This is a huge deployment obstacle. So this=20
> solution does=20
> >> present this problem and needs to be taken into account when=20
> >> evaluating different solutions. A solution that does not requires=20
> >> this would require less deployment effort. Of course this=20
> is not the=20
> >> only (or even most important) consideration when evaluating=20
> >> alternative solutions but it is indeed an important=20
> element imho, do=20
> >> you agree?
> >>
> >> regards, marcelo
> >>
> >>
> >>>   None of us have a crystal ball and our engineering work here is=20
> >>> usually focused on the protocol behavior and that it does
> >> no harm and
> >>> does not cause interoperability problems.
> >>>
> >>> /jim
> >>>
> >>>> -----Original Message-----
> >>>> From: marcelo bagnulo braun [mailto:[email-masked]]
> >>>> Sent: Wednesday, July 19, 2006 5:57 AM
> >>>> To: Bound, Jim
> >>>> Cc: [email-masked]; Pekka Savola; Iljitsch van Beijnum
> >>>> Subject: Re: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006
> >>>>
> >>>> Hi Jim,
> >>>>
> >>>>
> >>>> El 11/07/2006, a las 17:25, Bound, Jim escribi=F3:
> >>>>
> >>>>> I see this point.  Clearly public or pre-shared PKI has to
> >>>> exist yes.
> >>>>> But enclaves of network users will have this association is the=20
> >>>>> assumption.  So if we are not in some enclave we would
> >> need to join
> >>>>> one to send each other files via IPsec with encrypt.  The
> >>>> enclaves are
> >>>>> being built now.
> >>>>
> >>>>
> >>>> As i understand it, the only way to make the shim6
> >> security based on
> >>>> IPSec is to assume that a global PKI is deployed,=20
> including client=20
> >>>> certificates (i.e. not only server
> >>>> certificates) so that it is possible to secure any-to-any=20
> >>>> communication.
> >>>>
> >>>>  From what i understand such global pki is not in place=20
> yet and it=20
> >>>> doesn't looks like it will be anytime soon if ever.
> >>>>
> >>>> So, i really don't think it is reasonable to build the=20
> security on=20
> >>>> the
> >>>> shim6 relying on such global pki deployment
> >>>>
> >>>> does anybody think that it would be acceptable to build the
> >>>> shim6 security based on the  assumption of a global PKI=20
> deployment?
> >>>>
> >>>> Regards, marcelo
> >>>>
> >>>>
> >>>>>
> >>>>> Sorry I missed your point.
> >>>>>
> >>>>> /jim
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: Iljitsch van Beijnum [mailto:[email-masked]]
> >>>>>> Sent: Tuesday, July 11, 2006 10:19 AM
> >>>>>> To: Bound, Jim
> >>>>>> Cc: Pekka Savola; [email-masked]
> >>>>>> Subject: Re: CGA Use with HBA in Shim6 IETF Meeting=20
> July 10, 2006
> >>>>>>
> >>>>>> On 11-jul-2006, at 10:13, Bound, Jim wrote:
> >>>>>>
> >>>>>>> IPsec is deployed end-to-end for v4 and v6 in production
> >>>> not sure I
> >>>>>>> agree no one knows how to do this and I think I
> >>>> misunderstood your
> >>>>>>> statement below?  Thanks.
> >>>>>>
> >>>>>> So if I want to send you a file and I want to encrypt it
> >>>> with IPsec,
> >>>>>> how do I do that, without making special arrangements first?
> >>>>>>
> >>>>>> IPsec is only used for VPN tunnels in practice today.
> >>>>>>
> >>>>>
> >>>>
> >>>>
> >>>
> >>
> >>
> >
>=20
>=20

Delivery-date: Wed, 19 Jul 2006 19:27:25 +0000
Cc: "Francis Dupont" <[email-masked]>, <[email-masked]>, "Pekka Savola" <[email-masked]>, "Iljitsch van Beijnum" <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006 
Date: Wed, 19 Jul 2006 22:26:56 +0300
To: "Bound, Jim" <[email-masked]>

El 19/07/2006, a las 20:10, Bound, Jim escribi=F3:

> Global PKI is not required for certificates that can be done with=20
> pre-shared keys too or as we are doing with shim6 out-of-band=20
> signaling.  If any here believe IPsec will not be used end-to-end=20
> think again please it will.  Ipsec is totally possible and I will not=20=

> repeat my mail on enclaves for end-to-end PKI as that is a deployment=20=

> and systems integration implementation issue.
>

ok at this point it seems to me that we may start to repeating=20
ourselves, so at least let's try to identify where do we disagree...

What i am saying is that:

- In order to use IPSec to protect the shim6 protocol (in particular=20
for providing a secure binding between identifier and locators), there=20=

are two options: a) we use certificates issued by a global PKI are=20
needed in all shim6 peers or b) we have preshared keys in all shim6=20
nodes

do you disagree with this statement?

I assume you do

if you disagree could you explain to me how would you protect the shim6=20=

protocol from the threats described in RFC4218?

in particular could you explain to me how would you protect from the=20
following attack:

Suppose that Alice and Bob work in the same office and that Alice reads=20=

the local newspaper web page every morning at www.localpress.com
Now, suppose that tomorrow is Alice birthday and since Bob has a crush=20=

on Alice, Bob wants to make Alice believe that tomorrow local newspaper=20=

headline is "Happy Birthday Alice".

In order to do that, Bob's plan is to hijack any future communication=20
that Alice initiates from her machine to Bob's laptop, so Bob can=20
substitute the local newspaper web page by his own fake happy birthday=20=

greetings home page.

So, in the DNS www.localpress.com has a single IP address IPlp.

To launch the attack, the night before, Bob creates a shim6 state in=20
alice machine. In order to do that, Bob initiates the shim6 context=20
establishment exchange.

The created context, has IPlp as ULID and it has IPB (i.e. Bob's laptop=20=

IP) as preferred locator.

In order to keep the context alive, Bob sends periodic packets (e.g.=20
ping or UDP) to Alice machine. Note that the goal of these packets is=20
just to prevent the shim6 state at Alice machine to be garbage=20
collected, so there is no need to have a actual application receiving=20
those packets above the shim (i.e. these packets can be perfectly=20
discarded once they passed above the shim, and they would still be=20
fulfilling their goal from the attack p.o.v.)

The next morning (Alice birthday!!!) Alice arrives to the office and=20
she tries to connect to the local newspaper as everyday. The only=20
difference is that today, there is a shim6 state in Alice machine for=20
IPlp.
Alice browser asks the resolver for www.localpress.com. the resolver=20
returns IPlp. The browser initiates a TCP connection with IPlp, but the=20=

SYN packet is intercepted by the shim layer (at Alice's machine) and=20
the address is translated to IPB. the result, the communication is=20
redirected to Bob's machine and Alice will be accessing Bob's web=20
server while she thinks that she is reaching the local newspaper web=20
page

Bob has managed to steal the local newspaper IP identity from Alice=20
p.o.v.

This type of attack cannot be prevented by simply using IPSec, because=20=

it is launched before the keys have been exchanged.

In order to prevent these attacks, we need additional tools, like=20
global certificates, pre shared keys or crypto identities.

reagrds, marcelo

> thanks
> /jim
>
>> -----Original Message-----
>> From: marcelo bagnulo braun [mailto:[email-masked]]
>> Sent: Wednesday, July 19, 2006 11:32 AM
>> To: Bound, Jim
>> Cc: Francis Dupont; [email-masked]; Pekka Savola; Iljitsch van Beijnum
>> Subject: Re: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006
>>
>>
>> El 19/07/2006, a las 16:55, Bound, Jim escribi=F3:
>>
>>> I was assuming the node regardless will use IPsec as
>> required.  Thus
>>> it really is not shime6 concern.  But I do not believe no
>> one will not
>>> deploy IPsec because of PKI that is simply not true.
>>
>> i agree with this
>>
>>
>> but the problem is that if you want to use IPSEc to secure
>> the shim, you need to use certificates, if not the security
>> is not acceptable.
>>
>> You need to provide a secure binding between the identifer
>> and the locators. IPSec wihtout certificates does not
>> provides this feature. If you want to use IPSec to secure the
>> shim6 protocol, you need the certificates hence you need the
>> global PKI.
>>
>> So in order to evaluate a solution based on IPSec for
>> securing the shim6, you need to consider the fact that a
>> global PKI is required for this.
>>
>> Hence, the alternative solution for securing the shim at this
>> point would be IPSec+PKI, agree?
>>
>> regards, marcelo
>>
>>
>>
>>>   IPsec is deployed today with PKI.
>>>
>>
>>
>>> /jim
>>>
>>>> -----Original Message-----
>>>> From: marcelo bagnulo braun [mailto:[email-masked]]
>>>> Sent: Wednesday, July 19, 2006 8:04 AM
>>>> To: Francis Dupont
>>>> Cc: [email-masked]; Bound, Jim; Pekka Savola; Iljitsch van Beijnum
>>>> Subject: Re: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006
>>>>
>>>>
>>>> El 19/07/2006, a las 14:38, Francis Dupont escribi=F3:
>>>>
>>>>> I can't see where Jim proposed to base the Shim6 security
>>>> on IPsec...
>>>>
>>>> in message http://ops.ietf.org/lists/shim6/msg01511.html
>>>>
>>>> it is stated that:
>>>>
>>>> Suggestion is to simply embed ULIDs within the data
>> payload with new
>>>> option and secure all communications at least for now for IP layer
>>>> communcatiions with IPsec encryption based on locator pair.
>>>>
>>>> meaning to use IPSec as an alternative to HBA security
>>>>
>>>>> (something which is known to require the impossible and even not
>>>>> desirable global PKI :-)
>>>>>
>>>>
>>>> exactly
>>>>
>>>> Regards, marcelo
>>>>
>>>>
>>>>> Regards
>>>>>
>>>>> [email-masked]
>>>>>
>>>>
>>>>
>>>
>>
>>
>

Delivery-date: Wed, 19 Jul 2006 19:25:36 +0000
Content-class: urn:content-classes:message
Subject: RE: Security Module for shim6 or hip really
Date: Wed, 19 Jul 2006 15:24:26 -0400
From: "Bound, Jim" <[email-masked]>
To: "Iljitsch van Beijnum" <[email-masked]>
Cc: <[email-masked]>

Well we have the talent here to identify the interface and abstraction.
We would have to also address how does it effect the wire protocol parts
of SHIM6 exchanges too.  I know I might sound like a broken record but
we need to get security area to help too?  Or at least keep track.
/jim=20

> -----Original Message-----
> From: Iljitsch van Beijnum [mailto:[email-masked]]=20
> Sent: Wednesday, July 19, 2006 2:50 PM
> To: Bound, Jim
> Cc: [email-masked]
> Subject: Re: Security Module for shim6 or hip really
>=20
> On 19-jul-2006, at 16:19, Bound, Jim wrote:
>=20
> > A suggestion proposed at the Montreal IETF SHIM6 WG meeting was to=20
> > treat the security of ULIDs as module (abstractly speaking)=20
> for SHIM6=20
> > where the user or implementer can plug in different solutions.
>=20
> Right.
>=20
> This is attractive in some ways, but it does require us to=20
> come up with an interface for exchanging this information=20
> between the shim layer and the different providers of=20
> security. How would that work?
>=20

Delivery-date: Wed, 19 Jul 2006 19:20:32 +0000
Cc: <[email-masked]>, "Pekka Savola" <[email-masked]>, "Iljitsch van Beijnum" <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006
Date: Wed, 19 Jul 2006 22:20:01 +0300
To: "Bound, Jim" <[email-masked]>

El 19/07/2006, a las 20:01, Bound, Jim escribi=F3:

> I don't agree it is huge deployment obstacle,

i guess e need to agree to disagree here.

I certainly think that requiring certificates issued by a global PKIto=20=

all the nodes running shim6 is a huge deployment obstacle

what do others think? does it seems an acceptable apporach to base=20
shim6 security in the availability of certificates issue by a global=20
PKI in all shim6 peers?

>  but if it was it is not our issue here in IETF WG.

yes it is. because if we propose a protocol that relies on tools that=20
require massive dpeloyment cost, then the protocol is likely to not be=20=

deployed so it is a poor solution. As engineers, we need to provide=20
deployable solutions i.e solutions with a reduced deployment costs (in=20=

other words, the deployment cost is a factor to be taken into account=20
when evaluating different solutions)

>   Biometric, Smartcards, LinkIDs can all be preshared and associated=20=

> with enclaves per the other thread on end-to-end PKI.
>

i am not sure what do you mean here, but i am afraid that of all these=20=

abve, only preshared secret and global pki could be used to secure the=20=

shim... i don't think biometrics or smarcards can help here..

regards, marcelo

> /jim
>
>> -----Original Message-----
>> From: marcelo bagnulo braun [mailto:[email-masked]]
>> Sent: Wednesday, July 19, 2006 11:28 AM
>> To: Bound, Jim
>> Cc: [email-masked]; Pekka Savola; Iljitsch van Beijnum
>> Subject: Re: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006
>>
>>
>> El 19/07/2006, a las 16:52, Bound, Jim escribi=F3:
>>
>>> Hi Marcello,
>>>
>>> Well my view is specs cannot make assumptions about market
>> deployment
>>> the question first to ask is would IPsec work.
>>
>> i agree with this
>>
>> however, it is imho completelly valid to evaluate different
>> solutions based on their deployment costs.
>>
>> A solution based on IPSec requires either pre shared keys
>> between all the nodes in the internet or certificates for all
>> the nodes of the internet. This is a huge deployment
>> obstacle. So this solution does present this problem and
>> needs to be taken into account when evaluating different
>> solutions. A solution that does not requires this would
>> require less deployment effort. Of course this is not the
>> only (or even most important) consideration when evaluating
>> alternative solutions but it is indeed an important element
>> imho, do you agree?
>>
>> regards, marcelo
>>
>>
>>>   None of us have a crystal ball and our engineering work here is
>>> usually focused on the protocol behavior and that it does
>> no harm and
>>> does not cause interoperability problems.
>>>
>>> /jim
>>>
>>>> -----Original Message-----
>>>> From: marcelo bagnulo braun [mailto:[email-masked]]
>>>> Sent: Wednesday, July 19, 2006 5:57 AM
>>>> To: Bound, Jim
>>>> Cc: [email-masked]; Pekka Savola; Iljitsch van Beijnum
>>>> Subject: Re: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006
>>>>
>>>> Hi Jim,
>>>>
>>>>
>>>> El 11/07/2006, a las 17:25, Bound, Jim escribi=F3:
>>>>
>>>>> I see this point.  Clearly public or pre-shared PKI has to
>>>> exist yes.
>>>>> But enclaves of network users will have this association is the
>>>>> assumption.  So if we are not in some enclave we would
>> need to join
>>>>> one to send each other files via IPsec with encrypt.  The
>>>> enclaves are
>>>>> being built now.
>>>>
>>>>
>>>> As i understand it, the only way to make the shim6
>> security based on
>>>> IPSec is to assume that a global PKI is deployed, including client
>>>> certificates (i.e. not only server
>>>> certificates) so that it is possible to secure any-to-any
>>>> communication.
>>>>
>>>>  =46rom what i understand such global pki is not in place yet and =
it
>>>> doesn't looks like it will be anytime soon if ever.
>>>>
>>>> So, i really don't think it is reasonable to build the security on
>>>> the
>>>> shim6 relying on such global pki deployment
>>>>
>>>> does anybody think that it would be acceptable to build the
>>>> shim6 security based on the  assumption of a global PKI deployment?
>>>>
>>>> Regards, marcelo
>>>>
>>>>
>>>>>
>>>>> Sorry I missed your point.
>>>>>
>>>>> /jim
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Iljitsch van Beijnum [mailto:[email-masked]]
>>>>>> Sent: Tuesday, July 11, 2006 10:19 AM
>>>>>> To: Bound, Jim
>>>>>> Cc: Pekka Savola; [email-masked]
>>>>>> Subject: Re: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006
>>>>>>
>>>>>> On 11-jul-2006, at 10:13, Bound, Jim wrote:
>>>>>>
>>>>>>> IPsec is deployed end-to-end for v4 and v6 in production
>>>> not sure I
>>>>>>> agree no one knows how to do this and I think I
>>>> misunderstood your
>>>>>>> statement below?  Thanks.
>>>>>>
>>>>>> So if I want to send you a file and I want to encrypt it
>>>> with IPsec,
>>>>>> how do I do that, without making special arrangements first?
>>>>>>
>>>>>> IPsec is only used for VPN tunnels in practice today.
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>

Delivery-date: Wed, 19 Jul 2006 19:15:08 +0000
Cc: "Brian E Carpenter" <[email-masked]>, <[email-masked]>, "Joe Abley" <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: IPsec Issue Discussed for Shim6 at IETF Meeting July 10, 2006
Date: Wed, 19 Jul 2006 22:14:21 +0300
To: "Bound, Jim" <[email-masked]>

El 19/07/2006, a las 19:59, Bound, Jim escribi=F3:

>
>>
>> The shim6 spec does have some words about this, in particular section
>> 1.6 states:
>>
>>     Layering AH and ESP above the multihoming shim means that
>> IPsec can
>>     be made to be unaware of locator changes the same way
>> that transport
>>     protocols can be unaware.  Thus the IPsec security associations
>>     remain stable even though the locators are changing.
>> This means that
>>     the IP addresses specified in the selectors should be the ULIDs.
>>
>> however, it would be possible to add additional detailed
>> description about how would IPSec processing look like in a
>> shimmed environment (whether in the base spec or in the
>> applicability statement)
>
> The above is really not enough it needs to speak to the actual IPsec=20=

> processing and discuss the out-of-band signaling required.
>

i am not sure i understand...

a description of the IPSec processing is what i mentioned above, so i=20
guess we agree here

in addition, you suggest to include the out of band processing, but if=20=

i understand correctly this IS the shim6 protocol, since this is the=20
way the alternative locators and associated security information is=20
conveyed... we could put it explicitely...

>>
>>>   That would help yes.  But, the home agent address is secured with
>>> the mobile node too by IPsec.
>>
>> i was not cosnidering the communication with the HA but
>> directly with the CN using RO mode
>
> Same thing from the HA side as it is proxy to the MN.
>

No, the HA is not involved in the data path when RO mode is used,

in RO mode the data packet flow directly between the MN and the CN, so=20=

the two cases RO and BT mode are different. The point is that RO mode=20
requires similar out of band signaling and result in a IPSEc processing=20=

equal to the one of the shim6 protocol

>>
>>>  Making this word change in the spec and having a
>> discussion would be
>>> progress for sure, and we can then at least discuss security
>>> ramifications.  If you go to my very first mail on this the first
>>> input is that the text discussing this part of shim6 is not clear
>>> fixing that is a priori for sure then we can go to next steps.  But
>>> the MIPv6 case is not out of band signaling per se because the home
>>> agent address was kept with the node when it roamed and did
>> not have
>>> to be securely negotiated after going mobile.  That is a different
>>> network security scenario and property than CGA in shim6.
>>>
>>
>> indeed the communication between the HA and the mobile node
>> is a different scenario, but the communication between the MN
>> and the CN in RO mode is exactly the same scenario than a
>> shim6 communication AFAICT and it uses the exact same type of
>> out-band signalling, agree?
>
> It is not exactly the same all cohesive security containment is=20
> rigorous on the MN as it owns its HA address.

the point is how oes it proves to the CN that it owns the HoA... using=20=

IPSec? no, because, similarly to the shim6 case, in order to use IPSec=20=

for this you would need global PKI. So alternative methods (the so=20
called out of band signalling) are needed. The result in terms of IPSec=20=

processing is the same than in shim. Both MIP and shim lie below the=20
IPSec layer and the translate the locator of received packet to the=20
original identifiers/home address, so that the IPSec SA can be searched=20=

using the identifiers and not the locators used to route the packets.

>   Much different than what we are saying here.  Also the CN still can=20=

> perform IPsec processing at the IP layer without popping up to code=20
> for a shim layer.
>

I don't see why do you day this... MIP needs to restore the HoA before=20=

the IPSec processing exactly the same that in the shim case, where the=20=

shim needs to restore the ulids before IPSec processing. In both cases=20=

the security of the binding between the identifier and the locators is=20=

not based in IPSec but is this out of band security.

Regards, marcelo

> thanks
> /jim
>>
>> regards, marcelo
>>
>>
>>> /jim
>>>
>>>> -----Original Message-----
>>>> From: marcelo bagnulo braun [mailto:[email-masked]]
>>>> Sent: Wednesday, July 19, 2006 4:32 AM
>>>> To: Bound, Jim
>>>> Cc: Brian E Carpenter; [email-masked]; Joe Abley
>>>> Subject: Re: IPsec Issue Discussed for Shim6 at IETF
>> Meeting July 10,
>>>> 2006
>>>>
>>>> Hi Jim,
>>>>
>>>>
>>>> El 18/07/2006, a las 18:23, Bound, Jim escribi=F3:
>>>>
>>>>> Brian and Joe, (thanks).
>>>>>
>>>>> If ULID is both ID and Locator that is fine.  Here is more
>>>> on my issue
>>>>> and sorry for late response traveling and email is a pain.
>>>>>
>>>>> If when the packet is transmitted and the Locator is not
>>>> the ULID, AND
>>>>> the ULID is the SA to decrypt the packet is my concern.
>>>>>
>>>>> Here is why.
>>>>>
>>>>> First that means some form of out-of-band signaling was done to
>>>>> identify a Locator to a ULID so the decrypt can even
>>>> happen. This is
>>>>> out of scope for the IPsec architecture we clearly did
>> not support
>>>>> out-of-band singaling for IPsec all the way back to the
>>>> 1994 or 1995
>>>>> Danvers IETF meeting when we decided to move to IPsec.
>>>>>
>>>>> Second I am concerned about implementations that now assume
>>>> per IPsec
>>>>> that in fact the Locator is the SA in the arriving or
>>>> sending packet
>>>>> to another node.
>>>>>
>>>>> Does that help?
>>>>>
>>>>
>>>>
>>>> but isn't the case that there are existent protocols that
>> also use an
>>>> out of band signaling that you mention below the IPSec layer in a
>>>> similar fashion that the shim6 protocol (and i think there
>> are valid
>>>> reasons why to do that)
>>>>
>>>> Let's consider that case of Mobile IPv6 and in particular
>> the case of
>>>> RO mode
>>>>
>>>> Suppose that we have a node M that is communicating with a node C
>>>>
>>>> Suppose that node M has a stable address IPH and that node
>> C has an
>>>> address IPC
>>>>
>>>> Suppose that M and C have established and IPSec protected
>>>> communication using IPH and IPC (hence the IPSec SA
>> contains IPH and
>>>> IPC)
>>>>
>>>> Suppose now that node M (which is a mobile node running
>>>> MIPv6) moves and it gets a new address CoA
>>>>
>>>> Suppose that the communication between M and C is in route
>>>> optimization mode
>>>>
>>>> Consider the case of packet flowing from M to node C.
>>>> In this case, packets flowing from M to the mobile node C will be
>>>> carrying CoA in the src address field of the IPv6 header and they
>>>> will carry the HoA dst option containing the IPH address
>> In addition,
>>>> the packets carry the ESP/AH header.
>>>> Since the IPSec SA contains IPH (and not CoA) the IPH must be
>>>> restored by the MIPv6 layer before the processing.
>>>>
>>>> Actually, RFC3775 states in page 110 that:
>>>>
>>>>        If route optimization is in use, the mobile node
>> inserts a Home
>>>>        Address destination option into the packet, replacing the
>>>> Source
>>>>        Address in the packet's IP header with the care-of
>> address used
>>>>        with this correspondent node, as described in
>> Section 11.3.1.
>>>> The
>>>>        Destination Options header in which the Home Address
>>>> destination
>>>>        option is inserted MUST appear in the packet after
>> the routing
>>>>        header, if present, and before the IPsec (AH [5] or ESP [6])
>>>>        header, so that the Home Address destination option is
>>>> processed
>>>>        by the destination node before the IPsec header is
>> processed.
>>>>
>>>> This basically means, that upon reception, MIPv6 will restore the
>>>> original IPH address before the IPSec processing, so that the
>>>> original addresses/identifers can be used to search the IPSec SA.
>>>>
>>>> As far as i can see this is exactly the same behaviour
>> that is being
>>>> proposed for the shim, or do you see any difference
>> between the case
>>>> of the shim6 and mipv6?
>>>>
>>>> Regards, marcelo
>>>>
>>>>
>>>>
>>>>
>>>>> Thanks
>>>>> /jim
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Brian E Carpenter [mailto:[email-masked]]
>>>>>> Sent: Tuesday, July 18, 2006 11:04 AM
>>>>>> To: Joe Abley
>>>>>> Cc: Bound, Jim; [email-masked]
>>>>>> Subject: Re: IPsec Issue Discussed for Shim6 at IETF
>>>> Meeting July 10,
>>>>>> 2006
>>>>>>
>>>>>> Joe Abley wrote:
>>>>>>>
>>>>>>> On 18-Jul-2006, at 07:24, Brian E Carpenter wrote:
>>>>>>>
>>>>>>>> Sure, in my shim6 world the ULID is an initially valid locator.
>>>>>>>> Of course, it may become invalid dynamically during the
>>>>>> course of a
>>>>>>>> session, but that will not invalidate the SA as far as
>> I can see.
>>>>>>>
>>>>>>>
>>>>>>> Surely the ULID is static for the lifetime of a session,
>>>>>> regardless
>>>>>>> of what happens to the locator set?
>>>>>>
>>>>>> Exactly my point; but if the ULID ceases to work as a
>>>> locator, it no
>>>>>> longer has its initial duality as both an ID and a locator.
>>>>>> And I want to be sure than Jim doesn't see a problem in that.
>>>>>>
>>>>>>      Brian
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>

Delivery-date: Wed, 19 Jul 2006 19:00:17 +0000
Cc: shim6-wg <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006
Date: Wed, 19 Jul 2006 20:59:33 +0200
To: marcelo bagnulo braun <[email-masked]>

On 19-jul-2006, at 15:39, marcelo bagnulo braun wrote:

>> Why? If one end has a certificate the communication can be secure.

> but you still can provide identifier ownership proof, right?

> I mean, in order to avoid future attacks agaisnt the identity we  
> need more than just a secure channel but a secure binding between  
> the identifier and something that canbe used to prove ownership  
> (like a public/private key pair)

> so, such scheme would result in the posibilty of identity hijacking  
> attacks

> in order to avoid those, you need something else, like client  
> certificates

Right, you'd have the situation where client A connects to server X  
and X's certificate is used to protect the exchange of A's locator B,  
but then later X wants to talk to A and uses B but it turned out that  
A wasn't really A but someone "borrowing" A's address on an insecure  
link for a moment.

Return routability should help a bit here but it's not particularly  
strong... Same for DNS (X could check whether reverse A -> forward A - 
 > B) but this is pretty weak also, as long as we don't have DNSSEC.

I guess I could live with either requiring a client certificate  
(especially as this could be one proxy certificate for a proxy that  
handles a bunch of clients) or that new sessions may only be  
initiated by the client (server dumps all shim state when it needs to  
set up a session towards the client).

I expect nearly everyone to implement HBA anyway, but if some people  
really don't want it at least they have SOMETHING this way. Not  
having a mandatory security mechanism is possible here, IMO, as this  
simply means no multihoming benefits.

Delivery-date: Wed, 19 Jul 2006 18:50:09 +0000
Cc: <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: Security Module for shim6 or hip really
Date: Wed, 19 Jul 2006 20:49:38 +0200
To: "Bound, Jim" <[email-masked]>

On 19-jul-2006, at 16:19, Bound, Jim wrote:

> A suggestion proposed at the Montreal IETF SHIM6 WG meeting was to  
> treat
> the security of ULIDs as module (abstractly speaking) for SHIM6 where
> the user or implementer can plug in different solutions.

Right.

This is attractive in some ways, but it does require us to come up  
with an interface for exchanging this information between the shim  
layer and the different providers of security. How would that work?

Delivery-date: Wed, 19 Jul 2006 18:48:48 +0000
Cc: shim6-wg <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006
Date: Wed, 19 Jul 2006 20:47:57 +0200
To: "Ahrenholz, Jeffrey M" <[email-masked]>

On 19-jul-2006, at 17:35, Ahrenholz, Jeffrey M wrote:

> To throw 2-cents into this conversation, the SIDR WG seems to be
> considering a global PKI, albeit for BGP routers and not end hosts.

I don't take the discussions in SIDR to mean that every BGP router  
will have a certificate. That may or may not happen (I don't think  
storing private keys in routers that may be housed in fairly insecure  
places is a very good idea) but even if it does, that's not the same  
thing as having a certificate for EVERY host.

Delivery-date: Wed, 19 Jul 2006 17:32:30 +0000
Content-class: urn:content-classes:message
Subject: Shipping SHIM6 spec to IESG or not question per ULID Security
Date: Wed, 19 Jul 2006 13:31:31 -0400
From: "Bound, Jim" <[email-masked]>
To: <[email-masked]>

Shim6 Chairs,

Process Check.

I think the point now is there is WG significant interest in pursuing
the security discussion thus shipping shim6 to IESG with HBA as current
in the spec or the effect to IPsec is not optimal.  Unless we remove it
from the spec currently.

/jim=20

Delivery-date: Wed, 19 Jul 2006 17:24:03 +0000
Content-class: urn:content-classes:message
Subject: RE: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006 
Date: Wed, 19 Jul 2006 13:23:08 -0400
From: "Bound, Jim" <[email-masked]>
To: "Pekka Savola" <[email-masked]>
Cc: "Fiumano, Michael F [NTK]" <[email-masked]>, "marcelo bagnulo braun" <[email-masked]>, "Francis Dupont" <[email-masked]>, <[email-masked]>, "Iljitsch van Beijnum" <[email-masked]>

Good points but I would suggest we do not want a default for shim6 that
will not be deployed widely at least for 5 years minimum based soley on
HBA.  Let not create a default and do all security for shim6 as
extension to the base spec.

/jim=20

> -----Original Message-----
> From: Pekka Savola [mailto:[email-masked]]=20
> Sent: Wednesday, July 19, 2006 11:52 AM
> To: Bound, Jim
> Cc: Fiumano, Michael F [NTK]; marcelo bagnulo braun; Francis=20
> Dupont; [email-masked]; Iljitsch van Beijnum
> Subject: RE: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006=20
>=20
> On Wed, 19 Jul 2006, Bound, Jim wrote:
> > I don't think we can ever require that and nor have we in any spec.=20
> > Preshared keys work but the point is that is a market=20
> decision not an=20
> > IETF decision.  We build the protocols with operational guidance in=20
> > some cases whether or how they are used in the market is a=20
> red herring=20
> > for our work to keep moving forward.  We are more like=20
> scientists not=20
> > marketing and business people.
>=20
> Exactly.  Which is why we should move ahead without IPsec and=20
> PKI requirement.
>=20
> This debate seems pretty much like a recap of MIPv6 route=20
> optimization security discussions about 5 or so years ago. =20
> IPsec and PKI were deemed insufficient _in practice_, for=20
> _the general solution_, and I don't think the situation has=20
> changed in a significant way.
>=20
> I don't think no one is disputing that IPsec and PKI could be=20
> useful in some contexts where PKI has already been deployed. =20
> If folks think this is a sufficiently useful scenario, maybe=20
> it would be worth specifying in an optional shim6 extension.
>=20
> --=20
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
>=20

Delivery-date: Wed, 19 Jul 2006 17:10:59 +0000
Content-class: urn:content-classes:message
Subject: RE: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006 
Date: Wed, 19 Jul 2006 13:10:09 -0400
From: "Bound, Jim" <[email-masked]>
To: "marcelo bagnulo braun" <[email-masked]>
Cc: "Francis Dupont" <[email-masked]>, <[email-masked]>, "Pekka Savola" <[email-masked]>, "Iljitsch van Beijnum" <[email-masked]>

Global PKI is not required for certificates that can be done with =
pre-shared keys too or as we are doing with shim6 out-of-band signaling. =
 If any here believe IPsec will not be used end-to-end think again =
please it will.  Ipsec is totally possible and I will not repeat my mail =
on enclaves for end-to-end PKI as that is a deployment and systems =
integration implementation issue.

thanks
/jim=20

> -----Original Message-----
> From: marcelo bagnulo braun [mailto:[email-masked]]=20
> Sent: Wednesday, July 19, 2006 11:32 AM
> To: Bound, Jim
> Cc: Francis Dupont; [email-masked]; Pekka Savola; Iljitsch van Beijnum
> Subject: Re: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006=20
>=20
>=20
> El 19/07/2006, a las 16:55, Bound, Jim escribi=F3:
>=20
> > I was assuming the node regardless will use IPsec as=20
> required.  Thus=20
> > it really is not shime6 concern.  But I do not believe no=20
> one will not=20
> > deploy IPsec because of PKI that is simply not true.
>=20
> i agree with this
>=20
>=20
> but the problem is that if you want to use IPSEc to secure=20
> the shim, you need to use certificates, if not the security=20
> is not acceptable.
>=20
> You need to provide a secure binding between the identifer=20
> and the locators. IPSec wihtout certificates does not=20
> provides this feature. If you want to use IPSec to secure the=20
> shim6 protocol, you need the certificates hence you need the=20
> global PKI.
>=20
> So in order to evaluate a solution based on IPSec for=20
> securing the shim6, you need to consider the fact that a=20
> global PKI is required for this.
>=20
> Hence, the alternative solution for securing the shim at this=20
> point would be IPSec+PKI, agree?
>=20
> regards, marcelo
>=20
>=20
>=20
> >   IPsec is deployed today with PKI.
> >
>=20
>=20
> > /jim
> >
> >> -----Original Message-----
> >> From: marcelo bagnulo braun [mailto:[email-masked]]
> >> Sent: Wednesday, July 19, 2006 8:04 AM
> >> To: Francis Dupont
> >> Cc: [email-masked]; Bound, Jim; Pekka Savola; Iljitsch van Beijnum
> >> Subject: Re: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006
> >>
> >>
> >> El 19/07/2006, a las 14:38, Francis Dupont escribi=F3:
> >>
> >>> I can't see where Jim proposed to base the Shim6 security
> >> on IPsec...
> >>
> >> in message http://ops.ietf.org/lists/shim6/msg01511.html
> >>
> >> it is stated that:
> >>
> >> Suggestion is to simply embed ULIDs within the data=20
> payload with new=20
> >> option and secure all communications at least for now for IP layer=20
> >> communcatiions with IPsec encryption based on locator pair.
> >>
> >> meaning to use IPSec as an alternative to HBA security
> >>
> >>> (something which is known to require the impossible and even not=20
> >>> desirable global PKI :-)
> >>>
> >>
> >> exactly
> >>
> >> Regards, marcelo
> >>
> >>
> >>> Regards
> >>>
> >>> [email-masked]
> >>>
> >>
> >>
> >
>=20
>=20

Delivery-date: Wed, 19 Jul 2006 17:02:21 +0000
Content-class: urn:content-classes:message
Subject: RE: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006
Date: Wed, 19 Jul 2006 13:01:25 -0400
From: "Bound, Jim" <[email-masked]>
To: "marcelo bagnulo braun" <[email-masked]>
Cc: <[email-masked]>, "Pekka Savola" <[email-masked]>, "Iljitsch van Beijnum" <[email-masked]>

I don't agree it is huge deployment obstacle, but if it was it is not =
our issue here in IETF WG.  Biometric, Smartcards, LinkIDs can all be =
preshared and associated with enclaves per the other thread on =
end-to-end PKI.

/jim=20

> -----Original Message-----
> From: marcelo bagnulo braun [mailto:[email-masked]]=20
> Sent: Wednesday, July 19, 2006 11:28 AM
> To: Bound, Jim
> Cc: [email-masked]; Pekka Savola; Iljitsch van Beijnum
> Subject: Re: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006
>=20
>=20
> El 19/07/2006, a las 16:52, Bound, Jim escribi=F3:
>=20
> > Hi Marcello,
> >
> > Well my view is specs cannot make assumptions about market=20
> deployment=20
> > the question first to ask is would IPsec work.
>=20
> i agree with this
>=20
> however, it is imho completelly valid to evaluate different=20
> solutions based on their deployment costs.
>=20
> A solution based on IPSec requires either pre shared keys=20
> between all the nodes in the internet or certificates for all=20
> the nodes of the internet. This is a huge deployment=20
> obstacle. So this solution does present this problem and=20
> needs to be taken into account when evaluating different=20
> solutions. A solution that does not requires this would=20
> require less deployment effort. Of course this is not the=20
> only (or even most important) consideration when evaluating=20
> alternative solutions but it is indeed an important element=20
> imho, do you agree?
>=20
> regards, marcelo
>=20
>=20
> >   None of us have a crystal ball and our engineering work here is=20
> > usually focused on the protocol behavior and that it does=20
> no harm and=20
> > does not cause interoperability problems.
> >
> > /jim
> >
> >> -----Original Message-----
> >> From: marcelo bagnulo braun [mailto:[email-masked]]
> >> Sent: Wednesday, July 19, 2006 5:57 AM
> >> To: Bound, Jim
> >> Cc: [email-masked]; Pekka Savola; Iljitsch van Beijnum
> >> Subject: Re: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006
> >>
> >> Hi Jim,
> >>
> >>
> >> El 11/07/2006, a las 17:25, Bound, Jim escribi=F3:
> >>
> >>> I see this point.  Clearly public or pre-shared PKI has to
> >> exist yes.
> >>> But enclaves of network users will have this association is the=20
> >>> assumption.  So if we are not in some enclave we would=20
> need to join=20
> >>> one to send each other files via IPsec with encrypt.  The
> >> enclaves are
> >>> being built now.
> >>
> >>
> >> As i understand it, the only way to make the shim6=20
> security based on=20
> >> IPSec is to assume that a global PKI is deployed, including client=20
> >> certificates (i.e. not only server
> >> certificates) so that it is possible to secure any-to-any=20
> >> communication.
> >>
> >>  From what i understand such global pki is not in place yet and it=20
> >> doesn't looks like it will be anytime soon if ever.
> >>
> >> So, i really don't think it is reasonable to build the security on=20
> >> the
> >> shim6 relying on such global pki deployment
> >>
> >> does anybody think that it would be acceptable to build the
> >> shim6 security based on the  assumption of a global PKI deployment?
> >>
> >> Regards, marcelo
> >>
> >>
> >>>
> >>> Sorry I missed your point.
> >>>
> >>> /jim
> >>>
> >>>> -----Original Message-----
> >>>> From: Iljitsch van Beijnum [mailto:[email-masked]]
> >>>> Sent: Tuesday, July 11, 2006 10:19 AM
> >>>> To: Bound, Jim
> >>>> Cc: Pekka Savola; [email-masked]
> >>>> Subject: Re: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006
> >>>>
> >>>> On 11-jul-2006, at 10:13, Bound, Jim wrote:
> >>>>
> >>>>> IPsec is deployed end-to-end for v4 and v6 in production
> >> not sure I
> >>>>> agree no one knows how to do this and I think I
> >> misunderstood your
> >>>>> statement below?  Thanks.
> >>>>
> >>>> So if I want to send you a file and I want to encrypt it
> >> with IPsec,
> >>>> how do I do that, without making special arrangements first?
> >>>>
> >>>> IPsec is only used for VPN tunnels in practice today.
> >>>>
> >>>
> >>
> >>
> >
>=20
>=20

Delivery-date: Wed, 19 Jul 2006 17:00:55 +0000
Content-class: urn:content-classes:message
Subject: RE: IPsec Issue Discussed for Shim6 at IETF Meeting July 10, 2006
Date: Wed, 19 Jul 2006 12:59:41 -0400
From: "Bound, Jim" <[email-masked]>
To: "marcelo bagnulo braun" <[email-masked]>
Cc: "Brian E Carpenter" <[email-masked]>, <[email-masked]>, "Joe Abley" <[email-masked]>

>=20
> The shim6 spec does have some words about this, in particular section
> 1.6 states:
>=20
>     Layering AH and ESP above the multihoming shim means that=20
> IPsec can
>     be made to be unaware of locator changes the same way=20
> that transport
>     protocols can be unaware.  Thus the IPsec security associations
>     remain stable even though the locators are changing. =20
> This means that
>     the IP addresses specified in the selectors should be the ULIDs.
>=20
> however, it would be possible to add additional detailed=20
> description about how would IPSec processing look like in a=20
> shimmed environment (whether in the base spec or in the=20
> applicability statement)

The above is really not enough it needs to speak to the actual IPsec =
processing and discuss the out-of-band signaling required.

>=20
> >   That would help yes.  But, the home agent address is secured with=20
> > the mobile node too by IPsec.
>=20
> i was not cosnidering the communication with the HA but=20
> directly with the CN using RO mode

Same thing from the HA side as it is proxy to the MN.

>=20
> >  Making this word change in the spec and having a=20
> discussion would be=20
> > progress for sure, and we can then at least discuss security=20
> > ramifications.  If you go to my very first mail on this the first=20
> > input is that the text discussing this part of shim6 is not clear=20
> > fixing that is a priori for sure then we can go to next steps.  But=20
> > the MIPv6 case is not out of band signaling per se because the home=20
> > agent address was kept with the node when it roamed and did=20
> not have=20
> > to be securely negotiated after going mobile.  That is a different=20
> > network security scenario and property than CGA in shim6.
> >
>=20
> indeed the communication between the HA and the mobile node=20
> is a different scenario, but the communication between the MN=20
> and the CN in RO mode is exactly the same scenario than a=20
> shim6 communication AFAICT and it uses the exact same type of=20
> out-band signalling, agree?

It is not exactly the same all cohesive security containment is rigorous =
on the MN as it owns its HA address.  Much different than what we are =
saying here.  Also the CN still can perform IPsec processing at the IP =
layer without popping up to code for a shim layer.

thanks
/jim
>=20
> regards, marcelo
>=20
>=20
> > /jim
> >
> >> -----Original Message-----
> >> From: marcelo bagnulo braun [mailto:[email-masked]]
> >> Sent: Wednesday, July 19, 2006 4:32 AM
> >> To: Bound, Jim
> >> Cc: Brian E Carpenter; [email-masked]; Joe Abley
> >> Subject: Re: IPsec Issue Discussed for Shim6 at IETF=20
> Meeting July 10,=20
> >> 2006
> >>
> >> Hi Jim,
> >>
> >>
> >> El 18/07/2006, a las 18:23, Bound, Jim escribi=F3:
> >>
> >>> Brian and Joe, (thanks).
> >>>
> >>> If ULID is both ID and Locator that is fine.  Here is more
> >> on my issue
> >>> and sorry for late response traveling and email is a pain.
> >>>
> >>> If when the packet is transmitted and the Locator is not
> >> the ULID, AND
> >>> the ULID is the SA to decrypt the packet is my concern.
> >>>
> >>> Here is why.
> >>>
> >>> First that means some form of out-of-band signaling was done to=20
> >>> identify a Locator to a ULID so the decrypt can even
> >> happen. This is
> >>> out of scope for the IPsec architecture we clearly did=20
> not support=20
> >>> out-of-band singaling for IPsec all the way back to the
> >> 1994 or 1995
> >>> Danvers IETF meeting when we decided to move to IPsec.
> >>>
> >>> Second I am concerned about implementations that now assume
> >> per IPsec
> >>> that in fact the Locator is the SA in the arriving or
> >> sending packet
> >>> to another node.
> >>>
> >>> Does that help?
> >>>
> >>
> >>
> >> but isn't the case that there are existent protocols that=20
> also use an=20
> >> out of band signaling that you mention below the IPSec layer in a=20
> >> similar fashion that the shim6 protocol (and i think there=20
> are valid=20
> >> reasons why to do that)
> >>
> >> Let's consider that case of Mobile IPv6 and in particular=20
> the case of=20
> >> RO mode
> >>
> >> Suppose that we have a node M that is communicating with a node C
> >>
> >> Suppose that node M has a stable address IPH and that node=20
> C has an=20
> >> address IPC
> >>
> >> Suppose that M and C have established and IPSec protected=20
> >> communication using IPH and IPC (hence the IPSec SA=20
> contains IPH and=20
> >> IPC)
> >>
> >> Suppose now that node M (which is a mobile node running
> >> MIPv6) moves and it gets a new address CoA
> >>
> >> Suppose that the communication between M and C is in route=20
> >> optimization mode
> >>
> >> Consider the case of packet flowing from M to node C.
> >> In this case, packets flowing from M to the mobile node C will be=20
> >> carrying CoA in the src address field of the IPv6 header and they=20
> >> will carry the HoA dst option containing the IPH address=20
> In addition,=20
> >> the packets carry the ESP/AH header.
> >> Since the IPSec SA contains IPH (and not CoA) the IPH must be=20
> >> restored by the MIPv6 layer before the processing.
> >>
> >> Actually, RFC3775 states in page 110 that:
> >>
> >>        If route optimization is in use, the mobile node=20
> inserts a Home
> >>        Address destination option into the packet, replacing the=20
> >> Source
> >>        Address in the packet's IP header with the care-of=20
> address used
> >>        with this correspondent node, as described in=20
> Section 11.3.1. =20
> >> The
> >>        Destination Options header in which the Home Address=20
> >> destination
> >>        option is inserted MUST appear in the packet after=20
> the routing
> >>        header, if present, and before the IPsec (AH [5] or ESP [6])
> >>        header, so that the Home Address destination option is=20
> >> processed
> >>        by the destination node before the IPsec header is=20
> processed.
> >>
> >> This basically means, that upon reception, MIPv6 will restore the=20
> >> original IPH address before the IPSec processing, so that the=20
> >> original addresses/identifers can be used to search the IPSec SA.
> >>
> >> As far as i can see this is exactly the same behaviour=20
> that is being=20
> >> proposed for the shim, or do you see any difference=20
> between the case=20
> >> of the shim6 and mipv6?
> >>
> >> Regards, marcelo
> >>
> >>
> >>
> >>
> >>> Thanks
> >>> /jim
> >>>
> >>>> -----Original Message-----
> >>>> From: Brian E Carpenter [mailto:[email-masked]]
> >>>> Sent: Tuesday, July 18, 2006 11:04 AM
> >>>> To: Joe Abley
> >>>> Cc: Bound, Jim; [email-masked]
> >>>> Subject: Re: IPsec Issue Discussed for Shim6 at IETF
> >> Meeting July 10,
> >>>> 2006
> >>>>
> >>>> Joe Abley wrote:
> >>>>>
> >>>>> On 18-Jul-2006, at 07:24, Brian E Carpenter wrote:
> >>>>>
> >>>>>> Sure, in my shim6 world the ULID is an initially valid locator.
> >>>>>> Of course, it may become invalid dynamically during the
> >>>> course of a
> >>>>>> session, but that will not invalidate the SA as far as=20
> I can see.
> >>>>>
> >>>>>
> >>>>> Surely the ULID is static for the lifetime of a session,
> >>>> regardless
> >>>>> of what happens to the locator set?
> >>>>
> >>>> Exactly my point; but if the ULID ceases to work as a
> >> locator, it no
> >>>> longer has its initial duality as both an ID and a locator.
> >>>> And I want to be sure than Jim doesn't see a problem in that.
> >>>>
> >>>>      Brian
> >>>>
> >>>
> >>
> >>
> >
>=20
>=20

Delivery-date: Wed, 19 Jul 2006 15:55:32 +0000
Date: Wed, 19 Jul 2006 18:52:22 +0300 (EEST)
From: Pekka Savola <[email-masked]>
To: "Bound, Jim" <[email-masked]>
cc: "Fiumano, Michael F [NTK]" <[email-masked]>, marcelo bagnulo braun <[email-masked]>, Francis Dupont <[email-masked]>, [email-masked], Iljitsch van Beijnum <[email-masked]>
Subject: RE: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006 

On Wed, 19 Jul 2006, Bound, Jim wrote:
> I don't think we can ever require that and nor have we in any spec. 
> Preshared keys work but the point is that is a market decision not 
> an IETF decision.  We build the protocols with operational guidance 
> in some cases whether or how they are used in the market is a red 
> herring for our work to keep moving forward.  We are more like 
> scientists not marketing and business people.

Exactly.  Which is why we should move ahead without IPsec and PKI 
requirement.

This debate seems pretty much like a recap of MIPv6 route optimization 
security discussions about 5 or so years ago.  IPsec and PKI were 
deemed insufficient _in practice_, for _the general solution_, and I 
don't think the situation has changed in a significant way.

I don't think no one is disputing that IPsec and PKI could be useful 
in some contexts where PKI has already been deployed.  If folks think 
this is a sufficiently useful scenario, maybe it would be worth 
specifying in an optional shim6 extension.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

Delivery-date: Wed, 19 Jul 2006 15:50:32 +0000
Cc: <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006
Date: Wed, 19 Jul 2006 18:49:49 +0300
To: "Ahrenholz, Jeffrey M" <[email-masked]>

El 19/07/2006, a las 18:35, Ahrenholz, Jeffrey M escribi=F3:

> To throw 2-cents into this conversation, the SIDR WG seems to be
> considering a global PKI, albeit for BGP routers and not end hosts.
> (http://www3.ietf.org/proceedings/06mar/slides/sidr-1.pdf)
>

right...

but this seems to be quite different that what is needded for the=20
shim6...

i mean for the shim6 protocol to work, we would need certificates that=20=

bind the address itself with the public key, wwhile what sidr is after=20=

is a certificate that binds prefixes announced in the global routing=20
table with public keys (as far as i understand, and i am not followwing=20=

this work very closely, so please correct me if i am wrong (i know you=20=

will :-)

So even if you did have the sidr like global pki, you would still need=20=

to deploy host certificates to all hosts and renew those and so on.=20
since the owner of the certificates used in sidr are the bgp players,=20
creating the cert chain all the way down to the hosts may involve=20
cosniderable deployment costs

regards, marcelo

> -Jeff
>
>> As i understand it, the only way to make the shim6 security based on
>> IPSec is to assume that a global PKI is deployed, including client
>> certificates (i.e. not only server certificates) so that it
>> is possible to secure any-to-any communication.
>>
>>  =46rom what i understand such global pki is not in place yet and it
>> doesn't looks like it will be anytime soon if ever.
>

Delivery-date: Wed, 19 Jul 2006 15:46:26 +0000
Cc: "Iljitsch van Beijnum" <[email-masked]>, "Francis Dupont" <[email-masked]>, <[email-masked]>, "Fiumano, Michael F [NTK]" <[email-masked]>, "Pekka Savola" <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006 
Date: Wed, 19 Jul 2006 18:45:42 +0300
To: "Bound, Jim" <[email-masked]>

El 19/07/2006, a las 17:37, Bound, Jim escribi=F3:

> I don't think we can ever require that and nor have we in any spec.

agree

but if the security of the shim is based on IPSec, then the shim can=20
only be used securely if the peers have either certificates or=20
preshared keys.

In other words, we would be not imposing that PKI is deployed but=20
basing the shim6 security on IPSec is requiring the availablity of=20
certificates for both peers in order to be able to use the shim. If no=20=

certificates are available at the peers, the shim6 protocol cannot be=20
used safely

Regards, marcelo

>  Preshared keys work but the point is that is a market decision not an=20=

> IETF decision.  We build the protocols with operational guidance in=20
> some cases whether or how they are used in the market is a red herring=20=

> for our work to keep moving forward.  We are more like scientists not=20=

> marketing and business people.
> /jim
>
>> -----Original Message-----
>> From: Fiumano, Michael F [NTK] [mailto:[email-masked]]
>> Sent: Wednesday, July 19, 2006 10:25 AM
>> To: Bound, Jim; marcelo bagnulo braun; Francis Dupont
>> Cc: [email-masked]; Pekka Savola; Iljitsch van Beijnum
>> Subject: RE: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006
>>
>> Very few who use IPSec also use PKI.  Most use a pre-shared
>> key.  I hope that no one is requiring that a PKI be in place
>> in order to use shim6.
>>
>> Michael Fiumano
>> Senior Network Engineer
>> IP Core Infrastructure
>> 703-689-5875 Wk
>> 703-598-2434 Cel
>> [email-masked]
>>
>>
>>
>>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On
>> Behalf Of Bound, Jim
>> Sent: Wednesday, July 19, 2006 9:55 AM
>> To: marcelo bagnulo braun; Francis Dupont
>> Cc: [email-masked]; Pekka Savola; Iljitsch van Beijnum
>> Subject: RE: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006
>>
>> I was assuming the node regardless will use IPsec as
>> required.  Thus it really is not shime6 concern.  But I do
>> not believe no one will not deploy IPsec because of PKI that
>> is simply not true.  IPsec is deployed today with PKI.
>>
>> /jim
>>
>>> -----Original Message-----
>>> From: marcelo bagnulo braun [mailto:[email-masked]]
>>> Sent: Wednesday, July 19, 2006 8:04 AM
>>> To: Francis Dupont
>>> Cc: [email-masked]; Bound, Jim; Pekka Savola; Iljitsch van Beijnum
>>> Subject: Re: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006
>>>
>>>
>>> El 19/07/2006, a las 14:38, Francis Dupont escribi=F3:
>>>
>>>> I can't see where Jim proposed to base the Shim6 security
>>> on IPsec...
>>>
>>> in message http://ops.ietf.org/lists/shim6/msg01511.html
>>>
>>> it is stated that:
>>>
>>> Suggestion is to simply embed ULIDs within the data payload
>> with new
>>> option and secure all communications at least for now for IP layer
>>> communcatiions with IPsec encryption based on locator pair.
>>>
>>> meaning to use IPSec as an alternative to HBA security
>>>
>>>> (something which is known to require the impossible and even not
>>>> desirable global PKI :-)
>>>>
>>>
>>> exactly
>>>
>>> Regards, marcelo
>>>
>>>
>>>> Regards
>>>>
>>>> [email-masked]
>>>>
>>>
>>>
>>
>>
>>
>>
>

Delivery-date: Wed, 19 Jul 2006 15:43:17 +0000
Cc: "shim6-wg" <[email-masked]>, "Iljitsch van Beijnum" <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006
Date: Wed, 19 Jul 2006 18:42:34 +0300
To: "Bound, Jim" <[email-masked]>

El 19/07/2006, a las 17:13, Bound, Jim escribi=F3:

> You can also assume the security is already protected with Ipsec.
>

please note that having a secure channel with the other end is not=20
enough to prevent hijacking attacks as described in the threat analysis=20=

RFC

in order to prevent identity hijacking attacks, you need to provide a=20
secure binding between the identifier and the alternative locators,=20
which can only be provided by IPSec either by administrative means=20
(i.e. preshared keys) or with certificates (PKI) on both ends of the=20
communication

In other words, independently if the fact that the communication is=20
previously secured by IPSec, you still need or PKI or preshared keys

Regards, marcelo

> /jim
>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On
>> Behalf Of Iljitsch van Beijnum
>> Sent: Wednesday, July 19, 2006 9:02 AM
>> To: marcelo bagnulo braun
>> Cc: shim6-wg
>> Subject: Re: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006
>>
>> On 19-jul-2006, at 14:39, marcelo bagnulo braun wrote:
>>
>>> server certificate are more widely used than client certificates
>>> indeed, but in the case of the shim6 we need certificates for both
>>> ends, so what do we do for securing the client?
>>
>> Why? If one end has a certificate the communication can be secure.
>>
>>> besides, currently deployed certificates provide binding
>> between FQDNs
>>> and public key.... while in the shim6 we need binding between IP
>>> addresses and public keys, meaning than currently deployed
>>> certificates are not good
>>
>> Yes, this involves a trip to the DNS...
>>
>>> in addition, using certificates and public key crypto is much more
>>> expensive than CGAs, since they would involve public key operations
>>> not only for the validation of the locator set (as in CGA) but also
>>> for the validation of the certificates themselves (and this costs
>>> grows if the certification chain is long). In addition,
>> there is the
>>> overhead due to the transmission of the certificates in the
>> protocol
>>> itself, including all the certificates in the cert chain, which may
>>> even not fit in a single packet so we may end up neededing to send
>>> multi-packet messages.
>>
>>> and all this for every shimmed communication....
>>
>> This is certainly true. On the other hand, if the
>> communication is already protected with TLS the _additional_
>> overhead isn't much.
>>
>> Also, I think it would make sense to do the shim negotiation
>> inside a TLS protected TCP session, which should handle all
>> the packet size issues.
>>
>>> i thought that one of the key goals in the shim6 design was
>>> efficiency.... such an approach would really move us apart from the
>>> efficiency path...
>>
>> HBA is much more efficient so that should stay security
>> option #1, but it would certainly be nice to have an
>> alternative that allows easier implementation of shim6
>> proxies and lets people avoid the patent issues if they want.
>>
>>
>

Delivery-date: Wed, 19 Jul 2006 15:40:02 +0000
Cc: <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: Security Module for shim6 or hip really
Date: Wed, 19 Jul 2006 18:39:18 +0300
To: "Bound, Jim" <[email-masked]>

Hi Jim,

El 19/07/2006, a las 17:19, Bound, Jim escribi=F3:

> A suggestion proposed at the Montreal IETF SHIM6 WG meeting was to=20
> treat
> the security of ULIDs as module (abstractly speaking) for SHIM6 where
> the user or implementer can plug in different solutions.  We would
> abstract out ULID processing for security so that multiple solutions
> could be used.

well, this is at some extent already the case...

i mean the base protocol has support for multiple security mechanisms=20
including CGA and HBA but it leaves the door open to other solutions to=20=

protect the binding

However, the problem is that imho we need to standarize at least one of=20=

the security mechanisms, if not the shim6 protocol is simply useless

the current draft proposes two mechanisms the CGA and the HBAs (and=20
implementation can implement just one of them)

i guess that the ongoing discussion is whether we can change the=20
deafult mechanisms for other alternative ones.

Regards, marcelo

>   Each solution would be its own IETF draft specification
> and IETF discussion with close collaboration with the IETF Security
> Area.  I think this would be doing proper engineering diligence for=20
> this
> problem and we can explore HBA, TLS, IPsec and even other options. =20
> This
> also would permit the shim6 spec to move forward and provide a =
security
> note in the spec and avoid the in process IPR debate for CGA.
>
> Thoughts?
>
> /jim
>

Delivery-date: Wed, 19 Jul 2006 15:36:40 +0000
Content-class: urn:content-classes:message
Subject: RE: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006
Date: Wed, 19 Jul 2006 08:35:46 -0700
From: "Ahrenholz, Jeffrey M" <[email-masked]>
To: "marcelo bagnulo braun" <[email-masked]>
Cc: <[email-masked]>

To throw 2-cents into this conversation, the SIDR WG seems to be
considering a global PKI, albeit for BGP routers and not end hosts.
(http://www3.ietf.org/proceedings/06mar/slides/sidr-1.pdf)

-Jeff

> As i understand it, the only way to make the shim6 security based on=20
> IPSec is to assume that a global PKI is deployed, including client=20
> certificates (i.e. not only server certificates) so that it=20
> is possible to secure any-to-any communication.
>=20
>  From what i understand such global pki is not in place yet and it=20
> doesn't looks like it will be anytime soon if ever.

Delivery-date: Wed, 19 Jul 2006 15:32:18 +0000
Cc: "Francis Dupont" <[email-masked]>, <[email-masked]>, "Pekka Savola" <[email-masked]>, "Iljitsch van Beijnum" <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006 
Date: Wed, 19 Jul 2006 18:31:33 +0300
To: "Bound, Jim" <[email-masked]>

El 19/07/2006, a las 16:55, Bound, Jim escribi=F3:

> I was assuming the node regardless will use IPsec as required.  Thus=20=

> it really is not shime6 concern.  But I do not believe no one will not=20=

> deploy IPsec because of PKI that is simply not true.

i agree with this

but the problem is that if you want to use IPSEc to secure the shim,=20
you need to use certificates, if not the security is not acceptable.

You need to provide a secure binding between the identifer and the=20
locators. IPSec wihtout certificates does not provides this feature. If=20=

you want to use IPSec to secure the shim6 protocol, you need the=20
certificates hence you need the global PKI.

So in order to evaluate a solution based on IPSec for securing the=20
shim6, you need to consider the fact that a global PKI is required for=20=

this.

Hence, the alternative solution for securing the shim at this point=20
would be IPSec+PKI, agree?

regards, marcelo

>   IPsec is deployed today with PKI.
>

> /jim
>
>> -----Original Message-----
>> From: marcelo bagnulo braun [mailto:[email-masked]]
>> Sent: Wednesday, July 19, 2006 8:04 AM
>> To: Francis Dupont
>> Cc: [email-masked]; Bound, Jim; Pekka Savola; Iljitsch van Beijnum
>> Subject: Re: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006
>>
>>
>> El 19/07/2006, a las 14:38, Francis Dupont escribi=F3:
>>
>>> I can't see where Jim proposed to base the Shim6 security
>> on IPsec...
>>
>> in message http://ops.ietf.org/lists/shim6/msg01511.html
>>
>> it is stated that:
>>
>> Suggestion is to simply embed ULIDs within the data payload
>> with new option and secure all communications at least for
>> now for IP layer communcatiions with IPsec encryption based
>> on locator pair.
>>
>> meaning to use IPSec as an alternative to HBA security
>>
>>> (something which is known to require the impossible and even not
>>> desirable global PKI :-)
>>>
>>
>> exactly
>>
>> Regards, marcelo
>>
>>
>>> Regards
>>>
>>> [email-masked]
>>>
>>
>>
>

Delivery-date: Wed, 19 Jul 2006 15:28:29 +0000
Cc: <[email-masked]>, "Pekka Savola" <[email-masked]>, "Iljitsch van Beijnum" <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006
Date: Wed, 19 Jul 2006 18:27:45 +0300
To: "Bound, Jim" <[email-masked]>

El 19/07/2006, a las 16:52, Bound, Jim escribi=F3:

> Hi Marcello,
>
> Well my view is specs cannot make assumptions about market deployment=20=

> the question first to ask is would IPsec work.

i agree with this

however, it is imho completelly valid to evaluate different solutions=20
based on their deployment costs.

A solution based on IPSec requires either pre shared keys between all=20
the nodes in the internet or certificates for all the nodes of the=20
internet. This is a huge deployment obstacle. So this solution does=20
present this problem and needs to be taken into account when evaluating=20=

different solutions. A solution that does not requires this would=20
require less deployment effort. Of course this is not the only (or even=20=

most important) consideration when evaluating alternative solutions but=20=

it is indeed an important element imho, do you agree?

regards, marcelo

>   None of us have a crystal ball and our engineering work here is=20
> usually focused on the protocol behavior and that it does no harm and=20=

> does not cause interoperability problems.
>
> /jim
>
>> -----Original Message-----
>> From: marcelo bagnulo braun [mailto:[email-masked]]
>> Sent: Wednesday, July 19, 2006 5:57 AM
>> To: Bound, Jim
>> Cc: [email-masked]; Pekka Savola; Iljitsch van Beijnum
>> Subject: Re: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006
>>
>> Hi Jim,
>>
>>
>> El 11/07/2006, a las 17:25, Bound, Jim escribi=F3:
>>
>>> I see this point.  Clearly public or pre-shared PKI has to
>> exist yes.
>>> But enclaves of network users will have this association is the
>>> assumption.  So if we are not in some enclave we would need to join
>>> one to send each other files via IPsec with encrypt.  The
>> enclaves are
>>> being built now.
>>
>>
>> As i understand it, the only way to make the shim6 security
>> based on IPSec is to assume that a global PKI is deployed,
>> including client certificates (i.e. not only server
>> certificates) so that it is possible to secure any-to-any
>> communication.
>>
>>  =46rom what i understand such global pki is not in place yet
>> and it doesn't looks like it will be anytime soon if ever.
>>
>> So, i really don't think it is reasonable to build the security on =
the
>> shim6 relying on such global pki deployment
>>
>> does anybody think that it would be acceptable to build the
>> shim6 security based on the  assumption of a global PKI deployment?
>>
>> Regards, marcelo
>>
>>
>>>
>>> Sorry I missed your point.
>>>
>>> /jim
>>>
>>>> -----Original Message-----
>>>> From: Iljitsch van Beijnum [mailto:[email-masked]]
>>>> Sent: Tuesday, July 11, 2006 10:19 AM
>>>> To: Bound, Jim
>>>> Cc: Pekka Savola; [email-masked]
>>>> Subject: Re: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006
>>>>
>>>> On 11-jul-2006, at 10:13, Bound, Jim wrote:
>>>>
>>>>> IPsec is deployed end-to-end for v4 and v6 in production
>> not sure I
>>>>> agree no one knows how to do this and I think I
>> misunderstood your
>>>>> statement below?  Thanks.
>>>>
>>>> So if I want to send you a file and I want to encrypt it
>> with IPsec,
>>>> how do I do that, without making special arrangements first?
>>>>
>>>> IPsec is only used for VPN tunnels in practice today.
>>>>
>>>
>>
>>
>

Delivery-date: Wed, 19 Jul 2006 15:25:47 +0000
Cc: "Brian E Carpenter" <[email-masked]>, <[email-masked]>, "Joe Abley" <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: IPsec Issue Discussed for Shim6 at IETF Meeting July 10, 2006
Date: Wed, 19 Jul 2006 18:24:39 +0300
To: "Bound, Jim" <[email-masked]>

El 19/07/2006, a las 16:50, Bound, Jim escribi=F3:

> The MIPv6 case is written down and was discussed at a minimum shime6=20=

> needs to add such wording to the spec and have it reviewed by the WG.

The shim6 spec does have some words about this, in particular section=20
1.6 states:

    Layering AH and ESP above the multihoming shim means that IPsec can
    be made to be unaware of locator changes the same way that transport
    protocols can be unaware.  Thus the IPsec security associations
    remain stable even though the locators are changing.  This means =
that
    the IP addresses specified in the selectors should be the ULIDs.

however, it would be possible to add additional detailed description=20
about how would IPSec processing look like in a shimmed environment=20
(whether in the base spec or in the applicability statement)

>   That would help yes.  But, the home agent address is secured with=20
> the mobile node too by IPsec.

i was not cosnidering the communication with the HA but directly with=20
the CN using RO mode

>  Making this word change in the spec and having a discussion would be=20=

> progress for sure, and we can then at least discuss security=20
> ramifications.  If you go to my very first mail on this the first=20
> input is that the text discussing this part of shim6 is not clear=20
> fixing that is a priori for sure then we can go to next steps.  But=20
> the MIPv6 case is not out of band signaling per se because the home=20
> agent address was kept with the node when it roamed and did not have=20=

> to be securely negotiated after going mobile.  That is a different=20
> network security scenario and property than CGA in shim6.
>

indeed the communication between the HA and the mobile node is a=20
different scenario, but the communication between the MN and the CN in=20=

RO mode is exactly the same scenario than a shim6 communication AFAICT=20=

and it uses the exact same type of out-band signalling, agree?

regards, marcelo

> /jim
>
>> -----Original Message-----
>> From: marcelo bagnulo braun [mailto:[email-masked]]
>> Sent: Wednesday, July 19, 2006 4:32 AM
>> To: Bound, Jim
>> Cc: Brian E Carpenter; [email-masked]; Joe Abley
>> Subject: Re: IPsec Issue Discussed for Shim6 at IETF Meeting
>> July 10, 2006
>>
>> Hi Jim,
>>
>>
>> El 18/07/2006, a las 18:23, Bound, Jim escribi=F3:
>>
>>> Brian and Joe, (thanks).
>>>
>>> If ULID is both ID and Locator that is fine.  Here is more
>> on my issue
>>> and sorry for late response traveling and email is a pain.
>>>
>>> If when the packet is transmitted and the Locator is not
>> the ULID, AND
>>> the ULID is the SA to decrypt the packet is my concern.
>>>
>>> Here is why.
>>>
>>> First that means some form of out-of-band signaling was done to
>>> identify a Locator to a ULID so the decrypt can even
>> happen. This is
>>> out of scope for the IPsec architecture we clearly did not support
>>> out-of-band singaling for IPsec all the way back to the
>> 1994 or 1995
>>> Danvers IETF meeting when we decided to move to IPsec.
>>>
>>> Second I am concerned about implementations that now assume
>> per IPsec
>>> that in fact the Locator is the SA in the arriving or
>> sending packet
>>> to another node.
>>>
>>> Does that help?
>>>
>>
>>
>> but isn't the case that there are existent protocols that
>> also use an out of band signaling that you mention below the
>> IPSec layer in a similar fashion that the shim6 protocol (and
>> i think there are valid reasons why to do that)
>>
>> Let's consider that case of Mobile IPv6 and in particular the
>> case of RO mode
>>
>> Suppose that we have a node M that is communicating with a node C
>>
>> Suppose that node M has a stable address IPH and that node C
>> has an address IPC
>>
>> Suppose that M and C have established and IPSec protected
>> communication using IPH and IPC (hence the IPSec SA contains
>> IPH and IPC)
>>
>> Suppose now that node M (which is a mobile node running
>> MIPv6) moves and it gets a new address CoA
>>
>> Suppose that the communication between M and C is in route
>> optimization mode
>>
>> Consider the case of packet flowing from M to node C.
>> In this case, packets flowing from M to the mobile node C
>> will be carrying CoA in the src address field of the IPv6
>> header and they will carry the HoA dst option containing the
>> IPH address In addition, the packets carry the ESP/AH header.
>> Since the IPSec SA contains IPH (and not CoA) the IPH must be
>> restored by the MIPv6 layer before the processing.
>>
>> Actually, RFC3775 states in page 110 that:
>>
>>        If route optimization is in use, the mobile node inserts a =
Home
>>        Address destination option into the packet, replacing
>> the Source
>>        Address in the packet's IP header with the care-of address =
used
>>        with this correspondent node, as described in Section
>> 11.3.1.  The
>>        Destination Options header in which the Home Address
>> destination
>>        option is inserted MUST appear in the packet after the routing
>>        header, if present, and before the IPsec (AH [5] or ESP [6])
>>        header, so that the Home Address destination option is
>> processed
>>        by the destination node before the IPsec header is processed.
>>
>> This basically means, that upon reception, MIPv6 will restore
>> the original IPH address before the IPSec processing, so that
>> the original addresses/identifers can be used to search the IPSec SA.
>>
>> As far as i can see this is exactly the same behaviour that
>> is being proposed for the shim, or do you see any difference
>> between the case of the shim6 and mipv6?
>>
>> Regards, marcelo
>>
>>
>>
>>
>>> Thanks
>>> /jim
>>>
>>>> -----Original Message-----
>>>> From: Brian E Carpenter [mailto:[email-masked]]
>>>> Sent: Tuesday, July 18, 2006 11:04 AM
>>>> To: Joe Abley
>>>> Cc: Bound, Jim; [email-masked]
>>>> Subject: Re: IPsec Issue Discussed for Shim6 at IETF
>> Meeting July 10,
>>>> 2006
>>>>
>>>> Joe Abley wrote:
>>>>>
>>>>> On 18-Jul-2006, at 07:24, Brian E Carpenter wrote:
>>>>>
>>>>>> Sure, in my shim6 world the ULID is an initially valid locator.
>>>>>> Of course, it may become invalid dynamically during the
>>>> course of a
>>>>>> session, but that will not invalidate the SA as far as I can see.
>>>>>
>>>>>
>>>>> Surely the ULID is static for the lifetime of a session,
>>>> regardless
>>>>> of what happens to the locator set?
>>>>
>>>> Exactly my point; but if the ULID ceases to work as a
>> locator, it no
>>>> longer has its initial duality as both an ID and a locator.
>>>> And I want to be sure than Jim doesn't see a problem in that.
>>>>
>>>>      Brian
>>>>
>>>
>>
>>
>

Delivery-date: Wed, 19 Jul 2006 14:39:08 +0000
Content-class: urn:content-classes:message
Subject: RE: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006 
Date: Wed, 19 Jul 2006 10:37:36 -0400
From: "Bound, Jim" <[email-masked]>
To: "Fiumano, Michael F [NTK]" <[email-masked]>, "marcelo bagnulo braun" <[email-masked]>, "Francis Dupont" <[email-masked]>
Cc: <[email-masked]>, "Pekka Savola" <[email-masked]>, "Iljitsch van Beijnum" <[email-masked]>

I don't think we can ever require that and nor have we in any spec.  =
Preshared keys work but the point is that is a market decision not an =
IETF decision.  We build the protocols with operational guidance in some =
cases whether or how they are used in the market is a red herring for =
our work to keep moving forward.  We are more like scientists not =
marketing and business people.
/jim=20

> -----Original Message-----
> From: Fiumano, Michael F [NTK] [mailto:[email-masked]]=20
> Sent: Wednesday, July 19, 2006 10:25 AM
> To: Bound, Jim; marcelo bagnulo braun; Francis Dupont
> Cc: [email-masked]; Pekka Savola; Iljitsch van Beijnum
> Subject: RE: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006=20
>=20
> Very few who use IPSec also use PKI.  Most use a pre-shared=20
> key.  I hope that no one is requiring that a PKI be in place=20
> in order to use shim6.
>=20
> Michael Fiumano
> Senior Network Engineer
> IP Core Infrastructure
> 703-689-5875 Wk
> 703-598-2434 Cel
> [email-masked]
>=20
>=20
>=20
>=20
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On=20
> Behalf Of Bound, Jim
> Sent: Wednesday, July 19, 2006 9:55 AM
> To: marcelo bagnulo braun; Francis Dupont
> Cc: [email-masked]; Pekka Savola; Iljitsch van Beijnum
> Subject: RE: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006=20
>=20
> I was assuming the node regardless will use IPsec as=20
> required.  Thus it really is not shime6 concern.  But I do=20
> not believe no one will not deploy IPsec because of PKI that=20
> is simply not true.  IPsec is deployed today with PKI.
>=20
> /jim=20
>=20
> > -----Original Message-----
> > From: marcelo bagnulo braun [mailto:[email-masked]]
> > Sent: Wednesday, July 19, 2006 8:04 AM
> > To: Francis Dupont
> > Cc: [email-masked]; Bound, Jim; Pekka Savola; Iljitsch van Beijnum
> > Subject: Re: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006
> >=20
> >=20
> > El 19/07/2006, a las 14:38, Francis Dupont escribi=F3:
> >=20
> > > I can't see where Jim proposed to base the Shim6 security
> > on IPsec...
> >=20
> > in message http://ops.ietf.org/lists/shim6/msg01511.html
> >=20
> > it is stated that:
> >=20
> > Suggestion is to simply embed ULIDs within the data payload=20
> with new=20
> > option and secure all communications at least for now for IP layer=20
> > communcatiions with IPsec encryption based on locator pair.
> >=20
> > meaning to use IPSec as an alternative to HBA security
> >=20
> > > (something which is known to require the impossible and even not=20
> > > desirable global PKI :-)
> > >
> >=20
> > exactly
> >=20
> > Regards, marcelo
> >=20
> >=20
> > > Regards
> > >
> > > [email-masked]
> > >
> >=20
> >=20
>=20
>=20
>=20
>=20

Delivery-date: Wed, 19 Jul 2006 14:26:29 +0000
Content-class: urn:content-classes:message
Subject: RE: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006 
Date: Wed, 19 Jul 2006 09:24:43 -0500
From: "Fiumano, Michael F [NTK]" <[email-masked]>
To: "Bound, Jim" <[email-masked]>, "marcelo bagnulo braun" <[email-masked]>, "Francis Dupont" <[email-masked]>
Cc: <[email-masked]>, "Pekka Savola" <[email-masked]>, "Iljitsch van Beijnum" <[email-masked]>

Very few who use IPSec also use PKI.  Most use a pre-shared key.  I hope =
that no one is requiring that a PKI be in place in order to use shim6.

Michael Fiumano
Senior Network Engineer
IP Core Infrastructure
703-689-5875 Wk
703-598-2434 Cel
[email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of =
Bound, Jim
Sent: Wednesday, July 19, 2006 9:55 AM
To: marcelo bagnulo braun; Francis Dupont
Cc: [email-masked]; Pekka Savola; Iljitsch van Beijnum
Subject: RE: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006=20

I was assuming the node regardless will use IPsec as required.  Thus it =
really is not shime6 concern.  But I do not believe no one will not =
deploy IPsec because of PKI that is simply not true.  IPsec is deployed =
today with PKI.

/jim=20

> -----Original Message-----
> From: marcelo bagnulo braun [mailto:[email-masked]]=20
> Sent: Wednesday, July 19, 2006 8:04 AM
> To: Francis Dupont
> Cc: [email-masked]; Bound, Jim; Pekka Savola; Iljitsch van Beijnum
> Subject: Re: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006=20
>=20
>=20
> El 19/07/2006, a las 14:38, Francis Dupont escribi=F3:
>=20
> > I can't see where Jim proposed to base the Shim6 security=20
> on IPsec...
>=20
> in message http://ops.ietf.org/lists/shim6/msg01511.html
>=20
> it is stated that:
>=20
> Suggestion is to simply embed ULIDs within the data payload=20
> with new option and secure all communications at least for=20
> now for IP layer communcatiions with IPsec encryption based=20
> on locator pair.
>=20
> meaning to use IPSec as an alternative to HBA security
>=20
> > (something which is known to require the impossible and even not=20
> > desirable global PKI :-)
> >
>=20
> exactly
>=20
> Regards, marcelo
>=20
>=20
> > Regards
> >
> > [email-masked]
> >
>=20
>=20

Delivery-date: Wed, 19 Jul 2006 14:20:29 +0000
Content-class: urn:content-classes:message
Subject: Security Module for shim6 or hip really
Date: Wed, 19 Jul 2006 10:19:56 -0400
From: "Bound, Jim" <[email-masked]>
To: <[email-masked]>

A suggestion proposed at the Montreal IETF SHIM6 WG meeting was to treat
the security of ULIDs as module (abstractly speaking) for SHIM6 where
the user or implementer can plug in different solutions.  We would
abstract out ULID processing for security so that multiple solutions
could be used.  Each solution would be its own IETF draft specification
and IETF discussion with close collaboration with the IETF Security
Area.  I think this would be doing proper engineering diligence for this
problem and we can explore HBA, TLS, IPsec and even other options.  This
also would permit the shim6 spec to move forward and provide a security
note in the spec and avoid the in process IPR debate for CGA.

Thoughts?

/jim

Delivery-date: Wed, 19 Jul 2006 14:14:56 +0000
Content-class: urn:content-classes:message
Subject: RE: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006
Date: Wed, 19 Jul 2006 10:14:13 -0400
From: "Bound, Jim" <[email-masked]>
To: "marcelo bagnulo braun" <[email-masked]>, "Iljitsch van Beijnum" <[email-masked]>
Cc: "shim6-wg" <[email-masked]>

also performance of IPsec has much to do with the encrypt algorithm such =
as use with AES has different capabilities from test results from =
different suppliers.
/jim=20

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On=20
> Behalf Of marcelo bagnulo braun
> Sent: Wednesday, July 19, 2006 9:40 AM
> To: Iljitsch van Beijnum
> Cc: shim6-wg
> Subject: Re: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006
>=20
>=20
> El 19/07/2006, a las 16:02, Iljitsch van Beijnum escribi=F3:
>=20
> > On 19-jul-2006, at 14:39, marcelo bagnulo braun wrote:
> >
> >> server certificate are more widely used than client certificates=20
> >> indeed, but in the case of the shim6 we need certificates for both=20
> >> ends, so what do we do for securing the client?
> >
> > Why? If one end has a certificate the communication can be secure.
> >
>=20
> but you still can provide identifier ownership proof, right?
>=20
> I mean, in order to avoid future attacks agaisnt the identity=20
> we need more than just a secure channel but a secure binding=20
> between the identifier and something that canbe used to prove=20
> ownership (like a public/private key pair)
>=20
> so, such scheme would result in the posibilty of identity=20
> hijacking attacks
>=20
> in order to avoid those, you need something else, like client=20
> certificates
>=20
>=20
> >> besides, currently deployed certificates provide binding between=20
> >> FQDNs and public key.... while in the shim6 we need=20
> binding between=20
> >> IP addresses and public keys, meaning than currently deployed=20
> >> certificates are not good
> >
> > Yes, this involves a trip to the DNS...
> >
>=20
> so, now the cost is:
> - public key crypto (for the locator set validation and the=20
> certificates)
> - added overhead (because of the transmision of the cert chain)
> - latency because of the dns query
>=20
> >> in addition, using certificates and public key crypto is much more=20
> >> expensive than CGAs, since they would involve public key=20
> operations=20
> >> not only for the validation of the locator set (as in CGA)=20
> but also=20
> >> for the validation of the certificates themselves (and this costs=20
> >> grows if the certification chain is long). In addition,=20
> there is the=20
> >> overhead due to the transmission of the certificates in=20
> the protocol=20
> >> itself, including all the certificates in the cert chain,=20
> which may=20
> >> even not fit in a single packet so we may end up neededing to send=20
> >> multi-packet messages.
> >
> >> and all this for every shimmed communication....
> >
> > This is certainly true. On the other hand, if the communication is=20
> > already protected with TLS the _additional_ overhead isn't much.
> >
> > Also, I think it would make sense to do the shim=20
> negotiation inside a=20
> > TLS protected TCP session, which should handle all the packet size=20
> > issues.
> >
> >> i thought that one of the key goals in the shim6 design was=20
> >> efficiency.... such an approach would really move us apart=20
> from the=20
> >> efficiency path...
> >
> > HBA is much more efficient so that should stay security=20
> option #1, but=20
> > it would certainly be nice to have an alternative that=20
> allows easier=20
> > implementation of shim6 proxies
>=20
> this would indeed be a nice feature, but i would still need to=20
> understand how it would work with certificates...
>=20
> >  and lets people avoid the patent issues if they want.
> >
> >
>=20
> but if the HBA is the defaut sec mechanism, then the IPR issues are=20
> still the same, since there is the need to implement it in any case
>=20
> Regards, marcelo
>=20
>=20
>=20
>=20

Delivery-date: Wed, 19 Jul 2006 14:14:01 +0000
Content-class: urn:content-classes:message
Subject: RE: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006
Date: Wed, 19 Jul 2006 10:13:15 -0400
From: "Bound, Jim" <[email-masked]>
To: "Iljitsch van Beijnum" <[email-masked]>, "marcelo bagnulo braun" <[email-masked]>
Cc: "shim6-wg" <[email-masked]>

You can also assume the security is already protected with Ipsec. =20
/jim=20

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On=20
> Behalf Of Iljitsch van Beijnum
> Sent: Wednesday, July 19, 2006 9:02 AM
> To: marcelo bagnulo braun
> Cc: shim6-wg
> Subject: Re: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006
>=20
> On 19-jul-2006, at 14:39, marcelo bagnulo braun wrote:
>=20
> > server certificate are more widely used than client certificates=20
> > indeed, but in the case of the shim6 we need certificates for both=20
> > ends, so what do we do for securing the client?
>=20
> Why? If one end has a certificate the communication can be secure.
>=20
> > besides, currently deployed certificates provide binding=20
> between FQDNs=20
> > and public key.... while in the shim6 we need binding between IP=20
> > addresses and public keys, meaning than currently deployed=20
> > certificates are not good
>=20
> Yes, this involves a trip to the DNS...
>=20
> > in addition, using certificates and public key crypto is much more=20
> > expensive than CGAs, since they would involve public key operations=20
> > not only for the validation of the locator set (as in CGA) but also=20
> > for the validation of the certificates themselves (and this costs=20
> > grows if the certification chain is long). In addition,=20
> there is the=20
> > overhead due to the transmission of the certificates in the=20
> protocol=20
> > itself, including all the certificates in the cert chain, which may=20
> > even not fit in a single packet so we may end up neededing to send=20
> > multi-packet messages.
>=20
> > and all this for every shimmed communication....
>=20
> This is certainly true. On the other hand, if the=20
> communication is already protected with TLS the _additional_=20
> overhead isn't much.
>=20
> Also, I think it would make sense to do the shim negotiation=20
> inside a TLS protected TCP session, which should handle all=20
> the packet size issues.
>=20
> > i thought that one of the key goals in the shim6 design was=20
> > efficiency.... such an approach would really move us apart from the=20
> > efficiency path...
>=20
> HBA is much more efficient so that should stay security=20
> option #1, but it would certainly be nice to have an=20
> alternative that allows easier implementation of shim6=20
> proxies and lets people avoid the patent issues if they want.
>=20
>=20

Delivery-date: Wed, 19 Jul 2006 13:56:36 +0000
Content-class: urn:content-classes:message
Subject: RE: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006 
Date: Wed, 19 Jul 2006 09:55:17 -0400
From: "Bound, Jim" <[email-masked]>
To: "marcelo bagnulo braun" <[email-masked]>, "Francis Dupont" <[email-masked]>
Cc: <[email-masked]>, "Pekka Savola" <[email-masked]>, "Iljitsch van Beijnum" <[email-masked]>

I was assuming the node regardless will use IPsec as required.  Thus it =
really is not shime6 concern.  But I do not believe no one will not =
deploy IPsec because of PKI that is simply not true.  IPsec is deployed =
today with PKI.

/jim=20

> -----Original Message-----
> From: marcelo bagnulo braun [mailto:[email-masked]]=20
> Sent: Wednesday, July 19, 2006 8:04 AM
> To: Francis Dupont
> Cc: [email-masked]; Bound, Jim; Pekka Savola; Iljitsch van Beijnum
> Subject: Re: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006=20
>=20
>=20
> El 19/07/2006, a las 14:38, Francis Dupont escribi=F3:
>=20
> > I can't see where Jim proposed to base the Shim6 security=20
> on IPsec...
>=20
> in message http://ops.ietf.org/lists/shim6/msg01511.html
>=20
> it is stated that:
>=20
> Suggestion is to simply embed ULIDs within the data payload=20
> with new option and secure all communications at least for=20
> now for IP layer communcatiions with IPsec encryption based=20
> on locator pair.
>=20
> meaning to use IPSec as an alternative to HBA security
>=20
> > (something which is known to require the impossible and even not=20
> > desirable global PKI :-)
> >
>=20
> exactly
>=20
> Regards, marcelo
>=20
>=20
> > Regards
> >
> > [email-masked]
> >
>=20
>=20

Delivery-date: Wed, 19 Jul 2006 13:54:13 +0000
Content-class: urn:content-classes:message
Subject: RE: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006 
Date: Wed, 19 Jul 2006 09:53:35 -0400
From: "Bound, Jim" <[email-masked]>
To: <[email-masked]>, "marcelo bagnulo braun" <[email-masked]>
Cc: <[email-masked]>, "Pekka Savola" <[email-masked]>, "Iljitsch van Beijnum" <[email-masked]>

Correct I did not suggest that at this time.
/jim=20

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]=20
> Sent: Wednesday, July 19, 2006 7:39 AM
> To: marcelo bagnulo braun
> Cc: Bound, Jim; [email-masked]; Pekka Savola; Iljitsch van Beijnum
> Subject: Re: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006=20
>=20
> I can't see where Jim proposed to base the Shim6 security on IPsec...
> (something which is known to require the impossible and even=20
> not desirable global PKI :-)
>=20
> Regards
>   =20
> [email-masked]
>=20

Delivery-date: Wed, 19 Jul 2006 13:53:21 +0000
Content-class: urn:content-classes:message
Subject: RE: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006
Date: Wed, 19 Jul 2006 09:52:01 -0400
From: "Bound, Jim" <[email-masked]>
To: "marcelo bagnulo braun" <[email-masked]>
Cc: <[email-masked]>, "Pekka Savola" <[email-masked]>, "Iljitsch van Beijnum" <[email-masked]>

Hi Marcello,

Well my view is specs cannot make assumptions about market deployment =
the question first to ask is would IPsec work.  None of us have a =
crystal ball and our engineering work here is usually focused on the =
protocol behavior and that it does no harm and does not cause =
interoperability problems.

/jim=20

> -----Original Message-----
> From: marcelo bagnulo braun [mailto:[email-masked]]=20
> Sent: Wednesday, July 19, 2006 5:57 AM
> To: Bound, Jim
> Cc: [email-masked]; Pekka Savola; Iljitsch van Beijnum
> Subject: Re: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006
>=20
> Hi Jim,
>=20
>=20
> El 11/07/2006, a las 17:25, Bound, Jim escribi=F3:
>=20
> > I see this point.  Clearly public or pre-shared PKI has to=20
> exist yes.
> > But enclaves of network users will have this association is the=20
> > assumption.  So if we are not in some enclave we would need to join=20
> > one to send each other files via IPsec with encrypt.  The=20
> enclaves are=20
> > being built now.
>=20
>=20
> As i understand it, the only way to make the shim6 security=20
> based on IPSec is to assume that a global PKI is deployed,=20
> including client certificates (i.e. not only server=20
> certificates) so that it is possible to secure any-to-any=20
> communication.
>=20
>  From what i understand such global pki is not in place yet=20
> and it doesn't looks like it will be anytime soon if ever.
>=20
> So, i really don't think it is reasonable to build the security on the
> shim6 relying on such global pki deployment
>=20
> does anybody think that it would be acceptable to build the=20
> shim6 security based on the  assumption of a global PKI deployment?
>=20
> Regards, marcelo
>=20
>=20
> >
> > Sorry I missed your point.
> >
> > /jim
> >
> >> -----Original Message-----
> >> From: Iljitsch van Beijnum [mailto:[email-masked]]
> >> Sent: Tuesday, July 11, 2006 10:19 AM
> >> To: Bound, Jim
> >> Cc: Pekka Savola; [email-masked]
> >> Subject: Re: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006
> >>
> >> On 11-jul-2006, at 10:13, Bound, Jim wrote:
> >>
> >>> IPsec is deployed end-to-end for v4 and v6 in production=20
> not sure I=20
> >>> agree no one knows how to do this and I think I=20
> misunderstood your=20
> >>> statement below?  Thanks.
> >>
> >> So if I want to send you a file and I want to encrypt it=20
> with IPsec,=20
> >> how do I do that, without making special arrangements first?
> >>
> >> IPsec is only used for VPN tunnels in practice today.
> >>
> >
>=20
>=20

Delivery-date: Wed, 19 Jul 2006 13:51:16 +0000
Content-class: urn:content-classes:message
Subject: RE: IPsec Issue Discussed for Shim6 at IETF Meeting July 10, 2006
Date: Wed, 19 Jul 2006 09:50:16 -0400
From: "Bound, Jim" <[email-masked]>
To: "marcelo bagnulo braun" <[email-masked]>
Cc: "Brian E Carpenter" <[email-masked]>, <[email-masked]>, "Joe Abley" <[email-masked]>

The MIPv6 case is written down and was discussed at a minimum shime6 =
needs to add such wording to the spec and have it reviewed by the WG.  =
That would help yes.  But, the home agent address is secured with the =
mobile node too by IPsec.  Making this word change in the spec and =
having a discussion would be progress for sure, and we can then at least =
discuss security ramifications.  If you go to my very first mail on this =
the first input is that the text discussing this part of shim6 is not =
clear fixing that is a priori for sure then we can go to next steps.  =
But the MIPv6 case is not out of band signaling per se because the home =
agent address was kept with the node when it roamed and did not have to =
be securely negotiated after going mobile.  That is a different network =
security scenario and property than CGA in shim6.

/jim=20

> -----Original Message-----
> From: marcelo bagnulo braun [mailto:[email-masked]]=20
> Sent: Wednesday, July 19, 2006 4:32 AM
> To: Bound, Jim
> Cc: Brian E Carpenter; [email-masked]; Joe Abley
> Subject: Re: IPsec Issue Discussed for Shim6 at IETF Meeting=20
> July 10, 2006
>=20
> Hi Jim,
>=20
>=20
> El 18/07/2006, a las 18:23, Bound, Jim escribi=F3:
>=20
> > Brian and Joe, (thanks).
> >
> > If ULID is both ID and Locator that is fine.  Here is more=20
> on my issue=20
> > and sorry for late response traveling and email is a pain.
> >
> > If when the packet is transmitted and the Locator is not=20
> the ULID, AND=20
> > the ULID is the SA to decrypt the packet is my concern.
> >
> > Here is why.
> >
> > First that means some form of out-of-band signaling was done to=20
> > identify a Locator to a ULID so the decrypt can even=20
> happen. This is=20
> > out of scope for the IPsec architecture we clearly did not support=20
> > out-of-band singaling for IPsec all the way back to the=20
> 1994 or 1995=20
> > Danvers IETF meeting when we decided to move to IPsec.
> >
> > Second I am concerned about implementations that now assume=20
> per IPsec=20
> > that in fact the Locator is the SA in the arriving or=20
> sending packet=20
> > to another node.
> >
> > Does that help?
> >
>=20
>=20
> but isn't the case that there are existent protocols that=20
> also use an out of band signaling that you mention below the=20
> IPSec layer in a similar fashion that the shim6 protocol (and=20
> i think there are valid reasons why to do that)
>=20
> Let's consider that case of Mobile IPv6 and in particular the=20
> case of RO mode
>=20
> Suppose that we have a node M that is communicating with a node C
>=20
> Suppose that node M has a stable address IPH and that node C=20
> has an address IPC
>=20
> Suppose that M and C have established and IPSec protected=20
> communication using IPH and IPC (hence the IPSec SA contains=20
> IPH and IPC)
>=20
> Suppose now that node M (which is a mobile node running=20
> MIPv6) moves and it gets a new address CoA
>=20
> Suppose that the communication between M and C is in route=20
> optimization mode
>=20
> Consider the case of packet flowing from M to node C.
> In this case, packets flowing from M to the mobile node C=20
> will be carrying CoA in the src address field of the IPv6=20
> header and they will carry the HoA dst option containing the=20
> IPH address In addition, the packets carry the ESP/AH header.=20
> Since the IPSec SA contains IPH (and not CoA) the IPH must be=20
> restored by the MIPv6 layer before the processing.
>=20
> Actually, RFC3775 states in page 110 that:
>=20
>        If route optimization is in use, the mobile node inserts a Home
>        Address destination option into the packet, replacing=20
> the Source
>        Address in the packet's IP header with the care-of address used
>        with this correspondent node, as described in Section=20
> 11.3.1.  The
>        Destination Options header in which the Home Address=20
> destination
>        option is inserted MUST appear in the packet after the routing
>        header, if present, and before the IPsec (AH [5] or ESP [6])
>        header, so that the Home Address destination option is=20
> processed
>        by the destination node before the IPsec header is processed.
>=20
> This basically means, that upon reception, MIPv6 will restore=20
> the original IPH address before the IPSec processing, so that=20
> the original addresses/identifers can be used to search the IPSec SA.
>=20
> As far as i can see this is exactly the same behaviour that=20
> is being proposed for the shim, or do you see any difference=20
> between the case of the shim6 and mipv6?
>=20
> Regards, marcelo
>=20
>=20
>=20
>=20
> > Thanks
> > /jim
> >
> >> -----Original Message-----
> >> From: Brian E Carpenter [mailto:[email-masked]]
> >> Sent: Tuesday, July 18, 2006 11:04 AM
> >> To: Joe Abley
> >> Cc: Bound, Jim; [email-masked]
> >> Subject: Re: IPsec Issue Discussed for Shim6 at IETF=20
> Meeting July 10,=20
> >> 2006
> >>
> >> Joe Abley wrote:
> >>>
> >>> On 18-Jul-2006, at 07:24, Brian E Carpenter wrote:
> >>>
> >>>> Sure, in my shim6 world the ULID is an initially valid locator.
> >>>> Of course, it may become invalid dynamically during the
> >> course of a
> >>>> session, but that will not invalidate the SA as far as I can see.
> >>>
> >>>
> >>> Surely the ULID is static for the lifetime of a session,
> >> regardless
> >>> of what happens to the locator set?
> >>
> >> Exactly my point; but if the ULID ceases to work as a=20
> locator, it no=20
> >> longer has its initial duality as both an ID and a locator.
> >> And I want to be sure than Jim doesn't see a problem in that.
> >>
> >>      Brian
> >>
> >
>=20
>=20

Delivery-date: Wed, 19 Jul 2006 13:40:43 +0000
Cc: shim6-wg <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006
Date: Wed, 19 Jul 2006 16:39:51 +0300
To: Iljitsch van Beijnum <[email-masked]>

El 19/07/2006, a las 16:02, Iljitsch van Beijnum escribi=F3:

> On 19-jul-2006, at 14:39, marcelo bagnulo braun wrote:
>
>> server certificate are more widely used than client certificates=20
>> indeed, but in the case of the shim6 we need certificates for both=20
>> ends, so what do we do for securing the client?
>
> Why? If one end has a certificate the communication can be secure.
>

but you still can provide identifier ownership proof, right?

I mean, in order to avoid future attacks agaisnt the identity we need=20
more than just a secure channel but a secure binding between the=20
identifier and something that canbe used to prove ownership (like a=20
public/private key pair)

so, such scheme would result in the posibilty of identity hijacking=20
attacks

in order to avoid those, you need something else, like client=20
certificates

>> besides, currently deployed certificates provide binding between=20
>> FQDNs and public key.... while in the shim6 we need binding between=20=

>> IP addresses and public keys, meaning than currently deployed=20
>> certificates are not good
>
> Yes, this involves a trip to the DNS...
>

so, now the cost is:
- public key crypto (for the locator set validation and the=20
certificates)
- added overhead (because of the transmision of the cert chain)
- latency because of the dns query

>> in addition, using certificates and public key crypto is much more=20
>> expensive than CGAs, since they would involve public key operations=20=

>> not only for the validation of the locator set (as in CGA) but also=20=

>> for the validation of the certificates themselves (and this costs=20
>> grows if the certification chain is long). In addition, there is the=20=

>> overhead due to the transmission of the certificates in the protocol=20=

>> itself, including all the certificates in the cert chain, which may=20=

>> even not fit in a single packet so we may end up neededing to send=20
>> multi-packet messages.
>
>> and all this for every shimmed communication....
>
> This is certainly true. On the other hand, if the communication is=20
> already protected with TLS the _additional_ overhead isn't much.
>
> Also, I think it would make sense to do the shim negotiation inside a=20=

> TLS protected TCP session, which should handle all the packet size=20
> issues.
>
>> i thought that one of the key goals in the shim6 design was=20
>> efficiency.... such an approach would really move us apart from the=20=

>> efficiency path...
>
> HBA is much more efficient so that should stay security option #1, but=20=

> it would certainly be nice to have an alternative that allows easier=20=

> implementation of shim6 proxies

this would indeed be a nice feature, but i would still need to=20
understand how it would work with certificates...

>  and lets people avoid the patent issues if they want.
>
>

but if the HBA is the defaut sec mechanism, then the IPR issues are=20
still the same, since there is the need to implement it in any case

Regards, marcelo

Delivery-date: Wed, 19 Jul 2006 13:02:53 +0000
Cc: shim6-wg <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006
Date: Wed, 19 Jul 2006 15:02:05 +0200
To: marcelo bagnulo braun <[email-masked]>

On 19-jul-2006, at 14:39, marcelo bagnulo braun wrote:

> server certificate are more widely used than client certificates  
> indeed, but in the case of the shim6 we need certificates for both  
> ends, so what do we do for securing the client?

Why? If one end has a certificate the communication can be secure.

> besides, currently deployed certificates provide binding between  
> FQDNs and public key.... while in the shim6 we need binding between  
> IP addresses and public keys, meaning than currently deployed  
> certificates are not good

Yes, this involves a trip to the DNS...

> in addition, using certificates and public key crypto is much more  
> expensive than CGAs, since they would involve public key operations  
> not only for the validation of the locator set (as in CGA) but also  
> for the validation of the certificates themselves (and this costs  
> grows if the certification chain is long). In addition, there is  
> the overhead due to the transmission of the certificates in the  
> protocol itself, including all the certificates in the cert chain,  
> which may even not fit in a single packet so we may end up  
> neededing to send multi-packet messages.

> and all this for every shimmed communication....

This is certainly true. On the other hand, if the communication is  
already protected with TLS the _additional_ overhead isn't much.

Also, I think it would make sense to do the shim negotiation inside a  
TLS protected TCP session, which should handle all the packet size  
issues.

> i thought that one of the key goals in the shim6 design was  
> efficiency.... such an approach would really move us apart from the  
> efficiency path...

HBA is much more efficient so that should stay security option #1,  
but it would certainly be nice to have an alternative that allows  
easier implementation of shim6 proxies and lets people avoid the  
patent issues if they want.

Delivery-date: Wed, 19 Jul 2006 12:39:40 +0000
Cc: shim6-wg <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006
Date: Wed, 19 Jul 2006 15:39:12 +0300
To: Iljitsch van Beijnum <[email-masked]>

Hi Iljitsch,

El 19/07/2006, a las 15:30, Iljitsch van Beijnum escribi=F3:

> On 19-jul-2006, at 11:57, marcelo bagnulo braun wrote:
>
>> As i understand it, the only way to make the shim6 security based on=20=

>> IPSec is to assume that a global PKI is deployed, including client=20
>> certificates (i.e. not only server certificates) so that it is=20
>> possible to secure any-to-any communication.
>
>> =46rom what i understand such global pki is not in place yet and it=20=

>> doesn't looks like it will be anytime soon if ever. So, i really=20
>> don't think it is reasonable to build the security on the shim6=20
>> relying on such global pki deployment
>
>> does anybody think that it would be acceptable to build the shim6=20
>> security based on the  assumption of a global PKI deployment?
>
> Note that server certificates are relatively widespread, hence my=20
> suggestion to adopt TLS as an alternative security mechanism in=20
> addition to HBA.
>

server certificate are more widely used than client certificates=20
indeed, but in the case of the shim6 we need certificates for both=20
ends, so what do we do for securing the client?

besides, currently deployed certificates provide binding between FQDNs=20=

and public key.... while in the shim6 we need binding between IP=20
addresses and public keys, meaning than currently deployed certificates=20=

are not good (at least not in the general case and additional=20
assumptions about the existance of a FQDN is needed and the associated=20=

implications...)

in addition, using certificates and public key crypto is much more=20
expensive than CGAs, since they would involve public key operations not=20=

only for the validation of the locator set (as in CGA) but also for the=20=

validation of the certificates themselves (and this costs grows if the=20=

certification chain is long). In addition, there is the overhead due to=20=

the transmission of the certificates in the protocol itself, including=20=

all the certificates in the cert chain, which may even not fit in a=20
single packet so we may end up neededing to send multi-packet messages.

and all this for every shimmed communication....

i thought that one of the key goals in the shim6 design was=20
efficiency.... such an approach would really move us apart from the=20
efficiency path...

regards, marcelo

> It would be helpful to determine whether we as a wg want this or not.
>
> Obviously it's also possible to use IPsec rather than TLS but I don't=20=

> see how this would benefit us greatly and IPsec has proven hard to=20
> deploy until now.
>

Delivery-date: Wed, 19 Jul 2006 12:30:48 +0000
Cc: shim6-wg <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006
Date: Wed, 19 Jul 2006 14:30:00 +0200
To: marcelo bagnulo braun <[email-masked]>

On 19-jul-2006, at 11:57, marcelo bagnulo braun wrote:

> As i understand it, the only way to make the shim6 security based  
> on IPSec is to assume that a global PKI is deployed, including  
> client certificates (i.e. not only server certificates) so that it  
> is possible to secure any-to-any communication.

> From what i understand such global pki is not in place yet and it  
> doesn't looks like it will be anytime soon if ever. So, i really  
> don't think it is reasonable to build the security on the shim6  
> relying on such global pki deployment

> does anybody think that it would be acceptable to build the shim6  
> security based on the  assumption of a global PKI deployment?

Note that server certificates are relatively widespread, hence my  
suggestion to adopt TLS as an alternative security mechanism in  
addition to HBA.

It would be helpful to determine whether we as a wg want this or not.

Obviously it's also possible to use IPsec rather than TLS but I don't  
see how this would benefit us greatly and IPsec has proven hard to  
deploy until now.

Delivery-date: Wed, 19 Jul 2006 12:05:47 +0000
Cc: [email-masked], "Bound, Jim" <[email-masked]>, "Pekka Savola" <[email-masked]>, "Iljitsch van Beijnum" <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006 
Date: Wed, 19 Jul 2006 15:03:58 +0300
To: Francis Dupont <[email-masked]>

El 19/07/2006, a las 14:38, Francis Dupont escribi=F3:

> I can't see where Jim proposed to base the Shim6 security on IPsec...

in message http://ops.ietf.org/lists/shim6/msg01511.html

it is stated that:

Suggestion is to simply embed ULIDs within the data
payload with new option and secure all communications at least for now
for IP layer communcatiions with IPsec encryption based on locator pair.

meaning to use IPSec as an alternative to HBA security

> (something which is known to require the impossible and even not=20
> desirable
> global PKI :-)
>

exactly

Regards, marcelo

> Regards
>
> [email-masked]
>

Delivery-date: Wed, 19 Jul 2006 09:58:06 +0000
Cc:  <[email-masked]>, "Pekka Savola" <[email-masked]>, "Iljitsch van Beijnum" <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006
Date: Wed, 19 Jul 2006 12:57:21 +0300
To: "Bound, Jim" <[email-masked]>

Hi Jim,

El 11/07/2006, a las 17:25, Bound, Jim escribi=F3:

> I see this point.  Clearly public or pre-shared PKI has to exist yes.
> But enclaves of network users will have this association is the
> assumption.  So if we are not in some enclave we would need to join =
one
> to send each other files via IPsec with encrypt.  The enclaves are=20
> being
> built now.

As i understand it, the only way to make the shim6 security based on=20
IPSec is to assume that a global PKI is deployed, including client=20
certificates (i.e. not only server certificates) so that it is possible=20=

to secure any-to-any communication.

 =46rom what i understand such global pki is not in place yet and it=20
doesn't looks like it will be anytime soon if ever.

So, i really don't think it is reasonable to build the security on the=20=

shim6 relying on such global pki deployment

does anybody think that it would be acceptable to build the shim6=20
security based on the  assumption of a global PKI deployment?

Regards, marcelo

>
> Sorry I missed your point.
>
> /jim
>
>> -----Original Message-----
>> From: Iljitsch van Beijnum [mailto:[email-masked]]
>> Sent: Tuesday, July 11, 2006 10:19 AM
>> To: Bound, Jim
>> Cc: Pekka Savola; [email-masked]
>> Subject: Re: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006
>>
>> On 11-jul-2006, at 10:13, Bound, Jim wrote:
>>
>>> IPsec is deployed end-to-end for v4 and v6 in production not sure I
>>> agree no one knows how to do this and I think I misunderstood your
>>> statement below?  Thanks.
>>
>> So if I want to send you a file and I want to encrypt it with
>> IPsec, how do I do that, without making special arrangements first?
>>
>> IPsec is only used for VPN tunnels in practice today.
>>
>

Delivery-date: Wed, 19 Jul 2006 08:32:38 +0000
Cc: "Brian E Carpenter" <[email-masked]>, <[email-masked]>, "Joe Abley" <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: IPsec Issue Discussed for Shim6 at IETF Meeting July 10, 2006
Date: Wed, 19 Jul 2006 11:31:33 +0300
To: "Bound, Jim" <[email-masked]>

Hi Jim,

El 18/07/2006, a las 18:23, Bound, Jim escribi=F3:

> Brian and Joe, (thanks).
>
> If ULID is both ID and Locator that is fine.  Here is more on my issue
> and sorry for late response traveling and email is a pain.
>
> If when the packet is transmitted and the Locator is not the ULID, AND
> the ULID is the SA to decrypt the packet is my concern.
>
> Here is why.
>
> First that means some form of out-of-band signaling was done to=20
> identify
> a Locator to a ULID so the decrypt can even happen. This is out of=20
> scope
> for the IPsec architecture we clearly did not support out-of-band
> singaling for IPsec all the way back to the 1994 or 1995 Danvers IETF
> meeting when we decided to move to IPsec.
>
> Second I am concerned about implementations that now assume per IPsec
> that in fact the Locator is the SA in the arriving or sending packet =
to
> another node.
>
> Does that help?
>

but isn't the case that there are existent protocols that also use an=20
out of band signaling that you mention below the IPSec layer in a=20
similar fashion that the shim6 protocol (and i think there are valid=20
reasons why to do that)

Let's consider that case of Mobile IPv6 and in particular the case of=20
RO mode

Suppose that we have a node M that is communicating with a node C

Suppose that node M has a stable address IPH and that node C has an=20
address IPC

Suppose that M and C have established and IPSec protected communication=20=

using IPH and IPC (hence the IPSec SA contains IPH and IPC)

Suppose now that node M (which is a mobile node running MIPv6) moves=20
and it gets a new address CoA

Suppose that the communication between M and C is in route optimization=20=

mode

Consider the case of packet flowing from M to node C.
In this case, packets flowing from M to the mobile node C will be=20
carrying CoA in the src address field of the IPv6 header and they will=20=

carry the HoA dst option containing the IPH address
In addition, the packets carry the ESP/AH header. Since the IPSec SA=20
contains IPH (and not CoA) the IPH must be restored by the MIPv6 layer=20=

before the processing.

Actually, RFC3775 states in page 110 that:

       If route optimization is in use, the mobile node inserts a Home
       Address destination option into the packet, replacing the Source
       Address in the packet's IP header with the care-of address used
       with this correspondent node, as described in Section 11.3.1.  =
The
       Destination Options header in which the Home Address destination
       option is inserted MUST appear in the packet after the routing
       header, if present, and before the IPsec (AH [5] or ESP [6])
       header, so that the Home Address destination option is processed
       by the destination node before the IPsec header is processed.

This basically means, that upon reception, MIPv6 will restore the=20
original IPH address before the IPSec processing, so that the original=20=

addresses/identifers can be used to search the IPSec SA.

As far as i can see this is exactly the same behaviour that is being=20
proposed for the shim, or do you see any difference between the case of=20=

the shim6 and mipv6?

Regards, marcelo

> Thanks
> /jim
>
>> -----Original Message-----
>> From: Brian E Carpenter [mailto:[email-masked]]
>> Sent: Tuesday, July 18, 2006 11:04 AM
>> To: Joe Abley
>> Cc: Bound, Jim; [email-masked]
>> Subject: Re: IPsec Issue Discussed for Shim6 at IETF Meeting
>> July 10, 2006
>>
>> Joe Abley wrote:
>>>
>>> On 18-Jul-2006, at 07:24, Brian E Carpenter wrote:
>>>
>>>> Sure, in my shim6 world the ULID is an initially valid locator.
>>>> Of course, it may become invalid dynamically during the
>> course of a
>>>> session, but that will not invalidate the SA as far as I can see.
>>>
>>>
>>> Surely the ULID is static for the lifetime of a session,
>> regardless
>>> of what happens to the locator set?
>>
>> Exactly my point; but if the ULID ceases to work as a
>> locator, it no longer has its initial duality as both an ID
>> and a locator.
>> And I want to be sure than Jim doesn't see a problem in that.
>>
>>      Brian
>>
>

Delivery-date: Tue, 18 Jul 2006 15:23:41 +0000
Content-class: urn:content-classes:message
Subject: RE: IPsec Issue Discussed for Shim6 at IETF Meeting July 10, 2006
Date: Tue, 18 Jul 2006 11:23:10 -0400
From: "Bound, Jim" <[email-masked]>
To: "Brian E Carpenter" <[email-masked]>, "Joe Abley" <[email-masked]>
Cc: <[email-masked]>

Brian and Joe, (thanks).

If ULID is both ID and Locator that is fine.  Here is more on my issue
and sorry for late response traveling and email is a pain.

If when the packet is transmitted and the Locator is not the ULID, AND
the ULID is the SA to decrypt the packet is my concern. =20

Here is why.

First that means some form of out-of-band signaling was done to identify
a Locator to a ULID so the decrypt can even happen. This is out of scope
for the IPsec architecture we clearly did not support out-of-band
singaling for IPsec all the way back to the 1994 or 1995 Danvers IETF
meeting when we decided to move to IPsec.=20

Second I am concerned about implementations that now assume per IPsec
that in fact the Locator is the SA in the arriving or sending packet to
another node.

Does that help?

Thanks
/jim

> -----Original Message-----
> From: Brian E Carpenter [mailto:[email-masked]]=20
> Sent: Tuesday, July 18, 2006 11:04 AM
> To: Joe Abley
> Cc: Bound, Jim; [email-masked]
> Subject: Re: IPsec Issue Discussed for Shim6 at IETF Meeting=20
> July 10, 2006
>=20
> Joe Abley wrote:
> >=20
> > On 18-Jul-2006, at 07:24, Brian E Carpenter wrote:
> >=20
> >> Sure, in my shim6 world the ULID is an initially valid locator.
> >> Of course, it may become invalid dynamically during the=20
> course of a=20
> >> session, but that will not invalidate the SA as far as I can see.
> >=20
> >=20
> > Surely the ULID is static for the lifetime of a session,=20
> regardless =20
> > of what happens to the locator set?
>=20
> Exactly my point; but if the ULID ceases to work as a=20
> locator, it no longer has its initial duality as both an ID=20
> and a locator.
> And I want to be sure than Jim doesn't see a problem in that.
>=20
>      Brian
>=20

Delivery-date: Tue, 18 Jul 2006 15:05:14 +0000
Date: Tue, 18 Jul 2006 17:04:08 +0200
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: Joe Abley <[email-masked]>
CC: "Bound, Jim" <[email-masked]>, [email-masked]
Subject: Re: IPsec Issue Discussed for Shim6 at IETF Meeting July 10, 2006

Joe Abley wrote:
> 
> On 18-Jul-2006, at 07:24, Brian E Carpenter wrote:
> 
>> Sure, in my shim6 world the ULID is an initially valid locator.
>> Of course, it may become invalid dynamically during the course
>> of a session, but that will not invalidate the SA as far as
>> I can see.
> 
> 
> Surely the ULID is static for the lifetime of a session, regardless  of 
> what happens to the locator set?

Exactly my point; but if the ULID ceases to work as a locator,
it no longer has its initial duality as both an ID and a locator.
And I want to be sure than Jim doesn't see a problem in that.

     Brian

Delivery-date: Tue, 18 Jul 2006 13:35:15 +0000
Cc: "Bound, Jim" <[email-masked]>, [email-masked]
From: Joe Abley <[email-masked]>
Subject: Re: IPsec Issue Discussed for Shim6 at IETF Meeting July 10, 2006
Date: Tue, 18 Jul 2006 09:34:29 -0400
To: Brian E Carpenter <[email-masked]>

On 18-Jul-2006, at 07:24, Brian E Carpenter wrote:

> Sure, in my shim6 world the ULID is an initially valid locator.
> Of course, it may become invalid dynamically during the course
> of a session, but that will not invalidate the SA as far as
> I can see.

Surely the ULID is static for the lifetime of a session, regardless  
of what happens to the locator set?

Joe

Delivery-date: Tue, 18 Jul 2006 11:25:58 +0000
Date: Tue, 18 Jul 2006 13:24:19 +0200
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: "Bound, Jim" <[email-masked]>
CC: [email-masked]
Subject: Re: IPsec Issue Discussed for Shim6 at IETF Meeting July 10, 2006

Sure, in my shim6 world the ULID is an initially valid locator.
Of course, it may become invalid dynamically during the course
of a session, but that will not invalidate the SA as far as
I can see.

    Brian

Bound, Jim wrote:
> Brian, you have missed the point and I will have to respond more later.
> This was discused in the WG meeting.  SAs must coorespond to loactors
> and if those are ULIDs fine,  but if not there is an IPsec architecture
> problem here. Your comment on how IP works is not how practice or
> implementations work but only in IETF marketing powerpoint charts.
> Best,
> /jim 
> 
> 
>>-----Original Message-----
>>From: Brian E Carpenter [mailto:[email-masked]] 
>>Sent: Saturday, July 15, 2006 10:02 PM
>>To: Bound, Jim
>>Cc: [email-masked]
>>Subject: Re: IPsec Issue Discussed for Shim6 at IETF Meeting 
>>July 10, 2006
>>
>>Jim, I don't understand your architectural issue here. IPSec 
>>is very much an end-to-end protocol so relies on an e2e 
>>identifier (which is why we have to fiddle around to get 
>>IPSec through NAT). It isn't required that all packets 
>>belonging to a given SA travel the same path, because IP 
>>doesn't have that property anyway. So none of my 
>>architectural alarms go off here. (I'd certainly have no 
>>problem with the chairs asking for an early Security Area 
>>review, however.)
>>
>>The shim is clearly placed below IPSec in the stack. That was 
>>documented in draft-ietf-shim6-l3shim. Is that draft dead?
>>
>>     Brian
>>
>>Bound, Jim wrote:
>>
>>>Per the Chairs to WG,
>>>
>>>Currently for Shim6 the ULIDs are used to encrypt and decrypt the 
>>>Shim6 packet per discussions on this with the authors for 
>>
>>IPsec.  This 
>>
>>>is done and possible because there is a context associated with the 
>>>locator pair from out-of-bound message exchange at each end 
>>
>>point to 
>>
>>>identify the ULIDs for location pair association.  This means the 
>>>locator pair in the IP header are not used for IPsec encyrpt and 
>>>decrypt as is done today according to IPsec.
>>>
>>>This is using out-of-bound signals to set up IPsec and was 
>>>specifically rejected as a method for IPsec when defining the IPsec 
>>>architecture back in 1995 at IETF Danvers meeting. In addition this 
>>>type of use of IPsec should be verified and supported by 
>>
>>the IPsec WG within the IETF.
>>
>>>This could be an IETF Last Call objection presented to the IESG for
>>>Shim6 base protocol spec.  In addition this part of Shim6 requires 
>>>much better writing and explanation to provide absolute 
>>
>>clarity of the 
>>
>>>situation and mechanics for processing IPsec.
>>>
>>>Best,
>>>/jim
>>>
>>>
>>
>>
> 

Delivery-date: Mon, 17 Jul 2006 07:09:05 +0000
Content-class: urn:content-classes:message
Subject: RE: IPsec Issue Discussed for Shim6 at IETF Meeting July 10, 2006
Date: Mon, 17 Jul 2006 03:08:54 -0400
From: "Bound, Jim" <[email-masked]>
To: "Brian E Carpenter" <[email-masked]>
Cc: <[email-masked]>

Brian, you have missed the point and I will have to respond more later.
This was discused in the WG meeting.  SAs must coorespond to loactors
and if those are ULIDs fine,  but if not there is an IPsec architecture
problem here. Your comment on how IP works is not how practice or
implementations work but only in IETF marketing powerpoint charts.
Best,
/jim=20

> -----Original Message-----
> From: Brian E Carpenter [mailto:[email-masked]]=20
> Sent: Saturday, July 15, 2006 10:02 PM
> To: Bound, Jim
> Cc: [email-masked]
> Subject: Re: IPsec Issue Discussed for Shim6 at IETF Meeting=20
> July 10, 2006
>=20
> Jim, I don't understand your architectural issue here. IPSec=20
> is very much an end-to-end protocol so relies on an e2e=20
> identifier (which is why we have to fiddle around to get=20
> IPSec through NAT). It isn't required that all packets=20
> belonging to a given SA travel the same path, because IP=20
> doesn't have that property anyway. So none of my=20
> architectural alarms go off here. (I'd certainly have no=20
> problem with the chairs asking for an early Security Area=20
> review, however.)
>=20
> The shim is clearly placed below IPSec in the stack. That was=20
> documented in draft-ietf-shim6-l3shim. Is that draft dead?
>=20
>      Brian
>=20
> Bound, Jim wrote:
> > Per the Chairs to WG,
> >=20
> > Currently for Shim6 the ULIDs are used to encrypt and decrypt the=20
> > Shim6 packet per discussions on this with the authors for=20
> IPsec.  This=20
> > is done and possible because there is a context associated with the=20
> > locator pair from out-of-bound message exchange at each end=20
> point to=20
> > identify the ULIDs for location pair association.  This means the=20
> > locator pair in the IP header are not used for IPsec encyrpt and=20
> > decrypt as is done today according to IPsec.
> >=20
> > This is using out-of-bound signals to set up IPsec and was=20
> > specifically rejected as a method for IPsec when defining the IPsec=20
> > architecture back in 1995 at IETF Danvers meeting. In addition this=20
> > type of use of IPsec should be verified and supported by=20
> the IPsec WG within the IETF.
> >=20
> > This could be an IETF Last Call objection presented to the IESG for
> > Shim6 base protocol spec.  In addition this part of Shim6 requires=20
> > much better writing and explanation to provide absolute=20
> clarity of the=20
> > situation and mechanics for processing IPsec.
> >=20
> > Best,
> > /jim
> >=20
> >=20
>=20
>=20

Delivery-date: Mon, 17 Jul 2006 07:06:26 +0000
Date: Sun, 16 Jul 2006 04:02:10 +0200
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: "Bound, Jim" <[email-masked]>
CC: [email-masked]
Subject: Re: IPsec Issue Discussed for Shim6 at IETF Meeting July 10, 2006

Jim, I don't understand your architectural issue here. IPSec is very much
an end-to-end protocol so relies on an e2e identifier (which is why
we have to fiddle around to get IPSec through NAT). It isn't required
that all packets belonging to a given SA travel the same path,
because IP doesn't have that property anyway. So none of my
architectural alarms go off here. (I'd certainly have no problem
with the chairs asking for an early Security Area review, however.)

The shim is clearly placed below IPSec in the stack. That was
documented in draft-ietf-shim6-l3shim. Is that draft dead?

     Brian

Bound, Jim wrote:
> Per the Chairs to WG,
> 
> Currently for Shim6 the ULIDs are used to encrypt and decrypt the Shim6
> packet per discussions on this with the authors for IPsec.  This is done
> and possible because there is a context associated with the locator pair
> from out-of-bound message exchange at each end point to identify the
> ULIDs for location pair association.  This means the locator pair in the
> IP header are not used for IPsec encyrpt and decrypt as is done today
> according to IPsec.
> 
> This is using out-of-bound signals to set up IPsec and was specifically
> rejected as a method for IPsec when defining the IPsec architecture back
> in 1995 at IETF Danvers meeting. In addition this type of use of IPsec
> should be verified and supported by the IPsec WG within the IETF.
> 
> This could be an IETF Last Call objection presented to the IESG for
> Shim6 base protocol spec.  In addition this part of Shim6 requires much
> better writing and explanation to provide absolute clarity of the
> situation and mechanics for processing IPsec.
> 
> Best,
> /jim
> 
> 

Delivery-date: Thu, 13 Jul 2006 17:13:54 +0000
Date: Thu, 13 Jul 2006 13:13:00 -0400
From: Jari Arkko <[email-masked]>
To: shim6 <[email-masked]>
CC: "W. Mark Townsley" <[email-masked]>
Subject: Mark acting as your AD for the IPR discussion

Point of formality:  Given that my company is involved in
this case, I have recused myself as acting your AD in the IPR
discussion. Mark has agreed to act as your AD on this topic
until the issue is resolved.

Jari Arkko

Delivery-date: Thu, 13 Jul 2006 11:59:06 +0000
Date: Thu, 13 Jul 2006 07:58:25 -0400
To: [email-masked]
From: "Joel M. Halpern" <[email-masked]>
Subject: Re: clarification on my mic comments on HBA's

The various parts of the IETF that have looked at this issue have 
generally concluded that it needs to be a WG decision whether to 
accept a specific form of license.
This case is a good example of why.  Terms similar to those I have 
seen quoted on the list (I would hope Ericsson will post a note to 
the list with their exact intended terms) have been found acceptable 
by some WGs and unacceptable in other circumstances.  Most of the 
time such terms have been deemed acceptable.
The question is not a legal one.  The question is whether the 
limitations, and the impact on foreseeable cases, is felt to be a 
good tradeoff.

(And yes, the process of trying to "negotiate" something better is a 
major pain, since a working group has trouble "negotiating".  Such is 
the WGs choice.)

Yours,
Joel

At 05:20 AM 7/13/2006, Geoff Huston wrote:
>At 04:16 AM 13/07/2006, Joe Abley wrote:
>
>>On 11-Jul-2006, at 13:44, Jari Arkko wrote:
>>
>>>In any case, to move forward I can ask our IPR department
>>>to make a human readable explanation of what the license
>>>means in practise. This hopefully helps the people in the
>>>WG to make an informed decision. Do you think that would
>>>be useful?
>>
>>I am still confused as to why non-lawyers are being asked to indicate
>>comfort with the IPR issues as a prerequisite to the specifications
>>proceeding, when it's so unclear as (a) whether any indicated comfort
>>really means anything, and (b) how anybody should go about gauging
>>their own comfort when they are not qualified to understand the
>>question.
>>
>>This seems like something the working group should expect the IETF as
>>an organisation to find properly-qualified opinions on. I don't
>>understand why the organisation is instead seeking opinions from 
>>self- professed non-lawyers in the working group.
>
>
>Joe,
>
>I appreciate your sentiment, and can only say to you that Kurtis and 
>myself, as the WG Chairs, have raised this matter in a similar style 
>and with similar content with the Area Directors, and, as I informed 
>the WG meeting earlier this week, we were informed by the ADs that 
>this was seen as a matter that was encompassed by the Working Group 
>rough consensus decision making process. i.e. we had to work it out 
>ourselves as a WG. Hence the rough straw poll in the WG meeting on 
>Monday (with approximately equal levels of comfort and discomfort 
>being shown in response to the chairs' query of the working group) 
>and hence the continuation of this discussion here.
>
>I am happy to take your question and refer it to the ADs as being 
>illustrative of the level of comfort of some working group members 
>when being asked to consider detailed IPR matters as they pertain to 
>WG drafts (and have cc'ed the ADs in this response accordingly).
>
>I suspect that the procedural issue you have raised is one that the 
>Working Group cannot readily resolve, given the AD position on this 
>matter. You may want to raise your concern in IETF procedure-related 
>forums, such as the IPR working group 
>(http://www.ietf.org/html.charters/ipr-charter.html)
>
>regards,
>
>    Geoff
>
>
>
>
>
>
>

Delivery-date: Thu, 13 Jul 2006 10:24:37 +0000
Content-class: urn:content-classes:message
Subject: RE: clarification on my mic comments on HBA's
Date: Thu, 13 Jul 2006 06:24:05 -0400
From: "Bound, Jim" <[email-masked]>
To: "Geoff Huston" <[email-masked]>, "Joe Abley" <[email-masked]>, "Jari Arkko" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, "Mark Townsley" <[email-masked]>

Also one does not have to be a lawyer to read any disclosure that states
I will not enforce a patent on an IETF implemented work unless the
entity enforces a patent on the company holding the patent.

What this issue basiscally says is it is fine to use CGA from Company A.

But, if Company B builds fish tanks in the market and finds out Company
A is also building fish tanks and Company B enforces its patent against
Company A.  The the disclosure from Company A for totally not related
IETF CGA work says it can now enforce its CGA patent on Company B.

As CGA could be potentially widely integrated into all devices and nodes
(become pervasive) I am not clear the IETF should support or this
Working Group (per current rules of engagement as Geof stated) CGA
because of this issue.

That is my input to this working group for discussion and I guess a
decision.

Best,
/jim

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On=20
> Behalf Of Geoff Huston
> Sent: Thursday, July 13, 2006 5:21 AM
> To: Joe Abley; Jari Arkko
> Cc: [email-masked]; [email-masked]; Mark Townsley
> Subject: Re: clarification on my mic comments on HBA's
>=20
> At 04:16 AM 13/07/2006, Joe Abley wrote:
>=20
> >On 11-Jul-2006, at 13:44, Jari Arkko wrote:
> >
> >>In any case, to move forward I can ask our IPR department to make a=20
> >>human readable explanation of what the license means in=20
> practise. This=20
> >>hopefully helps the people in the WG to make an informed=20
> decision. Do=20
> >>you think that would be useful?
> >
> >I am still confused as to why non-lawyers are being asked to=20
> indicate=20
> >comfort with the IPR issues as a prerequisite to the specifications=20
> >proceeding, when it's so unclear as (a) whether any=20
> indicated comfort=20
> >really means anything, and (b) how anybody should go about gauging=20
> >their own comfort when they are not qualified to understand the=20
> >question.
> >
> >This seems like something the working group should expect=20
> the IETF as=20
> >an organisation to find properly-qualified opinions on. I don't=20
> >understand why the organisation is instead seeking opinions=20
> from self-=20
> >professed non-lawyers in the working group.
>=20
>=20
> Joe,
>=20
> I appreciate your sentiment, and can only say to you that=20
> Kurtis and myself, as the WG Chairs, have raised this matter=20
> in a similar style and with similar content with the Area=20
> Directors, and, as I informed the WG meeting earlier this=20
> week, we were informed by the ADs that this was seen as a=20
> matter that was encompassed by the Working Group rough=20
> consensus decision making process. i.e. we had to work it out=20
> ourselves as a WG.=20
> Hence the rough straw poll in the WG meeting on Monday (with=20
> approximately equal levels of comfort and discomfort being=20
> shown in response to the chairs' query of the working group)=20
> and hence the continuation of this discussion here.
>=20
> I am happy to take your question and refer it to the ADs as=20
> being illustrative of the level of comfort of some working=20
> group members when being asked to consider detailed IPR=20
> matters as they pertain to WG drafts (and have cc'ed the ADs=20
> in this response accordingly).
>=20
> I suspect that the procedural issue you have raised is one=20
> that the Working Group cannot readily resolve, given the AD=20
> position on this matter. You may want to raise your concern=20
> in IETF procedure-related forums, such as the IPR working=20
> group (http://www.ietf.org/html.charters/ipr-charter.html)
>=20
> regards,
>=20
>     Geoff
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20

Delivery-date: Thu, 13 Jul 2006 09:22:42 +0000
Date: Thu, 13 Jul 2006 19:20:48 +1000
To: Joe Abley <[email-masked]>, Jari Arkko <[email-masked]>
From: Geoff Huston <[email-masked]>
Subject: Re: clarification on my mic comments on HBA's
Cc: [email-masked], [email-masked], Mark Townsley <[email-masked]>

At 04:16 AM 13/07/2006, Joe Abley wrote:

>On 11-Jul-2006, at 13:44, Jari Arkko wrote:
>
>>In any case, to move forward I can ask our IPR department
>>to make a human readable explanation of what the license
>>means in practise. This hopefully helps the people in the
>>WG to make an informed decision. Do you think that would
>>be useful?
>
>I am still confused as to why non-lawyers are being asked to indicate
>comfort with the IPR issues as a prerequisite to the specifications
>proceeding, when it's so unclear as (a) whether any indicated comfort
>really means anything, and (b) how anybody should go about gauging
>their own comfort when they are not qualified to understand the
>question.
>
>This seems like something the working group should expect the IETF as
>an organisation to find properly-qualified opinions on. I don't
>understand why the organisation is instead seeking opinions from self- 
>professed non-lawyers in the working group.

Joe,

I appreciate your sentiment, and can only say to you that Kurtis and 
myself, as the WG Chairs, have raised this matter in a similar style and 
with similar content with the Area Directors, and, as I informed the WG 
meeting earlier this week, we were informed by the ADs that this was seen 
as a matter that was encompassed by the Working Group rough consensus 
decision making process. i.e. we had to work it out ourselves as a WG. 
Hence the rough straw poll in the WG meeting on Monday (with approximately 
equal levels of comfort and discomfort being shown in response to the 
chairs' query of the working group) and hence the continuation of this 
discussion here.

I am happy to take your question and refer it to the ADs as being 
illustrative of the level of comfort of some working group members when 
being asked to consider detailed IPR matters as they pertain to WG drafts 
(and have cc'ed the ADs in this response accordingly).

I suspect that the procedural issue you have raised is one that the Working 
Group cannot readily resolve, given the AD position on this matter. You may 
want to raise your concern in IETF procedure-related forums, such as the 
IPR working group (http://www.ietf.org/html.charters/ipr-charter.html)

regards,

    Geoff

Delivery-date: Wed, 12 Jul 2006 20:17:10 +0000
Cc: Jari Arkko <[email-masked]>, [email-masked], [email-masked]
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: clarification on my mic comments on HBA's
Date: Wed, 12 Jul 2006 16:15:55 -0400
To: Joe Abley <[email-masked]>

On 12-jul-2006, at 14:16, Joe Abley wrote:

> This seems like something the working group should expect the IETF  
> as an organisation to find properly-qualified opinions on. I don't  
> understand why the organisation is instead seeking opinions from  
> self-professed non-lawyers in the working group.

I agree that something better is needed, but I don't think it's a  
mystery why the IESG wants to know the opinion of the wg: generally,  
that's where the people are who are going to implement all of this so  
they should be able to determine through private pocesses whether  
this will be a show stopper for them or not.

Delivery-date: Wed, 12 Jul 2006 18:17:49 +0000
Cc: [email-masked], [email-masked]
From: Joe Abley <[email-masked]>
Subject: Re: clarification on my mic comments on HBA's
Date: Wed, 12 Jul 2006 14:16:28 -0400
To: Jari Arkko <[email-masked]>

On 11-Jul-2006, at 13:44, Jari Arkko wrote:

> In any case, to move forward I can ask our IPR department
> to make a human readable explanation of what the license
> means in practise. This hopefully helps the people in the
> WG to make an informed decision. Do you think that would
> be useful?

I am still confused as to why non-lawyers are being asked to indicate  
comfort with the IPR issues as a prerequisite to the specifications  
proceeding, when it's so unclear as (a) whether any indicated comfort  
really means anything, and (b) how anybody should go about gauging  
their own comfort when they are not qualified to understand the  
question.

This seems like something the working group should expect the IETF as  
an organisation to find properly-qualified opinions on. I don't  
understand why the organisation is instead seeking opinions from self- 
professed non-lawyers in the working group.

Joe

Delivery-date: Tue, 11 Jul 2006 17:50:50 +0000
Content-class: urn:content-classes:message
Subject: RE: clarification on my mic comments on HBA's
Date: Tue, 11 Jul 2006 20:50:36 +0300
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>

Jari,

>In any case, to move forward I can ask our IPR department to=20
>make a human readable explanation of what the license means in=20
>practise. This hopefully helps the people in the WG to make an=20
>informed decision. Do you think that would be useful?

This would be good - also if there was was some clarification if
the Patent covered HBAs generally, or on the CGA part.=20

thanks,
John

Delivery-date: Tue, 11 Jul 2006 17:45:16 +0000
Date: Tue, 11 Jul 2006 13:44:08 -0400
From: Jari Arkko <[email-masked]>
To:  [email-masked]
CC:  [email-masked]
Subject: Re: clarification on my mic comments on HBA's

[email-masked] wrote:

>Just to clarify my comments at the mic. My unease with HBAs is pragmatic
>- I generally
>worry that intellectual property on core SHIM6 specs may cause a
>deployment barrier,
>especially from "open source" implementations.  If this is not a major
>issue for
>folks implementing shim6 specs, then my unease is cleared.
>  
>
#participant_hat_on

Thanks for this note.

I agree that we need to make sure specs with potentially
very wide deployment are possible to implement on open
source. The number of implementation reports that we heard
yesterday perhaps help in assessing what the practical
impact is.

Indeed, that was our intention when Ericsson made
the statement. Previously CGA usage was only free
for SEND implementations. We wanted to make it
possible to use it for free in SHIM6, too. I feel bad
about the statement being taken negatively, given
that we did try help, not disrupt.

In any case, I would suggest that the WG participants need to
be able to differentiate between real IPR concerns and other IPR
concerns. The world, including the IETF, is unfortunately
full of IPR issues. In many situations we are talking about
IPR holders that either refuse to allow use of their technology
or ask an extremely high price for that, or at best employ
so called RAND rules which assure some fairness but still
imply payment.

This is NOT the case here. The license essentially says that
usage is free. There are no restrictions. No money. No need
to contact anyone. No license paper to sign. Nothing. There
is a defensive clause, but that only applies to folks who are
suing other people for their patents. Not sure I want to worry
about the fate to those people.

In any case, to move forward I can ask our IPR department
to make a human readable explanation of what the license
means in practise. This hopefully helps the people in the
WG to make an informed decision. Do you think that would
be useful?

--Jari

Delivery-date: Tue, 11 Jul 2006 14:35:22 +0000
Content-class: urn:content-classes:message
Subject: RE: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006
Date: Tue, 11 Jul 2006 10:13:44 -0400
From: "Bound, Jim" <[email-masked]>
To: "Iljitsch van Beijnum" <[email-masked]>, "Pekka Savola" <[email-masked]>
Cc: <[email-masked]>

IPsec is deployed end-to-end for v4 and v6 in production not sure I
agree no one knows how to do this and I think I misunderstood your
statement below?  Thanks.
/jim=20

> -----Original Message-----
> From: Iljitsch van Beijnum [mailto:[email-masked]]=20
> Sent: Tuesday, July 11, 2006 9:09 AM
> To: Pekka Savola
> Cc: Bound, Jim; [email-masked]
> Subject: Re: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006
>=20
> On 11-jul-2006, at 8:01, Pekka Savola wrote:
>=20
> >> Recommendation: For now remove HBA and the use of ULID security=20
> >> specifying HBA and leave it as work to be completed that=20
> avoids this=20
> >> IPR problem with CGA.  Suggestion is to simply embed ULIDs=20
> within the=20
> >> data payload with new option and secure all communications=20
> at least=20
> >> for now for IP layer communcatiions with IPsec encryption based on=20
> >> locator pair.
>=20
> > How could this any-to-any IPsec (no prior relation to your=20
> peers can=20
> > be assumed) be made to work?`
>=20
> > I think this potential solution path was hinted at the security=20
> > directorate review we got some time ago,
>=20
> And what would that be?
>=20
> Let me repeat my suggestion from yesterday in a bit more detail:
>=20
> In the absense of any information on whether there is even a=20
> patent claim on HBA itself or only on CGA (is there really no=20
> way to determine this?) we keep HBA but rather than make it=20
> the only and mandatory security mechanism (I'm unsure about=20
> the status for CGA but I'll assume that to be a variation of=20
> HBA for these purposes), we add an additional security mechanism.
>=20
> What I'm thinking of here is not IPsec, as nobody has yet=20
> figured out how to run IPsec between two hosts without any=20
> prior coordination in the real world, but rather TLS. This=20
> could be as simple as doing the shim negotiation inside a TCP=20
> session encrypted with TLS. This means more and larger=20
> packets, and one end needs to have a certificate that leads=20
> back to something the other end trusts, so in some ways it's=20
> inferior to HBA, but TLS is widely implemented so adding this=20
> should be very simple and then people have a choice between=20
> HBA IPR issues or TLS PKI and performance issues. Last but=20
> not least, TLS security would make it a good deal easier to=20
> implement the shim in a middlebox.
>=20
> Iljitsch
>=20

Delivery-date: Tue, 11 Jul 2006 14:25:34 +0000
Content-class: urn:content-classes:message
Subject: RE: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006
Date: Tue, 11 Jul 2006 10:25:17 -0400
From: "Bound, Jim" <[email-masked]>
To: "Iljitsch van Beijnum" <[email-masked]>
Cc: "Pekka Savola" <[email-masked]>, <[email-masked]>

I see this point.  Clearly public or pre-shared PKI has to exist yes.
But enclaves of network users will have this association is the
assumption.  So if we are not in some enclave we would need to join one
to send each other files via IPsec with encrypt.  The enclaves are being
built now. =20

Sorry I missed your point.

/jim=20

> -----Original Message-----
> From: Iljitsch van Beijnum [mailto:[email-masked]]=20
> Sent: Tuesday, July 11, 2006 10:19 AM
> To: Bound, Jim
> Cc: Pekka Savola; [email-masked]
> Subject: Re: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006
>=20
> On 11-jul-2006, at 10:13, Bound, Jim wrote:
>=20
> > IPsec is deployed end-to-end for v4 and v6 in production not sure I=20
> > agree no one knows how to do this and I think I misunderstood your=20
> > statement below?  Thanks.
>=20
> So if I want to send you a file and I want to encrypt it with=20
> IPsec, how do I do that, without making special arrangements first?
>=20
> IPsec is only used for VPN tunnels in practice today.
>=20

Delivery-date: Tue, 11 Jul 2006 14:20:05 +0000
Cc: "Pekka Savola" <[email-masked]>, <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006
Date: Tue, 11 Jul 2006 10:18:57 -0400
To: "Bound, Jim" <[email-masked]>

On 11-jul-2006, at 10:13, Bound, Jim wrote:

> IPsec is deployed end-to-end for v4 and v6 in production not sure I
> agree no one knows how to do this and I think I misunderstood your
> statement below?  Thanks.

So if I want to send you a file and I want to encrypt it with IPsec,  
how do I do that, without making special arrangements first?

IPsec is only used for VPN tunnels in practice today.

Delivery-date: Tue, 11 Jul 2006 13:50:12 +0000
Content-class: urn:content-classes:message
Subject: RE: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006
Date: Tue, 11 Jul 2006 09:49:38 -0400
From: "Bound, Jim" <[email-masked]>
To: "Pekka Savola" <[email-masked]>
Cc: <[email-masked]>

What I glean (using this word on purpose) is I entrust the encryption
and as I stated this only secures layer 3 for Shim6.  Once the processes
after IPsec happen another level of Security can begin at the Shim layer
or transport layer for the ULIDs.  That way we can plug and play various
solutions at that point I think as you suggest below if I read your mail
correctly?

Best,
/jimb=20

> -----Original Message-----
> From: Pekka Savola [mailto:[email-masked]]=20
> Sent: Tuesday, July 11, 2006 8:01 AM
> To: Bound, Jim
> Cc: [email-masked]
> Subject: Re: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006
>=20
> On Tue, 11 Jul 2006, Bound, Jim wrote:
> > Recommendation: For now remove HBA and the use of ULID security=20
> > specifying HBA and leave it as work to be completed that=20
> avoids this=20
> > IPR problem with CGA.  Suggestion is to simply embed ULIDs=20
> within the=20
> > data payload with new option and secure all communications at least=20
> > for now for IP layer communcatiions with IPsec encryption=20
> based on locator pair.
> > Separating the movement of Shim6 to proposed standard from=20
> the issue=20
> > of ULID security using HBA.
>=20
> How could this any-to-any IPsec (no prior relation to your=20
> peers can be assumed) be made to work?` Are you suggesting=20
> using BTNS, opportunistic IPsec, and/or something else?  What=20
> would be the impact on security of our solution?
>=20
> I think this potential solution path was hinted at the=20
> security directorate review we got some time ago, but as Jari=20
> Arkko said, it wasn't clear whether secdir fully understood=20
> the implications what using for example IPsec might mean for=20
> the solution.
>=20
> --=20
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
>=20

Delivery-date: Tue, 11 Jul 2006 13:13:33 +0000
Content-class: urn:content-classes:message
Subject: clarification on my mic comments on HBA's
Date: Tue, 11 Jul 2006 16:13:22 +0300
From: <[email-masked]>
To: <[email-masked]>

Hi all,

Just to clarify my comments at the mic. My unease with HBAs is pragmatic
- I generally
worry that intellectual property on core SHIM6 specs may cause a
deployment barrier,
especially from "open source" implementations.  If this is not a major
issue for
folks implementing shim6 specs, then my unease is cleared.

John

Delivery-date: Tue, 11 Jul 2006 13:09:47 +0000
Cc: "Bound, Jim" <[email-masked]>, [email-masked]
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006
Date: Tue, 11 Jul 2006 09:08:31 -0400
To: Pekka Savola <[email-masked]>

On 11-jul-2006, at 8:01, Pekka Savola wrote:

>> Recommendation: For now remove HBA and the use of ULID security
>> specifying HBA and leave it as work to be completed that avoids  
>> this IPR
>> problem with CGA.  Suggestion is to simply embed ULIDs within the  
>> data
>> payload with new option and secure all communications at least for  
>> now
>> for IP layer communcatiions with IPsec encryption based on locator  
>> pair.

> How could this any-to-any IPsec (no prior relation to your peers  
> can be assumed) be made to work?`

> I think this potential solution path was hinted at the security  
> directorate review we got some time ago,

And what would that be?

Let me repeat my suggestion from yesterday in a bit more detail:

In the absense of any information on whether there is even a patent  
claim on HBA itself or only on CGA (is there really no way to  
determine this?) we keep HBA but rather than make it the only and  
mandatory security mechanism (I'm unsure about the status for CGA but  
I'll assume that to be a variation of HBA for these purposes), we add  
an additional security mechanism.

What I'm thinking of here is not IPsec, as nobody has yet figured out  
how to run IPsec between two hosts without any prior coordination in  
the real world, but rather TLS. This could be as simple as doing the  
shim negotiation inside a TCP session encrypted with TLS. This means  
more and larger packets, and one end needs to have a certificate that  
leads back to something the other end trusts, so in some ways it's  
inferior to HBA, but TLS is widely implemented so adding this should  
be very simple and then people have a choice between HBA IPR issues  
or TLS PKI and performance issues. Last but not least, TLS security  
would make it a good deal easier to implement the shim in a middlebox.

Iljitsch

Delivery-date: Tue, 11 Jul 2006 12:02:03 +0000
Date: Tue, 11 Jul 2006 15:01:19 +0300 (EEST)
From: Pekka Savola <[email-masked]>
To: "Bound, Jim" <[email-masked]>
cc: [email-masked]
Subject: Re: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006

On Tue, 11 Jul 2006, Bound, Jim wrote:
> Recommendation: For now remove HBA and the use of ULID security
> specifying HBA and leave it as work to be completed that avoids this IPR
> problem with CGA.  Suggestion is to simply embed ULIDs within the data
> payload with new option and secure all communications at least for now
> for IP layer communcatiions with IPsec encryption based on locator pair.
> Separating the movement of Shim6 to proposed standard from the issue of
> ULID security using HBA.

How could this any-to-any IPsec (no prior relation to your peers can 
be assumed) be made to work?` Are you suggesting using BTNS, 
opportunistic IPsec, and/or something else?  What would be the impact 
on security of our solution?

I think this potential solution path was hinted at the security 
directorate review we got some time ago, but as Jari Arkko said, it 
wasn't clear whether secdir fully understood the implications what 
using for example IPsec might mean for the solution.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

Delivery-date: Tue, 11 Jul 2006 10:52:07 +0000
Content-class: urn:content-classes:message
Subject: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006
Date: Tue, 11 Jul 2006 06:51:50 -0400
From: "Bound, Jim" <[email-masked]>
To: <[email-masked]>

Per Chair and WG Discussion,

The current IPR for CGA use of HBA issue is as follows for the WG to
consider.

Assume or imagine CGA is pervasive tomorrow on all nodes, devices, and
sensors. The current IPR states that if any entity asserts any patents,
even if unrelated to any IETF or even networking products on the patent
holder then the CGA patent holder can assert their patent claims on the
entity.  That is rather broad and scary for us to accept as use for
Shim6 if it is broadly used.

Recommendation: For now remove HBA and the use of ULID security
specifying HBA and leave it as work to be completed that avoids this IPR
problem with CGA.  Suggestion is to simply embed ULIDs within the data
payload with new option and secure all communications at least for now
for IP layer communcatiions with IPsec encryption based on locator pair.
Separating the movement of Shim6 to proposed standard from the issue of
ULID security using HBA.

This could be an IETF Last Call issue presented to the IESG.

Best,
/jim

Delivery-date: Tue, 11 Jul 2006 10:44:40 +0000
Content-class: urn:content-classes:message
Subject: IPsec Issue Discussed for Shim6 at IETF Meeting July 10, 2006
Date: Tue, 11 Jul 2006 06:43:48 -0400
From: "Bound, Jim" <[email-masked]>
To: <[email-masked]>

Per the Chairs to WG,

Currently for Shim6 the ULIDs are used to encrypt and decrypt the Shim6
packet per discussions on this with the authors for IPsec.  This is done
and possible because there is a context associated with the locator pair
from out-of-bound message exchange at each end point to identify the
ULIDs for location pair association.  This means the locator pair in the
IP header are not used for IPsec encyrpt and decrypt as is done today
according to IPsec.

This is using out-of-bound signals to set up IPsec and was specifically
rejected as a method for IPsec when defining the IPsec architecture back
in 1995 at IETF Danvers meeting. In addition this type of use of IPsec
should be verified and supported by the IPsec WG within the IETF.

This could be an IETF Last Call objection presented to the IESG for
Shim6 base protocol spec.  In addition this part of Shim6 requires much
better writing and explanation to provide absolute clarity of the
situation and mechanics for processing IPsec.

Best,
/jim

Delivery-date: Tue, 04 Jul 2006 11:55:15 +0000
Cc: [email-masked]
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: I-D ACTION:draft-van-beijnum-shim6-reach-detect-00.txt
Date: Tue, 4 Jul 2006 13:54:14 +0200
To: Brian E Carpenter <[email-masked]>

On 4-jul-2006, at 8:45, Brian E Carpenter wrote:

>> 1. The base timing unit for this mechanism is named ShimKeepT.
>>    Until a negotiation mechanism to negotiate different values for
>>    ShimKeepT becomes available, a value of 10 seconds MUST be
>>    used.

> Having just seen claims that IPv6 will increase battery lifetime  
> because
> it avoids NAT keepalives, this "until" bothers me a bit.

> Is it essential that the two ends agree on the value of ShimKeepT?

Yes, because the receiver must time out when it doesn't see traffic  
for that period of time, so if the sender uses a larger value the  
receiver will time out when it shouldn't.

It is of course not that hard to add an option to the context  
establishment mechanism to convey the keepalive period used.

> Couldn't we devise an algorithm for progressively increasing it, or  
> for
> tuning it according to the rate of data packets? Presumably a  
> session that
> generates one packet every five minutes would not be damaged by a much
> larger ShimKeepT.

Nothing is impossible, but this would be quite difficult, as there  
could be missed messages and so on.

But don't forget that keepalives are only sent when one side sends  
data but the other side doesn't send anything. So in case where there  
is traffic in both directions and also in the case where the session  
is idle, no keepalives are sent. If we build in special case handling  
of TCP ACKs, TCP communication will NEVER generate keepalives if  
there is no packet loss, and if we don't, only when the session moves  
from active to idle.

So I don't think this is a huge issue.

Also note that increasing the timeout value means that detecting  
failures will take more time.

(All of this is the same in draft-ietf-shim6-failure-detection.)

>> When a host suspects that there is a failure for a context, it  
>> gathers
>> the set of possible source addresses and the set of possible  
>> destination
>> addresses.

> "Suspect" can't form part of an algorithm. Can you define what this  
> means
> algorithmically? Does it mean "When full reachability exploration  
> is started"?

:-)  Ok...

A host suspects that there is a failure when it has sent traffic and  
not seen any return traffic (regular traffic or keepalives) for  
ShimKeepT seconds plus 2 - 5 seconds.

Note it's unlikely that this document will continue to exist, after  
last week's discussion I'm going to take parts of it and incorporate  
them into the failure detection draft, and maybe other parts will  
find their way into the locator selection draft. The discussion about  
reusing the protocol for more than one client protocol that needs  
reachability detection is now obsolete because I've come to the  
conclusion that this isn't worth the trouble.

But thanks for reviewing!

Delivery-date: Tue, 04 Jul 2006 06:45:57 +0000
Date: Tue, 04 Jul 2006 08:45:05 +0200
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: [email-masked]
Subject: Re: I-D ACTION:draft-van-beijnum-shim6-reach-detect-00.txt

> 1. The base timing unit for this mechanism is named ShimKeepT.
>    Until a negotiation mechanism to negotiate different values for
>    ShimKeepT becomes available, a value of 10 seconds MUST be
>    used.

Having just seen claims that IPv6 will increase battery lifetime because
it avoids NAT keepalives, this "until" bothers me a bit.

Is it essential that the two ends agree on the value of ShimKeepT?

Couldn't we devise an algorithm for progressively increasing it, or for
tuning it according to the rate of data packets? Presumably a session that
generates one packet every five minutes would not be damaged by a much
larger ShimKeepT.

> When a host suspects that there is a failure for a context, it gathers
> the set of possible source addresses and the set of possible destination
> addresses.

"Suspect" can't form part of an algorithm. Can you define what this means
algorithmically? Does it mean "When full reachability exploration is started"?

    Brian

Delivery-date: Tue, 04 Jul 2006 01:31:52 +0000
Date: Tue, 04 Jul 2006 11:28:27 +1000
To: [email-masked]
From: Geoff Huston <[email-masked]>
Subject: Amended Agenda for SHIM6
Cc: kurt Erik Lindqvist <[email-masked]>

Site Multihoming by IPv6 Intermediation WG (SHIM6)
IETF 66, Montreal

Monday, July 10, 2006 1520-1720 (Afternoon Session II)
====================================================

CHAIRS: Geoff Huston <[email-masked]>
         Kurtis Lindqvist <[email-masked]>

AGENDA:

  1) Administriva                                             5 minutes

    - Mailing list: http://ops.ietf.org/lists/shim6/
    - Scribe?
    - Blue Sheets
    - Agenda Bashing

  2) Status of "base specification" document set             15 minutes

     1. Level 3 multihoming shim protocol
        http://www.ietf.org/internet-drafts/draft-ietf-shim6-proto-05.txt

     2. Hash Based Addresses (HBA)
        http://www.ietf.org/internet-drafts/draft-ietf-shim6-hba-01.txt

     3. Failure Detection and Locator Pair Exploration Protocol for IPv6
        Multihoming
        http://www.ietf.org/internet-drafts/draft-ietf-shim6-failure-detection-05

  3) SHIM6 Applicability

     1. Applicability (Marcelo Bagnulo, Joe Abley)           15 minutes

        Applicability Statement for the Level 3 Multihoming Shim Protocol
        http://www.ietf.org/internet-drafts/draft-ietf-shim6-applicability-01.txt

   4) SHIM6 Implementation Report                            10 minutes

      1. Progress report on SHIM6 Implementation
         Taewan You (ETRI)

   5) SHIM6 Extension Drafts

      1. Locator Pair Selection (Marcelo Bagnulo)            15 minutes

         Default Locator-pair selection algorithm for the SHIM6 protocol
         http://www.ietf.org/internet-drafts/draft-ietf-shim6-locator-pair-selection-00.txt

      2. ESD (Erik Nordmark)                                 15 minutes

         Extended Shim6 Design for ID/loc split and Traffic Engineering
         http://www.ietf.org/internet-drafts/draft-nordmark-shim6-esd-00.txt

         ** Eric wont be able to make it this time around - so the chairs
            will request  WG comments on the draft

      3. Ingress Filtering (Marcelo Bagnulo)                 10 minutes

         Ingress filtering compatibility for IPv6 multihomed sites
         http://www.ietf.org/internet-drafts/draft-bagnulo-shim6-ingress-filtering-00.txt

      4. Privacy Analysis (Marcelo Bagnulo)                  10 minutes

         Privacy Analysis for the SHIM6 protocol
         http://www.ietf.org/internet-drafts/draft-bagnulo-shim6-privacy-00.txt

      5. Socket API (Shinta Sugimoto)                        15 minutes

         Socket Application Program Interface (API) for Multihoming Shim
         http://www.ietf.org/internet-drafts/draft-sugimoto-multihome-shim-api-00.txt

  6) WG Direction

      Iljitsch van Beijnum                                   15 minutes

Delivery-date: Mon, 03 Jul 2006 21:36:12 +0000
Date: Tue, 04 Jul 2006 07:35:28 +1000
To: [email-masked]
From: Geoff Huston <[email-masked]>
Subject: Proposed Agenda for SHIM6 meeting
Cc: Kurt Erik Lindqvist <[email-masked]>

Site Multihoming by IPv6 Intermediation WG (SHIM6)
IETF 66, Montreal

Monday, July 10, 2006 1520-1720 (Afternoon Session II)
====================================================

CHAIRS: Geoff Huston <[email-masked]>
         Kurtis Lindqvist <[email-masked]>

AGENDA:

  1) Administriva                                             5 minutes

    - Mailing list: http://ops.ietf.org/lists/shim6/
    - Scribe?
    - Blue Sheets
    - Agenda Bashing

  2) Status of "base specification" document set             15 minutes

     1. Level 3 multihoming shim protocol
        http://www.ietf.org/internet-drafts/draft-ietf-shim6-proto-05.txt

     2. Hash Based Addresses (HBA)
        http://www.ietf.org/internet-drafts/draft-ietf-shim6-hba-01.txt

     3. Failure Detection and Locator Pair Exploration Protocol for IPv6
        Multihoming
        http://www.ietf.org/internet-drafts/draft-ietf-shim6-failure-detection-05

  3) SHIM6 Applicability

     1. Applicability (Marcelo Bagnulo, Joe Abley)           15 minutes

        Applicability Statement for the Level 3 Multihoming Shim Protocol
        http://www.ietf.org/internet-drafts/draft-ietf-shim6-applicability-01.txt

   4) SHIM6 Extension Drafts

      1. Locator Pair Selection (Marcelo Bagnulo)            15 minutes

         Default Locator-pair selection algorithm for the SHIM6 protocol
         http://www.ietf.org/internet-drafts/draft-ietf-shim6-locator-pair-selection-00.txt

      2. ESD (Erik Nordmark)                                 15 minutes

         Extended Shim6 Design for ID/loc split and Traffic Engineering
         http://www.ietf.org/internet-drafts/draft-nordmark-shim6-esd-00.txt

         ** Eric wont be able to make it this time around - so the chairs will
             request  WG comments on the draft

      3. Ingress Filtering (Marcelo Bagnulo)                 10 minutes

         Ingress filtering compatibility for IPv6 multihomed sites
         http://www.ietf.org/internet-drafts/draft-bagnulo-shim6-ingress-filtering-00.txt

      4. Privacy Analysis (Marcelo Bagnulo)                  10 minutes

         Privacy Analysis for the SHIM6 protocol
         http://www.ietf.org/internet-drafts/draft-bagnulo-shim6-privacy-00.txt

      5. Socket API (Shinta Sugimoto)                        15 minutes

         Socket Application Program Interface (API) for Multihoming Shim
         http://www.ietf.org/internet-drafts/draft-sugimoto-multihome-shim-api-00.txt

  5) WG Direction

      Iljitsch van Beijnum                                   15 minutes

Delivery-date: Mon, 03 Jul 2006 15:05:19 +0000
Cc: shim6-wg <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: I-D ACTION:draft-van-beijnum-shim6-suppress-header-00.txt
Date: Mon, 3 Jul 2006 17:04:59 +0200
To: Marshall Eubanks <[email-masked]>

On 3-jul-2006, at 16:36, Marshall Eubanks wrote:

>> So in practice, the number of packets that are shimmed because of  
>> outages will likely be something well below 1 in 1000, say around  
>> 1 in 10,000 to 1 in 100,000.

> I think that these estimates may be much too small. For example,  
> where my house is (Fairfax County, Virginia), the local cable  
> company Internet is severely oversubscribed
> mid-afternoon, and long periods (one hour or more) of 50%+ packet  
> loss are common, which, looked at in detail are a few seconds of no  
> packet loss followed by a few seconds of near total loss, repeated.  
> So, if Shim6 was functional, basically every one of my packets  
> would be shimmed every afternoon (assuming that the other providers  
> available also have the same sort of problems).

> Don't forget too that there is a filter effect likely here - the  
> more common outages are,
> the more likely you are to use something like Shim6, so the  
> sampling is not unbiased, and it is probable that Shim6 users will  
> have higher than usual packet losses.

You're right. I'm afraid that my estimation is based too much on my  
operational experience, which is mainly that of living in a dense,  
highly organized country with not much extreme weather. One big  
difference between here and many other parts of the world is that  
here in Holland, above ground phone wiring doesn't exist except in  
rural areas, so the phone service and thus the ADSL service is  
probably a lot more reliable than in countries where they use above  
ground phone wiring and also have lower/higher temperatures.  
(Although it's pretty hot here today...)

Delivery-date: Mon, 03 Jul 2006 14:37:22 +0000
Cc: Brian E Carpenter <[email-masked]>, shim6-wg <[email-masked]>
From: Marshall Eubanks <[email-masked]>
Subject: Re: I-D ACTION:draft-van-beijnum-shim6-suppress-header-00.txt
Date: Mon, 3 Jul 2006 10:36:10 -0400
To: Iljitsch van Beijnum <[email-masked]>

Hello;

On Jul 3, 2006, at 9:10 AM, Iljitsch van Beijnum wrote:

> On 3-jul-2006, at 14:33, Brian E Carpenter wrote:
>
>>> The author is of the opinion that such an increase in overhead on  
>>> top of
>>> the increase in overhead incurred by IPv6 in general over IPv4,  
>>> makes
>>> the shim6 multihoming solution less attractive, so it's  
>>> worthwhile to
>>> try and suppress the shim6 header where possible.
>
>> Has anyone looked at shim6/rohc interaction?
>
> I haven't, but I'd assume that it would be relatively simple to  
> compress the shim header too in cases where other headers are being  
> compressed.
>
>> Also, has anyone estimated what fraction of traffic would carry
>> shim6 headers, on reasonable assumptions about the prevalence
>> of multihoming events?
>
> Generally, outages are fairly rare (don't forget that many people  
> don't even multihome...), based on common SLA targets I'd say that  
> at any given time about 1 - 3 out of a thousand last mile links are  
> down. Although very short outages are more frequent than longer  
> ones, long ones account for the majority of the downtime. In these  
> cases, a shim6 enabled host will only use addresses associated with  
> the links that are down if it had already established a context  
> before the outage. So in practice, the number of packets that are  
> shimmed because of outages will likely be something well below 1 in  
> 1000, say around 1 in 10,000 to 1 in 100,000.
>

I think that these estimates may be much too small. For example,  
where my house is (Fairfax County, Virginia), the local cable company  
Internet is severely oversubscribed
mid-afternoon, and long periods (one hour or more) of 50%+ packet  
loss are common, which, looked at in detail are a few seconds of no  
packet loss followed by a few seconds of near total loss, repeated.  
So, if Shim6 was functional, basically every one of my packets would  
be shimmed every afternoon (assuming that the other providers  
available also have the same sort of problems).

Don't forget too that there is a filter effect likely here - the more  
common outages are,
the more likely you are to use something like Shim6, so the sampling  
is not unbiased, and it is probable that Shim6 users will have higher  
than usual packet losses.

Both of these things, of course, support your basic premise.

BTW, none of the local residential providers here provide SLA's,  
although do I know of
one person who has gotten one by request.

Regards
Marshall

> However, shim6 has the potential to make outages visible that are  
> hidden today. For instance, if I sit between major exchange  
> locations A and B, and my ISP gives me addresses that are routed  
> over A and addresses that are routed over B (even though I may not  
> be multihomed), I could end up with non-working addresses part of  
> the time where such an outage would be invisible today. Doing this  
> allows the user to "see" the two different paths and use whichever  
> works best, as opposed to the current situation where a routing  
> protocol selects one of the paths and the other is ignored.
>
> But the clincher would be shimming for traffic engineering. Since  
> it's hard to get people to connect to the "right" address at the  
> beginning of a context, it's likely that some content suppliers  
> will want to rehome a context immediately after it has been set up  
> for traffic engineering purposes. This has the potential to  
> generate a LOT of shimmed traffic so this is the main reason I  
> wrote the draft.
>

Delivery-date: Mon, 03 Jul 2006 13:11:16 +0000
Cc: shim6-wg <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: I-D ACTION:draft-van-beijnum-shim6-suppress-header-00.txt
Date: Mon, 3 Jul 2006 15:10:33 +0200
To: Brian E Carpenter <[email-masked]>

On 3-jul-2006, at 14:33, Brian E Carpenter wrote:

>> The author is of the opinion that such an increase in overhead on  
>> top of
>> the increase in overhead incurred by IPv6 in general over IPv4, makes
>> the shim6 multihoming solution less attractive, so it's worthwhile to
>> try and suppress the shim6 header where possible.

> Has anyone looked at shim6/rohc interaction?

I haven't, but I'd assume that it would be relatively simple to  
compress the shim header too in cases where other headers are being  
compressed.

> Also, has anyone estimated what fraction of traffic would carry
> shim6 headers, on reasonable assumptions about the prevalence
> of multihoming events?

Generally, outages are fairly rare (don't forget that many people  
don't even multihome...), based on common SLA targets I'd say that at  
any given time about 1 - 3 out of a thousand last mile links are  
down. Although very short outages are more frequent than longer ones,  
long ones account for the majority of the downtime. In these cases, a  
shim6 enabled host will only use addresses associated with the links  
that are down if it had already established a context before the  
outage. So in practice, the number of packets that are shimmed  
because of outages will likely be something well below 1 in 1000, say  
around 1 in 10,000 to 1 in 100,000.

However, shim6 has the potential to make outages visible that are  
hidden today. For instance, if I sit between major exchange locations  
A and B, and my ISP gives me addresses that are routed over A and  
addresses that are routed over B (even though I may not be  
multihomed), I could end up with non-working addresses part of the  
time where such an outage would be invisible today. Doing this allows  
the user to "see" the two different paths and use whichever works  
best, as opposed to the current situation where a routing protocol  
selects one of the paths and the other is ignored.

But the clincher would be shimming for traffic engineering. Since  
it's hard to get people to connect to the "right" address at the  
beginning of a context, it's likely that some content suppliers will  
want to rehome a context immediately after it has been set up for  
traffic engineering purposes. This has the potential to generate a  
LOT of shimmed traffic so this is the main reason I wrote the draft.

Delivery-date: Mon, 03 Jul 2006 12:34:56 +0000
Date: Mon, 03 Jul 2006 14:33:28 +0200
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: Iljitsch van Beijnum <[email-masked]>
CC: shim6-wg <[email-masked]>
Subject: Re: I-D ACTION:draft-van-beijnum-shim6-suppress-header-00.txt

> The author is of the opinion that such an increase in overhead on top of
> the increase in overhead incurred by IPv6 in general over IPv4, makes
> the shim6 multihoming solution less attractive, so it's worthwhile to
> try and suppress the shim6 header where possible.

Has anyone looked at shim6/rohc interaction?

Also, has anyone estimated what fraction of traffic would carry
shim6 headers, on reasonable assumptions about the prevalence
of multihoming events?

   Brian