Subject: Re: Specific problems in the Ericsson IPR statement?
From: Jari Arkko <[email-masked]>
To: Jeroen Massar <[email-masked]>
Cc: shim6 <[email-masked]>
Date: Mon, 28 Aug 2006 18:19:45 +0300

Jeroen Massar wrote:

> Do I read it correctly that this says:
>  - Company X has patent Z
>  - Company X implements this thing
>  - Ericsson implements thing with patent Z
>  - Company X can't protect it's patent as it implement this.

No. I should have included all the details - actually
company X has a choice between 1. The free license,
with an implication to allow use of Z on the same terms,
OR 2. the default Ericsson IETF license which is so called
RAND license (reasonable and non-discriminatory). In
the latter case there is no impact on Z but the license
isn't necessarily free.

Jim's issue was related to what you are asking. He
wanted X to be able to implement Shim6 for free if
Z is in some unrelated field, e.g., steam engines
or CDMA radios. The proposed change that I'll
try to convince to my IPR department to do means
that this would be possible, as long as X is
not simultaneously requiring Ericsson to give
Shim6 IPR for free and asking Ericsson to pay
royalty for some other IETF standards track
RFC.

Just my interpretation, of course.

--Jari

Delivery-date: Mon, 28 Aug 2006 14:31:59 +0000
Date: Mon, 28 Aug 2006 16:31:32 +0200
From: Jeroen Massar <[email-masked]>
Organization: Unfix
To: Jari Arkko <[email-masked]>
CC: shim6 <[email-masked]>
Subject: Re: Specific problems in the Ericsson IPR statement?
OpenPGP: id=333E7C23

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigF9D7AA5694075ACFD58754B2
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

Jari Arkko wrote:
> Folks,
>=20
> In the IPR discussion a specific problem that was raised
> was the generality of the defensive clause. As you may
> remember, the statement was formulated such that from
> Ericsson point of view anyone can use this technology
> for free. But only as long as the user do not sue Ericsson
> for some of his own patents (on any field).

Do I read it correctly that this says:
  - Company X has patent Z
  - Company X implements this thing
  - Ericsson implements thing with patent Z
  - Company X can't protect it's patent as it implement this.

Effectively that makes all patents of any company void when they would=20
implement this then. Simply ask Ericsson to cover them up when needed.
I guess there are a LOT of companies which won't agree with the above.

Did I misread/misunderstand?

Greets,
  Jeroen

(/me who sometimes wonders if patents in IETF related works are there to =

protect the invention or to simply force people to pay big bucks...)
(On one side this would be good as then there are no patent issues=20
anymore ;)

--------------enigF9D7AA5694075ACFD58754B2
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enigF9D7AA5694075ACFD58754B2--

Delivery-date: Mon, 28 Aug 2006 14:11:11 +0000
Date: Mon, 28 Aug 2006 17:10:02 +0300
From: Jari Arkko <[email-masked]>
To: shim6 <[email-masked]>
Subject: Specific problems in the Ericsson IPR statement?

Folks,

In the IPR discussion a specific problem that was raised
was the generality of the defensive clause. As you may
remember, the statement was formulated such that from
Ericsson point of view anyone can use this technology
for free. But only as long as the user do not sue Ericsson
for some of his own patents (on any field).

I plan to ask if our IPR department could agree on
changing this such that it only applies to IETF technology.
Based on a private discussion with Jim, this removes
at least his concern.

If there were other IPR related concerns, let me
know so that I can let our IPR department know.
I plan to talk to them later this week. In
particular, input from the various groups that
are working with Shim6 implementations for
open source would be valuable, if they have
issues that prevent implementation.

--Jari

Delivery-date: Mon, 21 Aug 2006 09:45:12 +0000
Date: Mon, 21 Aug 2006 11:44:18 +0200
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: marcelo bagnulo braun <[email-masked]>
CC: "Bound, Jim" <[email-masked]>, "Henderson, Thomas R" <[email-masked]>, [email-masked]
Subject: Re: IPsec Issue Discussed for Shim6 at IETF Meeting July 10, 2006

Sorry to reply late but I feel Marcelo is 100% correct here. IMHO:

- we can use IPsec to protect a session that happens to benefit
from shim6;

- we can choose not to use IPsec for such a session;

- neither IPsec nor shim6 are affected by this choice;

- this is completely separate from whether HBA is the best way to
protect shim6 signalling from the multihoming threat model.

- even if we decided to drop HBA and use some solution based on
IPsec to protect shim6 signalling, that is *still* completely separate
from using IPsec to protect a session that happens to benfit from shim6.

     Brian

marcelo bagnulo braun wrote:
> 
> El 08/08/2006, a las 17:00, Bound, Jim escribió:
> 
>> HBA does not prevent attacks that IPsec does.  See IPsec.
>>
> 
> i agree with this
> 
> let's see if you agree with the following statements:
> 
> - in any case, some of the attacks that are prevented by IPSec are not 
> prevented by HBA
> 
> - It is possible to build a security mechanisms to protect the shim6 
> protocol using IPSec with preshared keys or with PKI that actually 
> prevents all the threats described in RFC4218
> 
> - It is not possible to build a security mechanisms to protect the shim6 
> protocol using IPSec without preshared keys nor PKI that prevents all 
> the threats described in RFC4218 (in particular, it is not possible to 
> provide protection against redirection of future communications to a 
> given identifier)
> 
> If you do not agree with the last bullet, please describe how would you 
> build a security mechanisms for the shim6 protocol that actually 
> protects from this type of attacks using IPSec without using pre shared 
> keys or PKI. I mean if you can provide an actual solution that works, it 
> would be really useful because we could compare them and see the pros 
> and cons. Comparing a full fleshed silution like HBA with some 
> undocumented solution based on IPSec is extremely hard...
> 
> 
>> By Red Herring for IPsec PKI I am saying that the issue of PKI is 
>> often used to not use end-to-end today (as I described it before) 
>> because of PKI and just a means to win another technology discussion 
>> point often to support the further use of mid-com boxes which is in 
>> the way of true end-to-end.  It is an art of negotiations to position 
>> that which is not the issue against the real issue avoiding addressing 
>> the real issue. IPsec is now being used as strategy by every 
>> government and industry I know for those deploying not just IPv6. It 
>> provides defense in depth at layer 3.  Not having it as an option for 
>> shim6 is irresponsible by us in an IETF shim6 WG.
>>
> 
> but this is not the case...
> 
> i mean the shim6 is completelly compatible with IPSec (or it should be). 
> The goal is that you can use shim6 and IPSec toghether in the same 
> communication, i don't think there is any doubt about it.
> 
> The problem is that IPSec does not provides all the protection that it 
> is required by the shim protocol if there are no pre shared keys or PKI, 
> so we need additional tools in this case. It would be irresponsible by 
> us to accept a solution that introduces critical vulnerabilities like 
> identify hijacking by supporting opportunistic IPSec as a security 
> solution for the shim protocol
> 
> So, i fully agree that shim6 and IPSec must run together, Moreover, i 
> think it is a good idea that if the peers are already using IPSec and 
> they have a preshared key or a pki with a common anchor point available, 
> they use IPSec to protect the shim6 protocol. What is more, i am willing 
> to work with you to design such approach and write it down in an ID and 
> see that it fits in the shim6 protocol. However, we must provide an 
> alternative solution for the case where the pre shared kay and the PKI 
> are not available and a security solution based on IPSEc in not secure 
> enough for this case. So far this solution is based on the HBAs
> 
>> The compromise I suggest to the WG is remove any security from base 
>> shim6 spec which will never be deployed at least for 3 years and 
>> permit the WG to work on multiple solutions as an exercise.
> 
> 
> again i don't think that we can send a protocol wihtout proper security, 
> it is just a useless protocol, since it cannot be deployed (and i guess 
> that the IESG will reject it)
> 
> 
> my suggestion is let's discuss the security solutions now... we have 
> been working on this too long to delay it further.
> 
> we can design a security solution based on IPSecfor the case were it can 
> be used safely (preshared key or PKI)
> 
>>  In the interim for any testing or scoping IPsec can be clearly used 
>> in R&D labs to secure packets.  And any shime6 IP stack implementation 
>> should be architected in products to be modular to support multiple 
>> means to secure Locator communications for session use for multihoming.
> 
> 
> this is already the case
> 
> the current version of the shim6 protocol does support multiple security 
> mechanism and can be extended to other security mechanisms
> that is why i say that it would straight forward to design a solution 
> based on IPSEc with preshared keys or PKI
> 
> regards, marcelo
> 
> 
>>   We should also only conceptually specify the layer model whether 
>> above IP, above TCP, etc. (note do not assume a strict layering model 
>> IP can call TCP etc. at any point time and vice/versa).
>>
>> The entire discussion regarding Security for shim6 should be required 
>> to be reviewed by the IPsec WG and IETF Security Area Directorate.
>>
>> Best,
>> /jim
>>
>>
>>
>>> -----Original Message-----
>>> From: marcelo bagnulo braun [mailto:[email-masked]]
>>> Sent: Tuesday, August 08, 2006 2:45 AM
>>> To: Bound, Jim
>>> Cc: Henderson, Thomas R; [email-masked]
>>> Subject: Re: IPsec Issue Discussed for Shim6 at IETF Meeting
>>> July 10, 2006
>>>
>>>
>>> El 07/08/2006, a las 17:31, Bound, Jim escribió:
>>>
>>>> Tom, I explained in my last mail. Ipsec should not have used IP
>>>> addresses but it is all we have today and cannot achieve
>>>
>>> consensus on
>>>
>>>> identifiers anywhere in any SDO or consortia.  Today it is
>>>
>>> a fast path
>>>
>>>> for IPsec to parse the IP header off the IP stack interrupt
>>>
>>> queue and
>>>
>>>> permits us to drop the packet immediately if SA issue is found. HBA
>>>> does not give me enough comfort or the shim6 protocol to alter that
>>>> implementation behavior and also creates additional
>>>
>>> security problems.
>>>
>>> could you describe what are the security problems introduced
>>> by the shim protocols what HBA CGA are used?
>>>
>>>> Just leave it encapsulated under IP and decrypt from IPv6.
>>>
>>>
>>> this doesn't provide protection against identity hijacking attacks
>>>
>>>>   The PKI and
>>>> Pre-Shared key issue is a red herring,
>>>
>>>
>>> what do you mean by this?
>>> Do you think that using IPSec without PKI or preshared keys
>>> is good enough?
>>>
>>> regards, marcelo
>>>
>>>
>>>>  once we have an established IPv6
>>>> address between nodes IPsec works just fine.  From there
>>>
>>> shim6 can use
>>>
>>>> IPsec to pass locators.
>>>>
>>>> Best,
>>>> /jim
>>>>
>>>>> -----Original Message-----
>>>>> From: Henderson, Thomas R [mailto:[email-masked]]
>>>>> Sent: Wednesday, August 02, 2006 12:02 PM
>>>>> To: Bound, Jim; [email-masked]
>>>>> Subject: RE: IPsec Issue Discussed for Shim6 at IETF
>>>
>>> Meeting July 10,
>>>
>>>>> 2006
>>>>>
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Bound, Jim [mailto:[email-masked]]
>>>>>> Sent: Tuesday, July 11, 2006 3:44 AM
>>>>>> To: [email-masked]
>>>>>> Subject: IPsec Issue Discussed for Shim6 at IETF Meeting
>>>>>
>>>>> July 10, 2006
>>>>>
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>
>>>>> Jim,
>>>>> Can you clarify this historical note?  I wasn't around for
>>>
>>> the IPsec
>>>
>>>>> discussions then but I did go back to look at the mail list at the
>>>>> time and it seems that, in fact, IPsec did adopt an out-of-band
>>>>> signaling exchange (IKE), and that in-band (SKIP proposal) was
>>>>> rejected.  Here is the start of a thread on this subject:
>>>>> http://www.sandelman.ottawa.on.ca/ipsec/1995/02/msg00096.html
>>>>> but you seem to be using the terminology differently.
>>>>>
>>>>> I can't find it written down anywhere that the locator
>>>
>>> pair in the IP
>>>
>>>>> header on the wire must be those used at the point of IPsec
>>>>> processing for encrypt and decrypt.
>>>>>
>>>>> Tom
>>>>>
>>>>>
>>>>
>>>
>>>
>>
> 
> 
> 

Delivery-date: Wed, 09 Aug 2006 12:42:21 +0000
To: "Henderson, Thomas R" <[email-masked]>
Cc: shim6-wg <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: visibility of identifier in shim6 payload packet
Date: Thu, 3 Aug 2006 18:39:06 +0200

[resent from last week]

On 1-aug-2006, at 20:40, Henderson, Thomas R wrote:

> My understanding of the potential problem is as follows:

> - there are multiple ways to implement IPsec:  BITW, BITS, and native

> - BITS and BITW operate below the IP layer.  If these types of IPsec
> implementations talk to each other, there should be no problem if the
> SPD/SAD is defined on the basis of the locators.

Right. When hosts A and B communicate with A1/B1 there will be a  
security association for that address pair, when they switch to A2/B2  
or whatever, a new SA will be negotiated.

> - there is also no problem if two native IPsec implementations talk to
> each other using the ULIDs as the IPsec addresses, with both native
> IPsec implementations above the shim6 layer

Right, in this case the IPsec header will already be present when the  
shim sees the packet so all IPsec is done using the initially chosen  
address pair (the ULIDs) regardless of what locator the packets end  
up having in the IP header.

> - there is a potential interoperability problem if a native (host)
> implementation with SPD/SAD based on ULIDs tries to set up SAs with  
> BITS
> or BITW implementations, which don't have visibility into the ULIDs.

What would happen in this case is that the initial shim negotiation  
will use A1/B1 and that works for both ends. However, if A is the  
native IPsec implementation and it detects a reachability problem it  
will start probing A2/B2 without an IPsec header. B will try to  
negotiate an SA for this but this will either confuse A or A will  
accept and there will be a new A2/B2 SA. However, shim packets from A  
to B won't use this SA, but shim packets from B to A will.  
Presumably, B will have a policy that rejects the shim packets unless  
they're protected, but A will not use IPsec towards B so B wont' see  
A. A will most likely not process IPsec protected shim packets from B  
because that would be the wrong IPsec/shim ordering, but of course it  
could.

In any event, the return routability check will fail so the A2/B2  
address pair will not be used.

So nothing bad will happen except a slight waste of time and packets.  
One option to avoid this would be to reverse our original idea about  
the layering of shim6 and IPsec and layer the shim above IPsec.  
Another option would be to detect the situation where the layering is  
different and either don't do the shim or have the native end reverse  
its layering. We could do this in shim signalling but this requires  
BIT* implementations to become aware of shim6. IMO, a better solution  
would be to handle this in IKE. But then, I'm not involved in IPsec  
so there could be tons of problems that I'm unaware of...

Delivery-date: Wed, 09 Aug 2006 12:42:04 +0000
To: marcelo bagnulo braun <[email-masked]>
Cc: Francis Dupont <[email-masked]>, Shinta Sugimoto <[email-masked]>, shim6-wg <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: visibility of identifier in shim6 payload packet (was: Re: IPsec !?...) 
Date: Thu, 3 Aug 2006 18:18:26 +0200

[resent from last week]

On 2-aug-2006, at 15:41, marcelo bagnulo braun wrote:

> i am not sure what do you mean at the same time.... these would be  
> different ways to implement BITW compatibility that need to be  
> negotiated in the shim6 protocol (or either the processing is done  
> completelly in the BITW device or the ULID pair option is included  
> in the payload header, so that the BITW device can restore the ULIDs)

> fwiw i am perfectly ok with doing only the first option...

So basically this means that IF a host with bump-in-the-wire IPsec  
support MUST implement the shim in the BITW module and the host  
itself MUST NOT do shim6?

The second option isn't an option because information in the packet  
can't be trusted.

Delivery-date: Wed, 09 Aug 2006 12:41:54 +0000
To: marcelo bagnulo braun <[email-masked]>
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

[resent from last week]

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: Wed, 09 Aug 2006 12:29:36 +0000
Cc: shim6-wg <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: Multiple security mechanisms
Date: Wed, 9 Aug 2006 15:29:00 +0300
To: Iljitsch van Beijnum <[email-masked]>

Hi Iljitsch,
El 09/08/2006, a las 14:11, Iljitsch van Beijnum escribi=F3:

> [BTW: I'm reposting three messages from last week that I don't think=20=

> made it to the list.]
>
> How about the following to move forward in the dicussion on HBA/CGA=20
> patent issues and the need/want for other security mechanisms:
>
> I still have to do a full review of the shim6 proto spec, but the way=20=

> I understand it, today, the security mechanism (HBA) is either an=20
> integral part of the signalling, or it's encapsulated into the shim6=20=

> signalling protocol.
>
> What if we make this the other way around? So we isolate the shim6=20
> signalling from the security and then allow multiple security=20
> mechanisms to encapsulate the signalling and send it over the wire=20
> using appropriate mechanisms. For the current stuff this would look=20
> like this:
>
> [shim header][shim signalling][HBA/CGA]
>
> or
>
> [shim header][HBA/CGA][shim signalling]
>
> The changes, if needed, should be minimal: just move the HBA/CGA stuff=20=

> and the shim6 signalling to opposite ends of the packet so they can be=20=

> easily separated.
>

i think it would be possible to achieve something similar to what you=20
are after with the current spec

The current spec defines the Locator List Option Format where the=20
alternative locators are carried.
Fro each of  the locators contained in the list, there is a field=20
called  Verification Method that states which is the verification=20
method for this locator. So, for each verification method, you would=20
need additional verification information that needs to be conveyed in=20
the message. In the case of HBA/CGA, there are two options defined,=20
namely, CGA Parameter Data Structure Option Format to carry the=20
parameter data structure and the CGA Signature Option Format for=20
carrying signature information (in the case of CGA)

If we want to support a different security method, what we need to do=20
is:-
Define a value of the Verification Method field, so that we can include=20=

the new verification method in the message (that is easy)

Define new options to carry additional information required by the=20
security method if required.

For the case of IPSec for instance, this wouldn't be necesary, i guess.=20=

If the packet passes the AH /ESP verification and the proper=20
certificate or manually configured pre shared is in placed, then the=20
locator is validated.

Similar approach could be used with TLS i guess.

 =46rom the protocol perspective, adding this mechanisms is trivial. I=20=

guess that the compexity is likely to be in the interaction between the=20=

processes in the host itself, but i would expect this to work

regards, marcelo

> Then, if someone were to take it upon themselves to specify shim6 with=20=

> TLS security or shim6 with IPsec security, that would look like this:
>
> [tcp][tls([shim signalling])]
>
> [esp([udp][shim6 signalling])]
>
> [ah][udp][shim6 signalling]
>
> Additionally, the TLS/IKE people can define extensions to their=20
> protocols to signal the capability to do shim6 and if both sides=20
> support it and the necessary prerequisites are met (certificates at=20
> both ends, for instance), they can trigger a shim signalling exchange=20=

> protected by TLS or IPsec so we wouldn't need to implement complex=20
> capability negotiations in shim6, and if desired, the shim6 signalling=20=

> can be encrypted for additional security.
>

Delivery-date: Wed, 09 Aug 2006 11:12:22 +0000
To: shim6-wg <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Multiple security mechanisms
Date: Wed, 9 Aug 2006 13:11:11 +0200

[BTW: I'm reposting three messages from last week that I don't think  
made it to the list.]

How about the following to move forward in the dicussion on HBA/CGA  
patent issues and the need/want for other security mechanisms:

I still have to do a full review of the shim6 proto spec, but the way  
I understand it, today, the security mechanism (HBA) is either an  
integral part of the signalling, or it's encapsulated into the shim6  
signalling protocol.

What if we make this the other way around? So we isolate the shim6  
signalling from the security and then allow multiple security  
mechanisms to encapsulate the signalling and send it over the wire  
using appropriate mechanisms. For the current stuff this would look  
like this:

[shim header][shim signalling][HBA/CGA]

or

[shim header][HBA/CGA][shim signalling]

The changes, if needed, should be minimal: just move the HBA/CGA  
stuff and the shim6 signalling to opposite ends of the packet so they  
can be easily separated.

Then, if someone were to take it upon themselves to specify shim6  
with TLS security or shim6 with IPsec security, that would look like  
this:

[tcp][tls([shim signalling])]

[esp([udp][shim6 signalling])]

[ah][udp][shim6 signalling]

Additionally, the TLS/IKE people can define extensions to their  
protocols to signal the capability to do shim6 and if both sides  
support it and the necessary prerequisites are met (certificates at  
both ends, for instance), they can trigger a shim signalling exchange  
protected by TLS or IPsec so we wouldn't need to implement complex  
capability negotiations in shim6, and if desired, the shim6  
signalling can be encrypted for additional security.

Delivery-date: Wed, 09 Aug 2006 07:04:59 +0000
Cc: "Henderson, Thomas R" <[email-masked]>, <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: IPsec Issue Discussed for Shim6 at IETF Meeting July 10, 2006
Date: Wed, 9 Aug 2006 10:03:55 +0300
To: "Bound, Jim" <[email-masked]>

El 08/08/2006, a las 17:00, Bound, Jim escribi=F3:

> HBA does not prevent attacks that IPsec does.  See IPsec.
>

i agree with this

let's see if you agree with the following statements:

- in any case, some of the attacks that are prevented by IPSec are not=20=

prevented by HBA

- It is possible to build a security mechanisms to protect the shim6=20
protocol using IPSec with preshared keys or with PKI that actually=20
prevents all the threats described in RFC4218

- It is not possible to build a security mechanisms to protect the=20
shim6 protocol using IPSec without preshared keys nor PKI that prevents=20=

all the threats described in RFC4218 (in particular, it is not possible=20=

to provide protection against redirection of future communications to a=20=

given identifier)

If you do not agree with the last bullet, please describe how would you=20=

build a security mechanisms for the shim6 protocol that actually=20
protects from this type of attacks using IPSec without using pre shared=20=

keys or PKI. I mean if you can provide an actual solution that works,=20
it would be really useful because we could compare them and see the=20
pros and cons. Comparing a full fleshed silution like HBA with some=20
undocumented solution based on IPSec is extremely hard...

> By Red Herring for IPsec PKI I am saying that the issue of PKI is=20
> often used to not use end-to-end today (as I described it before)=20
> because of PKI and just a means to win another technology discussion=20=

> point often to support the further use of mid-com boxes which is in=20
> the way of true end-to-end.  It is an art of negotiations to position=20=

> that which is not the issue against the real issue avoiding addressing=20=

> the real issue. IPsec is now being used as strategy by every=20
> government and industry I know for those deploying not just IPv6. It=20=

> provides defense in depth at layer 3.  Not having it as an option for=20=

> shim6 is irresponsible by us in an IETF shim6 WG.
>

but this is not the case...

i mean the shim6 is completelly compatible with IPSec (or it should=20
be). The goal is that you can use shim6 and IPSec toghether in the same=20=

communication, i don't think there is any doubt about it.

The problem is that IPSec does not provides all the protection that it=20=

is required by the shim protocol if there are no pre shared keys or=20
PKI, so we need additional tools in this case. It would be=20
irresponsible by us to accept a solution that introduces critical=20
vulnerabilities like identify hijacking by supporting opportunistic=20
IPSec as a security solution for the shim protocol

So, i fully agree that shim6 and IPSec must run together, Moreover, i=20
think it is a good idea that if the peers are already using IPSec and=20
they have a preshared key or a pki with a common anchor point=20
available, they use IPSec to protect the shim6 protocol. What is more,=20=

i am willing to work with you to design such approach and write it down=20=

in an ID and see that it fits in the shim6 protocol. However, we must=20
provide an alternative solution for the case where the pre shared kay=20
and the PKI are not available and a security solution based on IPSEc in=20=

not secure enough for this case. So far this solution is based on the=20
HBAs

> The compromise I suggest to the WG is remove any security from base=20
> shim6 spec which will never be deployed at least for 3 years and=20
> permit the WG to work on multiple solutions as an exercise.

again i don't think that we can send a protocol wihtout proper=20
security, it is just a useless protocol, since it cannot be deployed=20
(and i guess that the IESG will reject it)

my suggestion is let's discuss the security solutions now... we have=20
been working on this too long to delay it further.

we can design a security solution based on IPSecfor the case were it=20
can be used safely (preshared key or PKI)

>  In the interim for any testing or scoping IPsec can be clearly used=20=

> in R&D labs to secure packets.  And any shime6 IP stack implementation=20=

> should be architected in products to be modular to support multiple=20
> means to secure Locator communications for session use for=20
> multihoming.

this is already the case

the current version of the shim6 protocol does support multiple=20
security mechanism and can be extended to other security mechanisms
that is why i say that it would straight forward to design a solution=20
based on IPSEc with preshared keys or PKI

regards, marcelo

>   We should also only conceptually specify the layer model whether=20
> above IP, above TCP, etc. (note do not assume a strict layering model=20=

> IP can call TCP etc. at any point time and vice/versa).
>
> The entire discussion regarding Security for shim6 should be required=20=

> to be reviewed by the IPsec WG and IETF Security Area Directorate.
>
> Best,
> /jim
>
>
>
>> -----Original Message-----
>> From: marcelo bagnulo braun [mailto:[email-masked]]
>> Sent: Tuesday, August 08, 2006 2:45 AM
>> To: Bound, Jim
>> Cc: Henderson, Thomas R; [email-masked]
>> Subject: Re: IPsec Issue Discussed for Shim6 at IETF Meeting
>> July 10, 2006
>>
>>
>> El 07/08/2006, a las 17:31, Bound, Jim escribi=F3:
>>
>>> Tom, I explained in my last mail. Ipsec should not have used IP
>>> addresses but it is all we have today and cannot achieve
>> consensus on
>>> identifiers anywhere in any SDO or consortia.  Today it is
>> a fast path
>>> for IPsec to parse the IP header off the IP stack interrupt
>> queue and
>>> permits us to drop the packet immediately if SA issue is found. HBA
>>> does not give me enough comfort or the shim6 protocol to alter that
>>> implementation behavior and also creates additional
>> security problems.
>>
>> could you describe what are the security problems introduced
>> by the shim protocols what HBA CGA are used?
>>
>>> Just leave it encapsulated under IP and decrypt from IPv6.
>>
>> this doesn't provide protection against identity hijacking attacks
>>
>>>   The PKI and
>>> Pre-Shared key issue is a red herring,
>>
>> what do you mean by this?
>> Do you think that using IPSec without PKI or preshared keys
>> is good enough?
>>
>> regards, marcelo
>>
>>
>>>  once we have an established IPv6
>>> address between nodes IPsec works just fine.  =46rom there
>> shim6 can use
>>> IPsec to pass locators.
>>>
>>> Best,
>>> /jim
>>>
>>>> -----Original Message-----
>>>> From: Henderson, Thomas R [mailto:[email-masked]]
>>>> Sent: Wednesday, August 02, 2006 12:02 PM
>>>> To: Bound, Jim; [email-masked]
>>>> Subject: RE: IPsec Issue Discussed for Shim6 at IETF
>> Meeting July 10,
>>>> 2006
>>>>
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: Bound, Jim [mailto:[email-masked]]
>>>>> Sent: Tuesday, July 11, 2006 3:44 AM
>>>>> To: [email-masked]
>>>>> Subject: IPsec Issue Discussed for Shim6 at IETF Meeting
>>>> July 10, 2006
>>>>>
>>>>> 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.
>>>>>
>>>>
>>>> Jim,
>>>> Can you clarify this historical note?  I wasn't around for
>> the IPsec
>>>> discussions then but I did go back to look at the mail list at the
>>>> time and it seems that, in fact, IPsec did adopt an out-of-band
>>>> signaling exchange (IKE), and that in-band (SKIP proposal) was
>>>> rejected.  Here is the start of a thread on this subject:
>>>> http://www.sandelman.ottawa.on.ca/ipsec/1995/02/msg00096.html
>>>> but you seem to be using the terminology differently.
>>>>
>>>> I can't find it written down anywhere that the locator
>> pair in the IP
>>>> header on the wire must be those used at the point of IPsec
>>>> processing for encrypt and decrypt.
>>>>
>>>> Tom
>>>>
>>>>
>>>
>>
>>
>

Delivery-date: Tue, 08 Aug 2006 14:01:32 +0000
Content-class: urn:content-classes:message
Subject: RE: IPsec Issue Discussed for Shim6 at IETF Meeting July 10, 2006
Date: Tue, 8 Aug 2006 10:00:13 -0400
From: "Bound, Jim" <[email-masked]>
To: "marcelo bagnulo braun" <[email-masked]>
Cc: "Henderson, Thomas R" <[email-masked]>, <[email-masked]>

HBA does not prevent attacks that IPsec does.  See IPsec.

By Red Herring for IPsec PKI I am saying that the issue of PKI is often =
used to not use end-to-end today (as I described it before) because of =
PKI and just a means to win another technology discussion point often to =
support the further use of mid-com boxes which is in the way of true =
end-to-end.  It is an art of negotiations to position that which is not =
the issue against the real issue avoiding addressing the real issue. =
IPsec is now being used as strategy by every government and industry I =
know for those deploying not just IPv6. It provides defense in depth at =
layer 3.  Not having it as an option for shim6 is irresponsible by us in =
an IETF shim6 WG.

The compromise I suggest to the WG is remove any security from base =
shim6 spec which will never be deployed at least for 3 years and permit =
the WG to work on multiple solutions as an exercise.  In the interim for =
any testing or scoping IPsec can be clearly used in R&D labs to secure =
packets.  And any shime6 IP stack implementation should be architected =
in products to be modular to support multiple means to secure Locator =
communications for session use for multihoming.  We should also only =
conceptually specify the layer model whether above IP, above TCP, etc. =
(note do not assume a strict layering model IP can call TCP etc. at any =
point time and vice/versa).

The entire discussion regarding Security for shim6 should be required to =
be reviewed by the IPsec WG and IETF Security Area Directorate.

Best,
/jim

=20

> -----Original Message-----
> From: marcelo bagnulo braun [mailto:[email-masked]]=20
> Sent: Tuesday, August 08, 2006 2:45 AM
> To: Bound, Jim
> Cc: Henderson, Thomas R; [email-masked]
> Subject: Re: IPsec Issue Discussed for Shim6 at IETF Meeting=20
> July 10, 2006
>=20
>=20
> El 07/08/2006, a las 17:31, Bound, Jim escribi=F3:
>=20
> > Tom, I explained in my last mail. Ipsec should not have used IP=20
> > addresses but it is all we have today and cannot achieve=20
> consensus on=20
> > identifiers anywhere in any SDO or consortia.  Today it is=20
> a fast path=20
> > for IPsec to parse the IP header off the IP stack interrupt=20
> queue and=20
> > permits us to drop the packet immediately if SA issue is found. HBA=20
> > does not give me enough comfort or the shim6 protocol to alter that=20
> > implementation behavior and also creates additional=20
> security problems.
>=20
> could you describe what are the security problems introduced=20
> by the shim protocols what HBA CGA are used?
>=20
> > Just leave it encapsulated under IP and decrypt from IPv6.
>=20
> this doesn't provide protection against identity hijacking attacks
>=20
> >   The PKI and
> > Pre-Shared key issue is a red herring,
>=20
> what do you mean by this?
> Do you think that using IPSec without PKI or preshared keys=20
> is good enough?
>=20
> regards, marcelo
>=20
>=20
> >  once we have an established IPv6
> > address between nodes IPsec works just fine.  From there=20
> shim6 can use=20
> > IPsec to pass locators.
> >
> > Best,
> > /jim
> >
> >> -----Original Message-----
> >> From: Henderson, Thomas R [mailto:[email-masked]]
> >> Sent: Wednesday, August 02, 2006 12:02 PM
> >> To: Bound, Jim; [email-masked]
> >> Subject: RE: IPsec Issue Discussed for Shim6 at IETF=20
> Meeting July 10,=20
> >> 2006
> >>
> >>
> >>
> >>> -----Original Message-----
> >>> From: Bound, Jim [mailto:[email-masked]]
> >>> Sent: Tuesday, July 11, 2006 3:44 AM
> >>> To: [email-masked]
> >>> Subject: IPsec Issue Discussed for Shim6 at IETF Meeting
> >> July 10, 2006
> >>>
> >>> 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=20
> the locator=20
> >>> 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=20
> >>> specifically rejected as a method for IPsec when defining=20
> the IPsec=20
> >>> architecture back in 1995 at IETF Danvers meeting. In=20
> addition this=20
> >>> type of use of IPsec should be verified and supported by
> >> the IPsec WG
> >>> within the IETF.
> >>>
> >>
> >> Jim,
> >> Can you clarify this historical note?  I wasn't around for=20
> the IPsec=20
> >> discussions then but I did go back to look at the mail list at the=20
> >> time and it seems that, in fact, IPsec did adopt an out-of-band=20
> >> signaling exchange (IKE), and that in-band (SKIP proposal) was=20
> >> rejected.  Here is the start of a thread on this subject:
> >> http://www.sandelman.ottawa.on.ca/ipsec/1995/02/msg00096.html
> >> but you seem to be using the terminology differently.
> >>
> >> I can't find it written down anywhere that the locator=20
> pair in the IP=20
> >> header on the wire must be those used at the point of IPsec=20
> >> processing for encrypt and decrypt.
> >>
> >> Tom
> >>
> >>
> >
>=20
>=20

Delivery-date: Tue, 08 Aug 2006 13:51:45 +0000
Content-class: urn:content-classes:message
Subject: RE: visibility of identifier in shim6 payload packet 
Date: Tue, 8 Aug 2006 09:51:07 -0400
From: "Bound, Jim" <[email-masked]>
To: "marcelo bagnulo braun" <[email-masked]>
Cc: "Henderson, Thomas R" <[email-masked]>, "Francis Dupont" <[email-masked]>, "Shinta Sugimoto" <[email-masked]>, "shim6-wg" <[email-masked]>

I disagree with everything you support.  That is fine.  That is why we =
have WG discussions. No response.  This conversation at my end is over =
with you unless there are new data points we are going in a circle.  =
Much of it is projection for tomorrow. HBA should be removed from the =
core spec or I will object at IESG last call.  Sorry but I will not be =
able to keep up with this mail regularly until Aug 28th as best I can. =
THus silence is not acceptance or support from my end.

Best and Respectfully,
/jim=20

> -----Original Message-----
> From: marcelo bagnulo braun [mailto:[email-masked]]=20
> Sent: Tuesday, August 08, 2006 2:43 AM
> To: Bound, Jim
> Cc: Henderson, Thomas R; Francis Dupont; Shinta Sugimoto; shim6-wg
> Subject: Re: visibility of identifier in shim6 payload packet=20
>=20
>=20
> El 07/08/2006, a las 17:27, Bound, Jim escribi=F3:
>=20
> > Tom,
> >
> > I am on vacation Aug 7-28 but doing some of my non day job work at=20
> > times to clean up. My response below.  I cannot stay mail=20
> for mail but=20
> > hopefully this will help.
> >
> >> Basically, you (and Jim) seem to be arguing that, with=20
> IPsec, there=20
> >> can not be any packet transformation below the IPsec layer that=20
> >> cannot be undone by an intermediate device that looks only at the=20
> >> individual packets and doesn't have access to other context=20
> >> negotiated by key management or shim protocols, and that either:
> >> i) shim6 should be layered above IPsec and just work on=20
> the basis of=20
> >> locators and perhaps use mobike techniques or just create new SAs=20
> >> when locators change, or
> >> ii) shimmed packets must carry the ULID in each packet for the=20
> >> benefit of BITW/BITS implementations
> >
> > The flaw in IPsec is the use of addresses, but we cannot=20
> agree in the=20
> > IETF or elsewhere what is the best identity.  If IPsec is used the=20
> > issues for RFC 4218 are highly reduced,
>=20
> not really
>=20
> IPSec without pre shared key or PKI does not provides=20
> identity protection. This means that basically IPSec without=20
> pre shared key or PKI mostly allows the peers to be certain=20
> that they are communicating with the same peer all the time=20
> and that nodody has hijacked the ongoing communication.
>=20
> However, IPSec without pre shared keys or PKI does not=20
> provides protection for future attacks on the identity=20
> meaning that it is trivial to hijack all future=20
> communications that a hosts wants to do with a given identity.
>=20
> I don't think this is acceptable
>=20
> >  as IPsec Architeture does
> > provide security in depth defense at layer 3 for the node, use, and=20
> > LAN.
> > I am not saying we do not need multi-layered security above=20
> layer 2 or=20
> > TLS, in fact we do and far more than we have today.  But, for shim6=20
> > IPsec is fine to secure the negotiations of the locators.  PKI or=20
> > Pre-Shared keys issue are orthogonal to the securing of ULIDs=20
> > completely and unlike some here I don't see a problem for the=20
> > evolution of PKI for IPsec between peers.
>=20
> yes, we disagree on this point
>=20
> i don't see PKI as a realistic option in the mid future
>=20
> >
> > Regarding end-to-end.  No IPsec did not say that exactly=20
> the Internet=20
> > architecture states it is the best scenario.  I want the ability to=20
> > encrypt my packet to you so that no one on the planet, except with=20
> > proper law enforcement, can see anything in my IPv6 packet=20
> but the IP=20
> > header and hop-by-hop or destination options.
>=20
> yes, but i guess you also want that it is not trivial to=20
> hijack all the future communication tht are addressed to your=20
> IP address
>=20
> using the current shim and IPSec you can have both
>=20
>=20
>=20
>=20
> >  If an intermediate box
> > has the authority to decrypt (meainging permission from the=20
> end-nodes=20
> > or the authority of the end-nodes) the packet that is fine, but I=20
> > suggest that decryption not interfere with the line rates of the=20
> > communications NIC and IO communications between the end-nodes.
> >
> >>
> >> But I think the above is a limiting view of IPsec, and is not=20
> >> consistent with reality that there may be IPsec (native
> >> end-to-end) within IPsec
> >> (BITW) that changes the selectors available to BITW, or NATs.
> >
> > Today implementations are built to decrypt as fast path with the IP=20
> > header.  That is simply the case today.
> >
>=20
> yes, but the point is that those implementations have decided=20
> to implement in hardware everything below the IPSec. So this=20
> means that any change in the stack in IPsec or below, will=20
> result in updating this piece of hardware. So, yes, if you=20
> want to implement shim or if you want to implement MIP HoA=20
> processing or MIP routing header processing or SeND=20
> processing or additional IPSec crypto algorithm or any other=20
> protocol that is below IPSec you need to update these pieces=20
> of hardware, but i guess this is normal, since the=20
> implementation is in hardware.
>=20
> > CGA further exacerbates the broken issues of IPsec by=20
> relying on an IP=20
> > address based keying and also cannot support multi-prefix=20
> scenarios as=20
> > I understand the method. HBA uses CGA spec and is still=20
> address based=20
> > keying.  We need to remvove HBA from the core shim6 spec=20
> and leave a=20
> > template for multiple solutions that are TBD.
>=20
> I don't think this is an option. I mean shim without proper=20
> security is simply inacceptable. We must provide a security=20
> mechanism (at least
> one) from the start of the shim will not fly. And saying use=20
> IPSec in the security considerations section will not fly,=20
> because oportunistic IPSec does not make a proper job and pre=20
> shared keys and PKI are not feasible in the short term.
>=20
> I mean, consider the MIPv6 experience.
>=20
> In the early versions of the draft you can find the following=20
> the security cosniderations
>=20
> this is from draft-ietf-mobileip-ipv6-09.txt
>=20
> 13. Security Considerations
>=20
> 13.1. Binding Updates, Acknowledgements, and Requests
>=20
>     The Binding Update option described in this document will result
>     in packets addressed to a mobile node being delivered instead to
>     its care-of address.  This ability to change the routing of these
>     packets could be a significant vulnerability if any=20
> packet containing
>     a Binding Update option was not authenticated.  Such use=20
> of "remote
>     redirection", for instance as performed by the Binding=20
> Update option,
>     is widely understood to be a security problem in the=20
> current Internet
>     if not authenticated [1].
>=20
>     The Binding Acknowledgement option also requires authentication,
>     since, for example, an attacker could otherwise trick a=20
> mobile node
>     into believing a different outcome from a registration=20
> attempt with
>     its home agent.
>=20
>     No authentication is required for the Binding Request=20
> option, since
>     the use of this option does not modify or create any=20
> state in either
>     the sender or the receiver.  The Binding Request option does open
>     some issues with binding privacy, but those issues can be=20
> dealt with
>     either through existing IPsec encryption mechanisms or=20
> through use of
>     firewalls.
>=20
>     The existing IPsec replay protection mechanisms allow a "replay
>     protection window" to support receiving packets out of order.
>     Although appropriate for many forms of communication,=20
> Binding Updates
>     MUST be applied only in the order sent.  The Binding Update option
>     thus includes a Sequence Number field to provide this necessary
>     sequencing.  The use of this Sequence Number together with IPsec
>     replay protection is similar in many ways, for example, to the the
>     sequence number in TCP.  IPsec provides strong replay=20
> protection but
>     no ordering, and the sequence number provides ordering=20
> but need not
>     worry about replay protection such as through the sequence number
>     wrapping around.
>=20
>=20
> basically they were saying "use IPSec" for this and the=20
> problems are solved
>=20
> This turned out to not be the case since IPSec is not an=20
> option because the reasons i mentioned above
>=20
> the case was that the IESG returned the protocol to the wg=20
> and they needed to work out a deployable real solution
>=20
> i think we are in the same case here
>=20
> shim without security is simply inacceptable because of the=20
> vulnerabilities that it introduces
>=20
> IPSec is not a realistic option (or it requires pre shared=20
> key or a PKI)
>=20
> regards, marcelo
>=20
>=20
> >
> > Best,
> > /jim
> >
> >>
> >> Tom
> >>
> >
>=20
>=20

Delivery-date: Tue, 08 Aug 2006 13:06:17 +0000
Cc: shim6-wg <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: visibility of identifier in shim6 payload packet
Date: Tue, 8 Aug 2006 16:06:05 +0300
To: Jari Arkko <[email-masked]>

El 08/08/2006, a las 15:50, Jari Arkko escribi=F3:

> marcelo bagnulo braun wrote:
>
>>
>> shim without proper security is simply inacceptable. We must provide =
a
>> security mechanism (at least one) from the start of the shim will not=20=

>> fly.
>
> I fully agree with this.
>
>> And saying use IPSec in the security considerations section will not
>> fly, because oportunistic IPSec does not make a proper job and pre
>> shared keys and PKI are not feasible in the short term.
>
> The short version of my opinion is that I do
> not see IPsec as a mechanism that satisfies
> the goals of Shim6.
>
> The longer version: I do like modular design,
> and I don't mind having the possibility of several
> different methods, possibly including IPsec, to
> exist in addition to the mandatory to implement
> mechanism for Shim6.
>

i am perfectly ok with this modular approach and supporting different=20
security moduls that can be added later

moreover, i also like Francis suggestion to _re-use_ IPSec for security=20=

_when_ the peers are already using IPSec for their communications and=20
it happens that for this particular pair of communicating peers, the=20
tools for providing authentications are in place for that particular=20
pair of hosts (i.e. the hosts already have a pre shared key or they are=20=

using certificates issued with a common trust anchor point)

but the shim6 protocol needs to have a default security mechanism that=20=

applies for the general case and IPSec is not it

Regards, marcelo

Delivery-date: Tue, 08 Aug 2006 12:52:18 +0000
Date: Tue, 08 Aug 2006 15:50:42 +0300
From: Jari Arkko <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
CC: shim6-wg <[email-masked]>
Subject: Re: visibility of identifier in shim6 payload packet

marcelo bagnulo braun wrote:

>
> shim without proper security is simply inacceptable. We must provide a
> security mechanism (at least one) from the start of the shim will not fly.

I fully agree with this.

> And saying use IPSec in the security considerations section will not
> fly, because oportunistic IPSec does not make a proper job and pre
> shared keys and PKI are not feasible in the short term.

The short version of my opinion is that I do
not see IPsec as a mechanism that satisfies
the goals of Shim6.

The longer version: I do like modular design,
and I don't mind having the possibility of several
different methods, possibly including IPsec, to
exist in addition to the mandatory to implement
mechanism for Shim6.

However, I believe that the low-hanging fruit for
IPsec use in the multihoming and mobility space
has already been picked, and that trying to do
something as ambitious as Shim6 with IPsec
as the primary mechanism would not succeed.

The low-hanging fruit is MOBIKE. This protocol
provides multihoming and mobility functions, and
it assumes that sufficient security associations
already exist for other reasons. In practical terms
this translates to usage in the VPN space, between
the VPN client and the VPN gateway. Its very easy
to deploy and it works. But its also already done,
and I see no reason to design new protocols that
do the same thing.

Also, extending this functionality to host to host
behaviour would face significant challenges.
There is no global authentication infrastructure
between hosts, and its not clear to me that such
infrastructure would even be desirable. Furthermore,
if the protocols were lightweight (no per packet
protection) as the Shim6 WG wanted, even
an authentication infrastructure would not
help at all, unless it had knowledge of which
hosts owned which addresses.

There is one design option which does seem
plausible, however, and does not require
authentication infrastructure. Namely,
opportunistic mode where all communications
are always bound to an ephemeral identity.
But this is again something that has already
been built -- HIP.

So from my point of view the only design that
can be made to match the requirements that
the Shim6 WG felt where important -- deployability,
ability to deal with referrals, avoiding overhead,
etc. is in the current documents. We can add
modularity and secondary authentication tools
if people feel that is important, however.

--Jari

Delivery-date: Tue, 08 Aug 2006 06:45:17 +0000
Cc: "Henderson, Thomas R" <[email-masked]>, <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: IPsec Issue Discussed for Shim6 at IETF Meeting July 10, 2006
Date: Tue, 8 Aug 2006 09:45:17 +0300
To: "Bound, Jim" <[email-masked]>

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

> Tom, I explained in my last mail. Ipsec should not have used IP
> addresses but it is all we have today and cannot achieve consensus on
> identifiers anywhere in any SDO or consortia.  Today it is a fast path
> for IPsec to parse the IP header off the IP stack interrupt queue and
> permits us to drop the packet immediately if SA issue is found. HBA=20
> does
> not give me enough comfort or the shim6 protocol to alter that
> implementation behavior and also creates additional security problems.

could you describe what are the security problems introduced by the=20
shim protocols what HBA CGA are used?

> Just leave it encapsulated under IP and decrypt from IPv6.

this doesn't provide protection against identity hijacking attacks

>   The PKI and
> Pre-Shared key issue is a red herring,

what do you mean by this?
Do you think that using IPSec without PKI or preshared keys is good=20
enough?

regards, marcelo

>  once we have an established IPv6
> address between nodes IPsec works just fine.  =46rom there shim6 can =
use
> IPsec to pass locators.
>
> Best,
> /jim
>
>> -----Original Message-----
>> From: Henderson, Thomas R [mailto:[email-masked]]
>> Sent: Wednesday, August 02, 2006 12:02 PM
>> To: Bound, Jim; [email-masked]
>> Subject: RE: IPsec Issue Discussed for Shim6 at IETF Meeting
>> July 10, 2006
>>
>>
>>
>>> -----Original Message-----
>>> From: Bound, Jim [mailto:[email-masked]]
>>> Sent: Tuesday, July 11, 2006 3:44 AM
>>> To: [email-masked]
>>> Subject: IPsec Issue Discussed for Shim6 at IETF Meeting
>> July 10, 2006
>>>
>>> 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.
>>>
>>
>> Jim,
>> Can you clarify this historical note?  I wasn't around for
>> the IPsec discussions then but I did go back to look at the
>> mail list at the time and it seems that, in fact, IPsec did
>> adopt an out-of-band signaling exchange (IKE), and that
>> in-band (SKIP proposal) was rejected.  Here is the start of a
>> thread on this subject:
>> http://www.sandelman.ottawa.on.ca/ipsec/1995/02/msg00096.html
>> but you seem to be using the terminology differently.
>>
>> I can't find it written down anywhere that the locator pair
>> in the IP header on the wire must be those used at the point
>> of IPsec processing for encrypt and decrypt.
>>
>> Tom
>>
>>
>

Delivery-date: Tue, 08 Aug 2006 06:44:00 +0000
Cc: "Henderson, Thomas R" <[email-masked]>, "Francis Dupont" <[email-masked]>, "Shinta Sugimoto" <[email-masked]>, "shim6-wg" <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: visibility of identifier in shim6 payload packet 
Date: Tue, 8 Aug 2006 09:42:58 +0300
To: "Bound, Jim" <[email-masked]>

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

> Tom,
>
> I am on vacation Aug 7-28 but doing some of my non day job work at=20
> times
> to clean up. My response below.  I cannot stay mail for mail but
> hopefully this will help.
>
>> Basically, you (and Jim) seem to be arguing that, with IPsec,
>> there can not be any packet transformation below the IPsec
>> layer that cannot be undone by an intermediate device that
>> looks only at the individual packets and doesn't have access
>> to other context negotiated by key management or shim
>> protocols, and that either:
>> i) shim6 should be layered above IPsec and just work on the
>> basis of locators and perhaps use mobike techniques or just
>> create new SAs when locators change, or
>> ii) shimmed packets must carry the ULID in each packet for the =
benefit
>> of BITW/BITS implementations
>
> The flaw in IPsec is the use of addresses, but we cannot agree in the
> IETF or elsewhere what is the best identity.  If IPsec is used the
> issues for RFC 4218 are highly reduced,

not really

IPSec without pre shared key or PKI does not provides identity=20
protection. This means that basically IPSec without pre shared key or=20
PKI mostly allows the peers to be certain that they are communicating=20
with the same peer all the time and that nodody has hijacked the=20
ongoing communication.

However, IPSec without pre shared keys or PKI does not provides=20
protection for future attacks on the identity meaning that it is=20
trivial to hijack all future communications that a hosts wants to do=20
with a given identity.

I don't think this is acceptable

>  as IPsec Architeture does
> provide security in depth defense at layer 3 for the node, use, and=20
> LAN.
> I am not saying we do not need multi-layered security above layer 2 or
> TLS, in fact we do and far more than we have today.  But, for shim6
> IPsec is fine to secure the negotiations of the locators.  PKI or
> Pre-Shared keys issue are orthogonal to the securing of ULIDs=20
> completely
> and unlike some here I don't see a problem for the evolution of PKI =
for
> IPsec between peers.

yes, we disagree on this point

i don't see PKI as a realistic option in the mid future

>
> Regarding end-to-end.  No IPsec did not say that exactly the Internet
> architecture states it is the best scenario.  I want the ability to
> encrypt my packet to you so that no one on the planet, except with
> proper law enforcement, can see anything in my IPv6 packet but the IP
> header and hop-by-hop or destination options.

yes, but i guess you also want that it is not trivial to hijack all the=20=

future communication tht are addressed to your IP address

using the current shim and IPSec you can have both

>  If an intermediate box
> has the authority to decrypt (meainging permission from the end-nodes=20=

> or
> the authority of the end-nodes) the packet that is fine, but I suggest
> that decryption not interfere with the line rates of the =
communications
> NIC and IO communications between the end-nodes.
>
>>
>> But I think the above is a limiting view of IPsec, and is not
>> consistent with reality that there may be IPsec (native
>> end-to-end) within IPsec
>> (BITW) that changes the selectors available to BITW, or NATs.
>
> Today implementations are built to decrypt as fast path with the IP
> header.  That is simply the case today.
>

yes, but the point is that those implementations have decided to=20
implement in hardware everything below the IPSec. So this means that=20
any change in the stack in IPsec or below, will result in updating this=20=

piece of hardware. So, yes, if you want to implement shim or if you=20
want to implement MIP HoA processing or MIP routing header processing=20
or SeND processing or additional IPSec crypto algorithm or any other=20
protocol that is below IPSec you need to update these pieces of=20
hardware, but i guess this is normal, since the implementation is in=20
hardware.

> CGA further exacerbates the broken issues of IPsec by relying on an IP
> address based keying and also cannot support multi-prefix scenarios as=20=

> I
> understand the method. HBA uses CGA spec and is still address based
> keying.  We need to remvove HBA from the core shim6 spec and leave a
> template for multiple solutions that are TBD.

I don't think this is an option. I mean shim without proper security is=20=

simply inacceptable. We must provide a security mechanism (at least=20
one) from the start of the shim will not fly. And saying use IPSec in=20
the security considerations section will not fly, because oportunistic=20=

IPSec does not make a proper job and pre shared keys and PKI are not=20
feasible in the short term.

I mean, consider the MIPv6 experience.

In the early versions of the draft you can find the following the=20
security cosniderations

this is from draft-ietf-mobileip-ipv6-09.txt

13. Security Considerations

13.1. Binding Updates, Acknowledgements, and Requests

    The Binding Update option described in this document will result
    in packets addressed to a mobile node being delivered instead to
    its care-of address.  This ability to change the routing of these
    packets could be a significant vulnerability if any packet =
containing
    a Binding Update option was not authenticated.  Such use of "remote
    redirection", for instance as performed by the Binding Update =
option,
    is widely understood to be a security problem in the current =
Internet
    if not authenticated [1].

    The Binding Acknowledgement option also requires authentication,
    since, for example, an attacker could otherwise trick a mobile node
    into believing a different outcome from a registration attempt with
    its home agent.

    No authentication is required for the Binding Request option, since
    the use of this option does not modify or create any state in either
    the sender or the receiver.  The Binding Request option does open
    some issues with binding privacy, but those issues can be dealt with
    either through existing IPsec encryption mechanisms or through use =
of
    firewalls.

    The existing IPsec replay protection mechanisms allow a "replay
    protection window" to support receiving packets out of order.
    Although appropriate for many forms of communication, Binding =
Updates
    MUST be applied only in the order sent.  The Binding Update option
    thus includes a Sequence Number field to provide this necessary
    sequencing.  The use of this Sequence Number together with IPsec
    replay protection is similar in many ways, for example, to the the
    sequence number in TCP.  IPsec provides strong replay protection but
    no ordering, and the sequence number provides ordering but need not
    worry about replay protection such as through the sequence number
    wrapping around.

basically they were saying "use IPSec" for this and the problems are=20
solved

This turned out to not be the case since IPSec is not an option because=20=

the reasons i mentioned above

the case was that the IESG returned the protocol to the wg and they=20
needed to work out a deployable real solution

i think we are in the same case here

shim without security is simply inacceptable because of the=20
vulnerabilities that it introduces

IPSec is not a realistic option (or it requires pre shared key or a PKI)

regards, marcelo

>
> Best,
> /jim
>
>>
>> Tom
>>
>

Delivery-date: Mon, 07 Aug 2006 14:33:09 +0000
Content-class: urn:content-classes:message
Subject: RE: IPsec Issue Discussed for Shim6 at IETF Meeting July 10, 2006
Date: Mon, 7 Aug 2006 10:32:59 -0400
From: "Bound, Jim" <[email-masked]>
To: "Henderson, Thomas R" <[email-masked]>, <[email-masked]>

On out-of-band As a note I was a supporter of SKIP.  Good point I had my
terminology backwards. What we are doing in shim6 is in-band-signaling.
So exactly my point thanks for the old references that is good hunting
on your part.

Thanks
/jim=20

> -----Original Message-----
> From: Henderson, Thomas R [mailto:[email-masked]]=20
> Sent: Wednesday, August 02, 2006 12:02 PM
> To: Bound, Jim; [email-masked]
> Subject: RE: IPsec Issue Discussed for Shim6 at IETF Meeting=20
> July 10, 2006
>=20
> =20
>=20
> > -----Original Message-----
> > From: Bound, Jim [mailto:[email-masked]]
> > Sent: Tuesday, July 11, 2006 3:44 AM
> > To: [email-masked]
> > Subject: IPsec Issue Discussed for Shim6 at IETF Meeting=20
> July 10, 2006
> >=20
> > 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 IPsec.
> > This is done
> > and possible because there is a context associated with the locator=20
> > pair from out-of-bound message exchange at each end point=20
> to identify=20
> > the ULIDs for location pair association.  This means the=20
> locator pair=20
> > in the IP header are not used for IPsec encyrpt and decrypt=20
> as is done=20
> > 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=20
> > within the IETF.
> >=20
>=20
> Jim,
> Can you clarify this historical note?  I wasn't around for=20
> the IPsec discussions then but I did go back to look at the=20
> mail list at the time and it seems that, in fact, IPsec did=20
> adopt an out-of-band signaling exchange (IKE), and that=20
> in-band (SKIP proposal) was rejected.  Here is the start of a=20
> thread on this subject:
> http://www.sandelman.ottawa.on.ca/ipsec/1995/02/msg00096.html
> but you seem to be using the terminology differently.
>=20
> I can't find it written down anywhere that the locator pair=20
> in the IP header on the wire must be those used at the point=20
> of IPsec processing for encrypt and decrypt.
>=20
> Tom
>=20
>=20

Delivery-date: Mon, 07 Aug 2006 14:31:38 +0000
Content-class: urn:content-classes:message
Subject: RE: IPsec Issue Discussed for Shim6 at IETF Meeting July 10, 2006
Date: Mon, 7 Aug 2006 10:31:28 -0400
From: "Bound, Jim" <[email-masked]>
To: "Henderson, Thomas R" <[email-masked]>, <[email-masked]>

Tom, I explained in my last mail. Ipsec should not have used IP
addresses but it is all we have today and cannot achieve consensus on
identifiers anywhere in any SDO or consortia.  Today it is a fast path
for IPsec to parse the IP header off the IP stack interrupt queue and
permits us to drop the packet immediately if SA issue is found. HBA does
not give me enough comfort or the shim6 protocol to alter that
implementation behavior and also creates additional security problems.
Just leave it encapsulated under IP and decrypt from IPv6.  The PKI and
Pre-Shared key issue is a red herring, once we have an established IPv6
address between nodes IPsec works just fine.  From there shim6 can use
IPsec to pass locators.

Best,
/jim=20

> -----Original Message-----
> From: Henderson, Thomas R [mailto:[email-masked]]=20
> Sent: Wednesday, August 02, 2006 12:02 PM
> To: Bound, Jim; [email-masked]
> Subject: RE: IPsec Issue Discussed for Shim6 at IETF Meeting=20
> July 10, 2006
>=20
> =20
>=20
> > -----Original Message-----
> > From: Bound, Jim [mailto:[email-masked]]
> > Sent: Tuesday, July 11, 2006 3:44 AM
> > To: [email-masked]
> > Subject: IPsec Issue Discussed for Shim6 at IETF Meeting=20
> July 10, 2006
> >=20
> > 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 IPsec.
> > This is done
> > and possible because there is a context associated with the locator=20
> > pair from out-of-bound message exchange at each end point=20
> to identify=20
> > the ULIDs for location pair association.  This means the=20
> locator pair=20
> > in the IP header are not used for IPsec encyrpt and decrypt=20
> as is done=20
> > 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=20
> > within the IETF.
> >=20
>=20
> Jim,
> Can you clarify this historical note?  I wasn't around for=20
> the IPsec discussions then but I did go back to look at the=20
> mail list at the time and it seems that, in fact, IPsec did=20
> adopt an out-of-band signaling exchange (IKE), and that=20
> in-band (SKIP proposal) was rejected.  Here is the start of a=20
> thread on this subject:
> http://www.sandelman.ottawa.on.ca/ipsec/1995/02/msg00096.html
> but you seem to be using the terminology differently.
>=20
> I can't find it written down anywhere that the locator pair=20
> in the IP header on the wire must be those used at the point=20
> of IPsec processing for encrypt and decrypt.
>=20
> Tom
>=20
>=20

Delivery-date: Mon, 07 Aug 2006 14:29:29 +0000
Content-class: urn:content-classes:message
Subject: RE: visibility of identifier in shim6 payload packet 
Date: Mon, 7 Aug 2006 10:27:55 -0400
From: "Bound, Jim" <[email-masked]>
To: "Henderson, Thomas R" <[email-masked]>, "Francis Dupont" <[email-masked]>
Cc: "Shinta Sugimoto" <[email-masked]>, "shim6-wg" <[email-masked]>

Tom,

I am on vacation Aug 7-28 but doing some of my non day job work at times
to clean up. My response below.  I cannot stay mail for mail but
hopefully this will help.=20

> Basically, you (and Jim) seem to be arguing that, with IPsec,=20
> there can not be any packet transformation below the IPsec=20
> layer that cannot be undone by an intermediate device that=20
> looks only at the individual packets and doesn't have access=20
> to other context negotiated by key management or shim=20
> protocols, and that either:
> i) shim6 should be layered above IPsec and just work on the=20
> basis of locators and perhaps use mobike techniques or just=20
> create new SAs when locators change, or
> ii) shimmed packets must carry the ULID in each packet for the benefit
> of BITW/BITS implementations=20

The flaw in IPsec is the use of addresses, but we cannot agree in the
IETF or elsewhere what is the best identity.  If IPsec is used the
issues for RFC 4218 are highly reduced, as IPsec Architeture does
provide security in depth defense at layer 3 for the node, use, and LAN.
I am not saying we do not need multi-layered security above layer 2 or
TLS, in fact we do and far more than we have today.  But, for shim6
IPsec is fine to secure the negotiations of the locators.  PKI or
Pre-Shared keys issue are orthogonal to the securing of ULIDs completely
and unlike some here I don't see a problem for the evolution of PKI for
IPsec between peers.

Regarding end-to-end.  No IPsec did not say that exactly the Internet
architecture states it is the best scenario.  I want the ability to
encrypt my packet to you so that no one on the planet, except with
proper law enforcement, can see anything in my IPv6 packet but the IP
header and hop-by-hop or destination options.  If an intermediate box
has the authority to decrypt (meainging permission from the end-nodes or
the authority of the end-nodes) the packet that is fine, but I suggest
that decryption not interfere with the line rates of the communications
NIC and IO communications between the end-nodes.
 =20
>=20
> But I think the above is a limiting view of IPsec, and is not=20
> consistent with reality that there may be IPsec (native=20
> end-to-end) within IPsec
> (BITW) that changes the selectors available to BITW, or NATs. =20

Today implementations are built to decrypt as fast path with the IP
header.  That is simply the case today.

CGA further exacerbates the broken issues of IPsec by relying on an IP
address based keying and also cannot support multi-prefix scenarios as I
understand the method. HBA uses CGA spec and is still address based
keying.  We need to remvove HBA from the core shim6 spec and leave a
template for multiple solutions that are TBD.

Best,
/jim

>=20
> Tom
>=20

Delivery-date: Mon, 07 Aug 2006 06:59:17 +0000
Cc: Shinta Sugimoto <[email-masked]>, Francis Dupont <[email-masked]>, shim6-wg <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: visibility of identifier in shim6 payload packet (was: Re: IPsec !?...) 
Date: Mon, 7 Aug 2006 09:58:13 +0300
To: Iljitsch van Beijnum <[email-masked]>

El 06/08/2006, a las 18:59, Iljitsch van Beijnum escribi=F3:

> [Does anyone know what has happened to the mailinglist? I only got one=20=

> message after wednesday and I posted three. I mailed Geoff and Kurtis=20=

> but to no avail.]
>
> On 6-aug-2006, at 9:36, marcelo bagnulo braun wrote:
>
>>> So basically this means that IF a host with bump-in-the-wire IPsec=20=

>>> support MUST implement the shim in the BITW module and the host=20
>>> itself MUST NOT do shim6?
>
>> well i would rephrase it a bit differently
>
>> a host may have different shim6 and IPSec implementations, native and=20=

>> BITW
>> If the host is using BITW IPSEc , then if it wants to implement the=20=

>> shim, it must use the BITW shim implementation...
>
> Right. I would like to express this as "if a host has BITW IPsec, the=20=

> host itself MUST NOT perform shim6 processing" so that if the host=20
> does shim6, this happens at or after the BITW module.
>
>>> The second option isn't an option because information in the packet=20=

>>> can't be trusted.
>
>> why not?
>
> Because I can make a packet that has my return address but has=20
> [email-masked] in the additional ULID field. This means that=20
> demultiplexing the packet on this field without additional security=20
> checks allows attackers to inject packets. Additional checks means=20
> state and if we have state anyway, being able to look up the context=20=

> ID or other demux info is not a big deal so there is no reason to have=20=

> a ULID field.
>

i think i fully agree with this

I mean i don't think that the ULID option is needed in this case
I mean when we say that the BITW device implements the shim, it means=20
it completelly implements the shim, meaning that it has the shim state,=20=

the HBA verification, the HBA state and all the whole lot

I mean, fro the protocol perspective nothing changes, only that the=20
implementation is in hardware in the BITW device, rather than in=20
software...

> (Yes, this means that MIPv6 got it wrong.)
>
>

but now they are proposing to remove the option (for privacy issues)

regards, marcelo

Delivery-date: Sun, 06 Aug 2006 16:01:00 +0000
Cc: Shinta Sugimoto <[email-masked]>, Francis Dupont <[email-masked]>, shim6-wg <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: visibility of identifier in shim6 payload packet (was: Re: IPsec !?...) 
Date: Sun, 6 Aug 2006 17:59:46 +0200
To: marcelo bagnulo braun <[email-masked]>

[Does anyone know what has happened to the mailinglist? I only got  
one message after wednesday and I posted three. I mailed Geoff and  
Kurtis but to no avail.]

On 6-aug-2006, at 9:36, marcelo bagnulo braun wrote:

>> So basically this means that IF a host with bump-in-the-wire IPsec  
>> support MUST implement the shim in the BITW module and the host  
>> itself MUST NOT do shim6?

> well i would rephrase it a bit differently

> a host may have different shim6 and IPSec implementations, native  
> and BITW
> If the host is using BITW IPSEc , then if it wants to implement the  
> shim, it must use the BITW shim implementation...

Right. I would like to express this as "if a host has BITW IPsec, the  
host itself MUST NOT perform shim6 processing" so that if the host  
does shim6, this happens at or after the BITW module.

>> The second option isn't an option because information in the  
>> packet can't be trusted.

> why not?

Because I can make a packet that has my return address but has  
[email-masked] in the additional ULID field. This means that  
demultiplexing the packet on this field without additional security  
checks allows attackers to inject packets. Additional checks means  
state and if we have state anyway, being able to look up the context  
ID or other demux info is not a big deal so there is no reason to  
have a ULID field.

(Yes, this means that MIPv6 got it wrong.)

Delivery-date: Sun, 06 Aug 2006 07:38:27 +0000
Cc: Shinta Sugimoto <[email-masked]>, Francis Dupont <[email-masked]>, shim6-wg <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: visibility of identifier in shim6 payload packet (was: Re: IPsec !?...) 
Date: Sun, 6 Aug 2006 10:36:09 +0300
To: Iljitsch van Beijnum <[email-masked]>

El 03/08/2006, a las 19:18, Iljitsch van Beijnum escribi=F3:

> On 2-aug-2006, at 15:41, marcelo bagnulo braun wrote:
>
>> i am not sure what do you mean at the same time.... these would be=20
>> different ways to implement BITW compatibility that need to be=20
>> negotiated in the shim6 protocol (or either the processing is done=20
>> completelly in the BITW device or the ULID pair option is included in=20=

>> the payload header, so that the BITW device can restore the ULIDs)
>
>> fwiw i am perfectly ok with doing only the first option...
>
> So basically this means that IF a host with bump-in-the-wire IPsec=20
> support MUST implement the shim in the BITW module and the host itself=20=

> MUST NOT do shim6?
>

well i would rephrase it a bit differently

a host may have different shim6 and IPSec implementations, native and=20
BITW
If the host is using BITW IPSEc , then if it wants to implement the=20
shim, it must use the BITW shim implementation... after all, if it is=20
using the BITW IPSec, then the packet is already in the hardware device=20=

when it enters the IPSec module, and if we want to do something below=20
IPSec we must do it in the hardware device itself, right?

If the host is using native IPSec, the it can use either BITW shim or=20
native shim, since there is no constraints about the packet already=20
being placed in the hardware device

> The second option isn't an option because information in the packet=20
> can't be trusted.
>
>

why not? I mean, what we are talking here is about implementations,=20
right? the protocol and the security features/mechaisms are exactly the=20=

same, independetly of the implementation, right? i mean a BITW shim=20
implementation still uses HBAs and other shim6 security features, only=20=

that in this case, the processing is implemented in hardware, right?

Regards, marcelo

Delivery-date: Fri, 04 Aug 2006 09:54:35 +0000
Date: Fri, 04 Aug 2006 11:50:31 +0200
From: Xiaoming Fu <[email-masked]>
To:  [email-masked],  [email-masked],  [email-masked]
Subject: MobiArch'06 - submission deadline in 3 days!

===================================================================
MobiArch 2006 - Last Call for Papers - Paper submission by 7 August
===================================================================

(Apologies if you receive multiple copies of this CfP)

Dear Colleagues,

A reminder that the paper submission deadline for the 1st Workshop on
Mobility in the Evolving Internet Architecture (San Francisco, CA, USA,
December 1, 2006, in conjunction with IEEE GLOBECOM 2006) will be coming
up soon.

- EDAS paper submission deadline (firm):  **** August 7, 2006 ****
- URL: http://user.informatik.uni-goettingen.de/~mobiarch

Please consult the above URL for details regarding submissions.

On behalf of the MobiArch'06 team,
Xiaoming Fu, University of Goettingen <[email-masked]>

Envelope-to: [email-masked]
Delivery-date: Wed, 02 Aug 2006 14:01:31 +0000
Message-Id: <[email-masked]>
From: Francis Dupont <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
cc: Shinta Sugimoto <[email-masked]>, shim6-wg <[email-masked]>
Subject: Re: visibility of identifier in shim6 payload packet (was: Re: IPsec !?...) 
Date: Wed, 02 Aug 2006 16:00:46 +0200

 In your previous mail you wrote:

   so, in order to do this options, do we need to do any changes to the 
   protocol spec?
   
=> in the protocol itself I don't think so. But the control of
the protocol could be different, in particular if the BITW is
"transparent".

   As i understand it, what is needed woudl be to mention that this is the 
   expected way to implement the shim processing if BITW is used... 
   something else?
   
=> we have to check if it is feasible in the whole world
and scan specs to change any detail which assumes a native implementation
for SHIM6.

   fwiw i am perfectly ok with doing only the first option... does anyone 
   has a problem with adopting only the first option above? (at least for 
   now)
   
=> you should ask Jim and firewall people too.   
   
Regards

[email-masked]

Envelope-to: [email-masked]
Delivery-date: Wed, 02 Aug 2006 13:46:29 +0000
Message-Id: <[email-masked]>
From: Francis Dupont <[email-masked]>
To: Shinta Sugimoto <[email-masked]>
cc: marcelo bagnulo braun <[email-masked]>, "Christian Huitema" <[email-masked]>, "shim6-wg" <[email-masked]>, "Iljitsch van Beijnum" <[email-masked]>
Subject: Re: visibility of identifier in shim6 payload packet (was: Re: IPsec !?...) 
Date: Wed, 02 Aug 2006 15:46:10 +0200

 In your previous mail you wrote:

   I am not saying that we should give up providing the compatibility.
   I am saying that we should first take a look at the problem, and
   see how serious the problem is.  I am not sure if the combination
   of SHIM6 and BITW IPsec is totally infeasible or not, so I need
   clarification.
   
=> note that we have the architectural point of view (i.e., Jim's
concern) which is the same issue but with another kind of arguments.

   Based on assumption that BITW IPsec should be completely transparent
   to the ULPs (including SHIM6 as its a conceptual sublayer within IP
   layer), I don't see why SHIM6 over BITW IPsec would not work.

=> what do you mean with SHIM6 over BITW IPsec? Don't forget the kind
of IPsec implementations is transparent too, i.e., the provided service
is the same, and in particular the traffic selectors are the ULIDs when
the device fiddles about the bits in the wire.

    it would not be optimum operation, but that's same in the case of
   normal IP host connected to multihomed site over BITW device isn't it?
   (Please correct me if I am wrong)

=> I can't say: I don't understand your idea.

   I agree with your statement, in general.  But I would like to see if
   the problem that we are talking about is a problem newly created by
   the SHIM6 intermediation,

=> it is created by SHIM6 because, even we can consider it is a bad design,
IPsec needs to find its traffic selectors in the traffic packets and
the choice to put IPsec at an upper level than SHIM6 in the stack is
bot incompatible with an IPsec device running at the wire level and
raises a basic architectural issue on how IPsec knows the locators/ULID
binding.

Regards

[email-masked]

Delivery-date: Wed, 02 Aug 2006 13:42:17 +0000
Cc: Shinta Sugimoto <[email-masked]>, shim6-wg <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: visibility of identifier in shim6 payload packet (was: Re: IPsec !?...) 
Date: Wed, 2 Aug 2006 16:41:56 +0300
To: Francis Dupont <[email-masked]>

El 02/08/2006, a las 16:29, Francis Dupont escribi=F3:

>    i mean, as i understand this, part of the shim6 processing will be
>    performed by the BITW device. I guess we have two options so far:
>    - or we integrate all the shim6 processing in the BITW device
>
> =3D> this is my idea. This was never considered for MIPv6, IMHO =
because
> the MIPv6 target was very small devices and the proxy-MIPv4 stuff
> was already heavily patented.
>

so, in order to do this options, do we need to do any changes to the=20
protocol spec?

As i understand it, what is needed woudl be to mention that this is the=20=

expected way to implement the shim processing if BITW is used...=20
something else?

>    - or we include the ULID pair option in data packets (when BITW is=20=

> in
>    use), so that the BITW device can hace access to all the =
information
>    that is needed and do not need to perform all the shim6 processing
>    itself
>
>    My suggestion would be to:
>    - adopt the first option now
>    - make an extension to shim later so that this BITW optimized mode=20=

> is
>    supported
>
>    makes sense?
>
> =3D> I don't understand how we can have both options at the same time.
>

i am not sure what do you mean at the same time.... these would be=20
different ways to implement BITW compatibility that need to be=20
negotiated in the shim6 protocol (or either the processing is done=20
completelly in the BITW device or the ULID pair option is included in=20
the payload header, so that the BITW device can restore the ULIDs)

fwiw i am perfectly ok with doing only the first option... does anyone=20=

has a problem with adopting only the first option above? (at least for=20=

now)

Regards, marcelo

> Regards
>
> [email-masked]
>

Envelope-to: [email-masked]
Delivery-date: Wed, 02 Aug 2006 13:30:04 +0000
Message-Id: <[email-masked]>
From: Francis Dupont <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
cc: Shinta Sugimoto <[email-masked]>, shim6-wg <[email-masked]>
Subject: Re: visibility of identifier in shim6 payload packet (was: Re: IPsec !?...) 
Date: Wed, 02 Aug 2006 15:29:35 +0200

 In your previous mail you wrote:

   so, let me ask you another question with respect to BITW and MIPv6 RO 
   operation...
   
   suppose you have a node using MIPv6 in RO mode and it is using BITW 
   IPSec and it receives a packet with the HoA dest option
   
=> yes, a BITW IPsec has to know what is a HoA dest option. In fact
it already has to know for AH handling (another point where SHIM6
needs some specs but it is not an issue).

   Bottom line is that i think that a reasonable apporach would eb to try 
   to follow the same path that MIPv6 folks have done...
   
=> this is the easy solution...
   
   > => one way is to put the ULID in all packets. This solves this problem
   > and related firewall issues too (*). But it is clearly expensive.
   
   i think this may be one option for this particular BITW case
   i mean, the other option is that the BITW module can access to shim6 
   state, but from your words above, i conclude that this is not feasible
   
=> more important it is not desirable for the same reasons which make
BITW the right choice in some circumstances.
   
   > Two other points:
   >  - one possible solution is to integrated the whole SHIM6 into the BITW
   >    device (i.e., have an IPsec+SHIM6 BITW). As the issue comes from the
   >    relative positions of the IPsec and SHIM6 sublayer, this makes 
   > sense.
   
   yes this is another possibility indeed and as i understand this is 
   partialy what is done in MIPv6 with respect to HoA and Routing header 
   processing, right?
   
   i mean, as i understand this, part of the shim6 processing will be 
   performed by the BITW device. I guess we have two options so far:
   - or we integrate all the shim6 processing in the BITW device

=> this is my idea. This was never considered for MIPv6, IMHO because
the MIPv6 target was very small devices and the proxy-MIPv4 stuff
was already heavily patented.

   - or we include the ULID pair option in data packets (when BITW is in 
   use), so that the BITW device can hace access to all the information 
   that is needed and do not need to perform all the shim6 processing 
   itself
   
   My suggestion would be to:
   - adopt the first option now
   - make an extension to shim later so that this BITW optimized mode is 
   supported
   
   makes sense?
   
=> I don't understand how we can have both options at the same time.
   
Regards
   
[email-masked]

Delivery-date: Wed, 02 Aug 2006 13:00:14 +0000
Date: Wed, 02 Aug 2006 15:58:38 +0300
From: Shinta Sugimoto <[email-masked]>
To: Francis Dupont <[email-masked]>
Subject: Re: visibility of identifier in shim6 payload packet (was: Re: IPsec !?...) 
Cc: marcelo bagnulo braun <[email-masked]>, "Christian Huitema" <[email-masked]>, "shim6-wg" <[email-masked]>, "Iljitsch van Beijnum" <[email-masked]>

Hi Francis,

Please find my further comments inline.

On Wed, 02 Aug 2006 13:03:01 +0200
Francis Dupont <[email-masked]> wrote:

>  In your previous mail you wrote:
> 
>    I assume that you are pointing out the visibility of the identifier
>    in the data packet.  In case of SHIM6, if locator switch is performed
>    at the SHIM layer, the source and destination address field of the
>    IP header contain locators not the identifiers (in some case they
>    might be identical, though).  Now, what implications would this have
>    for existing IPsec system?  I assume your point is that BITW IPsec
>    device will not be able to extract the information from the IP packet
>    for protecting the traffic.  More specifically, BITW IPsec stack may
>    want to take the traffic selector information from the packet.
>    In this respect, there is a difference between MIP6 RO and SHIM6 in
>    its relation to the IPsec.  In case of MIP6, the identifier (=home address)
>    is contained in the extended field of the IP header (either in RH2
>    or DSTOPT).  Not in SHIM6 case.  Is this the problem that you are
>    pointing out?
>    
> => yes, this is the main issue.

Ok.

>    Now, let me state my view on this.  I think that the current
>    architectural model given in the SHIM6 base protocol document is
>    fairly reasonable, and I think we should not change it.
>    And I think the above issue is not relevant to security mechanism
>    of the SHIM6 protocol (that's why i changed the subject).
> 
> => yes, it is the other side of SHIM6/IPsec interactions.
> 
>    Moreover, I would see the above case (BITW) rather minor than
>    major.  However, I should admit that I am not familiar with the
>    real deployment of BITW IPsec and how common it is to extract
>    the information from the packet reached to the BITW device.
>    Could you provide me some input how common it is in the BITW
>    IPsec scenairo to dynamically extract the information from the
>    IP header of the packet?
> 
> => it is always the case: as the BITW is at the wire level it has
> only access to the bits on the wire.

Ok.

>    We may also think how much does it make much sense to run SHIM6 in
>    case where the BITW device is attached to the host.
> 
> => as IPsec and BITW is already part of the IP architecture, SHIM6
> has to accomodate with them.

Yes, I agree in general.  But I need more clarification on this
issue.  More comments below.

> 
>    BTW, according to RFC4301, BITW device itself
>    is IP addressable normally.
> 
> => yes, it has to be managed and perhaps to run IKE so it is better
> to give it its own address. BUT this doesn't mean it is a router
> (a security gateway in IPsec terminology).

Ok.

>    If this is the case, I tend to think
>    that support by SHIM6 does not make much sense in those scenario,
>    meaning that the concern is not serious.
> 
> => I strongly disagree: there is no requirement to make IPsec BITWs easy
> but there is a clear requirement to be compatible (i.e., not to make
> them impossible).

I am not saying that we should give up providing the compatibility.
I am saying that we should first take a look at the problem, and
see how serious the problem is.  I am not sure if the combination
of SHIM6 and BITW IPsec is totally infeasible or not, so I need
clarification.

I see similarity of BITW and SHIM6 in a sense that both of them
are intermediation of an IP processing.  And when designing such
intermediation, the primary concern is to keep it transparent to
its upper layer protocols.  In this respect, SHIM6 does not have
any issue as far as I see it, and (I hope) we all agree with that.

Now we are trying to see what kind of impact would SHIM6 (a new
intermediation) would have on another already-existing
intermediation which is BITW IPsec.

Based on assumption that BITW IPsec should be completely transparent
to the ULPs (including SHIM6 as its a conceptual sublayer within IP
layer), I don't see why SHIM6 over BITW IPsec would not work.  Well,
it would not be optimum operation, but that's same in the case of
normal IP host connected to multihomed site over BITW device isn't it?
(Please correct me if I am wrong)  To me, what you are pointing out
is that SHIM6 and BITW may work more efficiently, hence I see it
rather optimization than satisfying mandatory requirement.  And I
am of course not against considering the optimization.

> 
>    Anyway, if the concern is really serious,
> 
> => it is, I expect you don't want a last call objection from the military
> community and its vendors against the protocol document?

No.  My intention is to capture the issue.

>    then we may consider minor modification to
>    the SHIM6 payload extension header so that it can provide
>    identifier information for the BITW IPsec.  What do you think?
>    
> => one way is to put the ULID in all packets. This solves this problem
> and related firewall issues too (*). But it is clearly expensive.

Yes.

>    BTW, in case of MIP6, due to the visibility of the identifier
>    information, some people are feeling privacy concern and trying
>    to hide them from the packet on the wire (in MOBOPTS IPRG).
> 
> => yes, this is the IPsec VPN tentation but multi-homing is very different
> because the standard/initial mode hides nothing...

Ok. I see the difference.

>    So, I am feeling that there is no solution that fulfills everyone's
>    requirement.  We should focus on the main target, IMHO.
>    
> => the main target is to have a protocol which fits into the current
> architecture (note this is not yet the case) and solves the problem
> (still need to be proved).

I agree with your statement, in general.  But I would like to see if
the problem that we are talking about is a problem newly created by
the SHIM6 intermediation, or a general (existing) problem which may be
potentially solved by optimization.

> Two other points:
>  - one possible solution is to integrated the whole SHIM6 into the BITW
>    device (i.e., have an IPsec+SHIM6 BITW). As the issue comes from the
>    relative positions of the IPsec and SHIM6 sublayer, this makes sense.

This is an approach to combine two different intermediation into one.
I see no reason to prohibit this option.

>  - (*) in MIPv6 the home address is in all packets and fragments for the
>    benefit of firewalls (cf RFC 3775 6.3 page 53). IMHO SHIM6 has the same
>    concern so a packet or fragment should be easily attached to a
>    communication (here easily means without SHIM6 signaling spoofing,
>    state handling, etc, both because it is clearly not so easy and
>    because one can't assume an intermediate node can see all packets).

Ok, noted.

Regards,
Shinta

Delivery-date: Wed, 02 Aug 2006 11:37:02 +0000
Cc: Shinta Sugimoto <[email-masked]>, shim6-wg <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: visibility of identifier in shim6 payload packet (was: Re: IPsec !?...) 
Date: Wed, 2 Aug 2006 14:36:38 +0300
To: Francis Dupont <[email-masked]>

El 02/08/2006, a las 14:03, Francis Dupont escribi=F3:

>  In your previous mail you wrote:
>
>    I assume that you are pointing out the visibility of the identifier
>    in the data packet.  In case of SHIM6, if locator switch is=20
> performed
>    at the SHIM layer, the source and destination address field of the
>    IP header contain locators not the identifiers (in some case they
>    might be identical, though).  Now, what implications would this =
have
>    for existing IPsec system?  I assume your point is that BITW IPsec
>    device will not be able to extract the information from the IP=20
> packet
>    for protecting the traffic.  More specifically, BITW IPsec stack =
may
>    want to take the traffic selector information from the packet.
>    In this respect, there is a difference between MIP6 RO and SHIM6 in
>    its relation to the IPsec.  In case of MIP6, the identifier (=3Dhome=20=

> address)
>    is contained in the extended field of the IP header (either in RH2
>    or DSTOPT).  Not in SHIM6 case.  Is this the problem that you are
>    pointing out?
>
> =3D> yes, this is the main issue.

>    Moreover, I would see the above case (BITW) rather minor than
>    major.  However, I should admit that I am not familiar with the
>    real deployment of BITW IPsec and how common it is to extract
>    the information from the packet reached to the BITW device.
>    Could you provide me some input how common it is in the BITW
>    IPsec scenairo to dynamically extract the information from the
>    IP header of the packet?
>
> =3D> it is always the case: as the BITW is at the wire level it has
> only access to the bits on the wire.
>

so, let me ask you another question with respect to BITW and MIPv6 RO=20
operation...

suppose you have a node using MIPv6 in RO mode and it is using BITW=20
IPSec and it receives a packet with the HoA dest option

In order to properly perform the IPSec processing, the HoA must be=20
restored to the IPv6 source address field of the IPv6 header.
Since the IPSec processing occurs in the BITW mode, this HoA=20
restoration must occurs in a BITW mode also (i.e. by the IPSec hardware=20=

or something below IPSec). Having the HoA in the packet, allows for the=20=

BITW not to have to interact with upper parts of the stack to learn the=20=

associated HoA, but still part of the HoA dst option processing must=20
occurs in a BITW mode, right?

I think that a similar behaviour occurs for outgoing packets carrying=20
the Routing header, since the including the CoA as the destiantion=20
address in the IPv6 header must be performed after the IPSec processing

So, would it be correct to say that in order to support MIP- IPSec BITW=20=

compatibility, the BITW implementation must  be updated in order to=20
support part of the MIP processing (in particular, HoA dest option=20
processing and routing header insertion/processing?)

Bottom line is that i think that a reasonable apporach would eb to try=20=

to follow the same path that MIPv6 folks have done...

>

>    then we may consider minor modification to
>    the SHIM6 payload extension header so that it can provide
>    identifier information for the BITW IPsec.  What do you think?
>
> =3D> one way is to put the ULID in all packets. This solves this =
problem
> and related firewall issues too (*). But it is clearly expensive.
>

i think this may be one option for this particular BITW case
i mean, the other option is that the BITW module can access to shim6=20
state, but from your words above, i conclude that this is not feasible

>    BTW, in case of MIP6, due to the visibility of the identifier
>    information, some people are feeling privacy concern and trying
>    to hide them from the packet on the wire (in MOBOPTS IPRG).
>
> =3D> yes, this is the IPsec VPN tentation but multi-homing is very=20
> different
> because the standard/initial mode hides nothing...
>
>    So, I am feeling that there is no solution that fulfills everyone's
>    requirement.  We should focus on the main target, IMHO.
>
> =3D> the main target is to have a protocol which fits into the current
> architecture (note this is not yet the case) and solves the problem
> (still need to be proved).
>
> Two other points:
>  - one possible solution is to integrated the whole SHIM6 into the =
BITW
>    device (i.e., have an IPsec+SHIM6 BITW). As the issue comes from =
the
>    relative positions of the IPsec and SHIM6 sublayer, this makes=20
> sense.

yes this is another possibility indeed and as i understand this is=20
partialy what is done in MIPv6 with respect to HoA and Routing header=20
processing, right?

i mean, as i understand this, part of the shim6 processing will be=20
performed by the BITW device. I guess we have two options so far:
- or we integrate all the shim6 processing in the BITW device
- or we include the ULID pair option in data packets (when BITW is in=20
use), so that the BITW device can hace access to all the information=20
that is needed and do not need to perform all the shim6 processing=20
itself

My suggestion would be to:
- adopt the first option now
- make an extension to shim later so that this BITW optimized mode is=20
supported

makes sense?

regards, marcelo

>  - (*) in MIPv6 the home address is in all packets and fragments for=20=

> the
>    benefit of firewalls (cf RFC 3775 6.3 page 53). IMHO SHIM6 has the=20=

> same
>    concern so a packet or fragment should be easily attached to a
>    communication (here easily means without SHIM6 signaling spoofing,
>    state handling, etc, both because it is clearly not so easy and
>    because one can't assume an intermediate node can see all packets).
>
> Regards
>
> [email-masked]
>

Envelope-to: [email-masked]
Delivery-date: Wed, 02 Aug 2006 11:10:21 +0000
Message-Id: <[email-masked]>
From: Francis Dupont <[email-masked]>
To: "Henderson, Thomas R" <[email-masked]>
cc: "Shinta Sugimoto" <[email-masked]>, "shim6-wg" <[email-masked]>
Subject: Re: visibility of identifier in shim6 payload packet 
Date: Wed, 02 Aug 2006 13:10:04 +0200

 In your previous mail you wrote:

   My understanding of the potential problem is as follows:
   
   - there are multiple ways to implement IPsec:  BITW, BITS, and native
   
=> note these multiple ways are supposed to provide the same service.

   - BITS and BITW operate below the IP layer.  If these types of IPsec
   implementations talk to each other, there should be no problem if the
   SPD/SAD is defined on the basis of the locators.

=> the choice of the relative positions of IPsec and SHIM6 sublayers
was done and *must* not rely on implementation details (including
native or not native).

   For the native-to-non-native case, this seems to me to be related to the
   IKE NAT traversal problem (RFC3947).

=> BTW the word NAT is authorized in an IPv6 list only with strong
negative terms (:-).

To summary you are following the wrong way: RFC 4301 introduces some ways
to provide the same services, not different services.

Regards

[email-masked]

Envelope-to: [email-masked]
Delivery-date: Wed, 02 Aug 2006 11:04:37 +0000
Message-Id: <[email-masked]>
From: Francis Dupont <[email-masked]>
To: Shinta Sugimoto <[email-masked]>
cc: marcelo bagnulo braun <[email-masked]>, "Christian Huitema" <[email-masked]>, "shim6-wg" <[email-masked]>, "Iljitsch van Beijnum" <[email-masked]>
Subject: Re: visibility of identifier in shim6 payload packet (was: Re: IPsec !?...) 
Date: Wed, 02 Aug 2006 13:03:01 +0200

 In your previous mail you wrote:

   I assume that you are pointing out the visibility of the identifier
   in the data packet.  In case of SHIM6, if locator switch is performed
   at the SHIM layer, the source and destination address field of the
   IP header contain locators not the identifiers (in some case they
   might be identical, though).  Now, what implications would this have
   for existing IPsec system?  I assume your point is that BITW IPsec
   device will not be able to extract the information from the IP packet
   for protecting the traffic.  More specifically, BITW IPsec stack may
   want to take the traffic selector information from the packet.
   In this respect, there is a difference between MIP6 RO and SHIM6 in
   its relation to the IPsec.  In case of MIP6, the identifier (=home address)
   is contained in the extended field of the IP header (either in RH2
   or DSTOPT).  Not in SHIM6 case.  Is this the problem that you are
   pointing out?
   
=> yes, this is the main issue.

   Now, let me state my view on this.  I think that the current
   architectural model given in the SHIM6 base protocol document is
   fairly reasonable, and I think we should not change it.
   And I think the above issue is not relevant to security mechanism
   of the SHIM6 protocol (that's why i changed the subject).

=> yes, it is the other side of SHIM6/IPsec interactions.

   Moreover, I would see the above case (BITW) rather minor than
   major.  However, I should admit that I am not familiar with the
   real deployment of BITW IPsec and how common it is to extract
   the information from the packet reached to the BITW device.
   Could you provide me some input how common it is in the BITW
   IPsec scenairo to dynamically extract the information from the
   IP header of the packet?

=> it is always the case: as the BITW is at the wire level it has
only access to the bits on the wire.

   We may also think how much does it make much sense to run SHIM6 in
   case where the BITW device is attached to the host.

=> as IPsec and BITW is already part of the IP architecture, SHIM6
has to accomodate with them.

   BTW, according to RFC4301, BITW device itself
   is IP addressable normally.

=> yes, it has to be managed and perhaps to run IKE so it is better
to give it its own address. BUT this doesn't mean it is a router
(a security gateway in IPsec terminology).

   If this is the case, I tend to think
   that support by SHIM6 does not make much sense in those scenario,
   meaning that the concern is not serious.

=> I strongly disagree: there is no requirement to make IPsec BITWs easy
but there is a clear requirement to be compatible (i.e., not to make
them impossible).

   Anyway, if the concern is really serious,

=> it is, I expect you don't want a last call objection from the military
community and its vendors against the protocol document?

   then we may consider minor modification to
   the SHIM6 payload extension header so that it can provide
   identifier information for the BITW IPsec.  What do you think?
   
=> one way is to put the ULID in all packets. This solves this problem
and related firewall issues too (*). But it is clearly expensive.

   BTW, in case of MIP6, due to the visibility of the identifier
   information, some people are feeling privacy concern and trying
   to hide them from the packet on the wire (in MOBOPTS IPRG).

=> yes, this is the IPsec VPN tentation but multi-homing is very different
because the standard/initial mode hides nothing...

   So, I am feeling that there is no solution that fulfills everyone's
   requirement.  We should focus on the main target, IMHO.
   
=> the main target is to have a protocol which fits into the current
architecture (note this is not yet the case) and solves the problem
(still need to be proved).

Two other points:
 - one possible solution is to integrated the whole SHIM6 into the BITW
   device (i.e., have an IPsec+SHIM6 BITW). As the issue comes from the
   relative positions of the IPsec and SHIM6 sublayer, this makes sense.
 - (*) in MIPv6 the home address is in all packets and fragments for the
   benefit of firewalls (cf RFC 3775 6.3 page 53). IMHO SHIM6 has the same
   concern so a packet or fragment should be easily attached to a
   communication (here easily means without SHIM6 signaling spoofing,
   state handling, etc, both because it is clearly not so easy and
   because one can't assume an intermediate node can see all packets).

Regards

[email-masked]

Delivery-date: Tue, 01 Aug 2006 18:40:41 +0000
Content-class: urn:content-classes:message
Subject: RE: visibility of identifier in shim6 payload packet
Date: Tue, 1 Aug 2006 11:40:15 -0700
From: "Henderson, Thomas R" <[email-masked]>
To: "Shinta Sugimoto" <[email-masked]>, "Francis Dupont" <[email-masked]>
Cc: "shim6-wg" <[email-masked]>

=20

> -----Original Message-----
> From: Shinta Sugimoto [mailto:[email-masked]]=20
> Sent: Tuesday, August 01, 2006 10:42 AM
> To: Francis Dupont
> Cc: marcelo bagnulo braun; Christian Huitema; shim6-wg;=20
> Iljitsch van Beijnum
> Subject: visibility of identifier in shim6 payload packet=20
> (was: Re: IPsec !?...)
>=20
> Hi Francis,
>=20
> (excuse me for changing the subject, but I think it's more
> suitable for the topic being discussed)
>=20
> Please find my comments below.
>=20
> On Tue, 01 Aug 2006 13:29:07 +0200
> Francis Dupont <[email-masked]> wrote:
>=20
> >  In your previous mail you wrote:
> >=20
> >    > To make the use of IPsec impossible as a limited=20
> alternative is more
> >    > arguable. To make shim6 and IPsec compatible is a=20
> third topics, the
> >    > question was opened by Jim and is not yet closed.
> >   =20
> >    i don't see any problems with IPSec and shim=20
> compatibility.... do you=20
> >    see any issues/troubles there? could you expand on this?
> >   =20
> > =3D> you can read the thread initiated by Jim. To summary=20
> there is an issue
> > about what should be the traffic selectors and how to=20
> implement a BITW
> > (Bump-in-the-Wire, cf. RFC 4301). As it was already=20
> discussed in this
> > list please send questions directly to me (but solution(s)=20
> to the list :-).
>=20

My understanding of the potential problem is as follows:

- there are multiple ways to implement IPsec:  BITW, BITS, and native

- BITS and BITW operate below the IP layer.  If these types of IPsec
implementations talk to each other, there should be no problem if the
SPD/SAD is defined on the basis of the locators.  There is a problem of
ULID visibility if someone tried to define the SPD/SAD on the basis of
ULIDs

- there is also no problem if two native IPsec implementations talk to
each other using the ULIDs as the IPsec addresses, with both native
IPsec implementations above the shim6 layer

- there is a potential interoperability problem if a native (host)
implementation with SPD/SAD based on ULIDs tries to set up SAs with BITS
or BITW implementations, which don't have visibility into the ULIDs.  =20

Aside from the native-to-non-native case, I don't really see a problem.
In fact, it should be possible that end-to-end native IPsec is running
between hosts (this end-to-end is based on the ULID) while BITW is used
as an additional IPsec encapsulation between sites (this BITW-BITW is
based on locators).  It may be that mobike techniques can be applied to
allow a BITS host to be multihomed and talk to a BITW gateway.

For the native-to-non-native case, this seems to me to be related to the
IKE NAT traversal problem (RFC3947).  I don't know offhand whether the
IKE extensions defined there could also apply to shim6, or whether more
work is needed, or whether that particular use case is really important.

Tom

Delivery-date: Tue, 01 Aug 2006 18:18:55 +0000
Date: Tue, 01 Aug 2006 21:18:21 +0300
From: Shinta Sugimoto <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
Subject: Re: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006
Cc: "Bound, Jim" <[email-masked]>, <[email-masked]>, "Pekka Savola" <[email-masked]>, "Iljitsch van Beijnum" <[email-masked]>

Hi Marcelo,

Sorry for the late response, but by answering this email, I would
like to address my opinion on the security mechanism of the SHIM6
protocol.  please find my comments below.

On Wed, 19 Jul 2006 22:39:18 +0300
marcelo bagnulo braun <[email-masked]> wrote:

>=20
> El 19/07/2006, a las 22:28, Bound, Jim escribi=F3:
>=20
> > 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.
>=20
> exactly
>=20
> 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
>=20
> comments form the wg?

The choice of IPsec is not realistic, I think. Because, SHIM6 protocol
is expected to run among anonymous nodes.  That is, we cannot assume
any soft of pre-shared secret.  If the peers try to authenticate with
public key, then we must rely on global PKI.  I agree with your statement
that the assumption (wide deployment of PKI) is difficult.

So, I support the current security mechanisms (HBA, CGA, HBA/CGA) specified
in the SHIM6 base protocol which do not require any infrastructure.
I think its more scalable and easy to deploy.

Regards,
Shinta

(rest of the original email snipped)

Delivery-date: Tue, 01 Aug 2006 17:42:42 +0000
Date: Tue, 01 Aug 2006 20:41:44 +0300
From: Shinta Sugimoto <[email-masked]>
To: Francis Dupont <[email-masked]>
Subject: visibility of identifier in shim6 payload packet (was: Re: IPsec !?...)
Cc: marcelo bagnulo braun <[email-masked]>, "Christian Huitema" <[email-masked]>, "shim6-wg" <[email-masked]>, "Iljitsch van Beijnum" <[email-masked]>

Hi Francis,

(excuse me for changing the subject, but I think it's more
suitable for the topic being discussed)

Please find my comments below.

On Tue, 01 Aug 2006 13:29:07 +0200
Francis Dupont <[email-masked]> wrote:

>  In your previous mail you wrote:
> 
>    > 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.
>    
>    i don't see any problems with IPSec and shim compatibility.... do you 
>    see any issues/troubles there? could you expand on this?
>    
> => you can read the thread initiated by Jim. To summary there is an issue
> about what should be the traffic selectors and how to implement a BITW
> (Bump-in-the-Wire, cf. RFC 4301). As it was already discussed in this
> list please send questions directly to me (but solution(s) to the list :-).

I have read the email thread, but still I am not completely sure if
I understand your point.  So, let me clarify.

I assume that you are pointing out the visibility of the identifier
in the data packet.  In case of SHIM6, if locator switch is performed
at the SHIM layer, the source and destination address field of the
IP header contain locators not the identifiers (in some case they
might be identical, though).  Now, what implications would this have
for existing IPsec system?  I assume your point is that BITW IPsec
device will not be able to extract the information from the IP packet
for protecting the traffic.  More specifically, BITW IPsec stack may
want to take the traffic selector information from the packet.
In this respect, there is a difference between MIP6 RO and SHIM6 in
its relation to the IPsec.  In case of MIP6, the identifier (=home address)
is contained in the extended field of the IP header (either in RH2
or DSTOPT).  Not in SHIM6 case.  Is this the problem that you are
pointing out?

Now, let me state my view on this.  I think that the current
architectural model given in the SHIM6 base protocol document is
fairly reasonable, and I think we should not change it.
And I think the above issue is not relevant to security mechanism
of the SHIM6 protocol (that's why i changed the subject).
Moreover, I would see the above case (BITW) rather minor than
major.  However, I should admit that I am not familiar with the
real deployment of BITW IPsec and how common it is to extract
the information from the packet reached to the BITW device.
Could you provide me some input how common it is in the BITW
IPsec scenairo to dynamically extract the information from the
IP header of the packet?  We may also think how much does it
make much sense to run SHIM6 in case where the BITW device is
attached to the host.  BTW, according to RFC4301, BITW device itself
is IP addressable normally.  If this is the case, I tend to think
that support by SHIM6 does not make much sense in those scenairo,
meaning that the concern is not serious.  Anyway, if the concern
is really serious, then we may consider minor modification to
the SHIM6 payload extension header so that it can provide
identifier information for the BITW IPsec.  What do you think?

BTW, in case of MIP6, due to the visibility of the identifier
information, some people are feeling privacy concern and trying
to hide them from the packet on the wire (in MOBOPTS IPRG).
So, I am feeling that there is no solution that fulfills everyone's
requirement.  We should focus on the main target, IMHO.

Regards,
Shinta

Envelope-to: [email-masked]
Delivery-date: Tue, 01 Aug 2006 13:30:13 +0000
Message-Id: <[email-masked]>
From: Francis Dupont <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
cc: shim6-wg <[email-masked]>
Subject: Re: IPsec !?, was: Re: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006 
Date: Tue, 01 Aug 2006 15:29:28 +0200

 In your previous mail you wrote:

   > => but this is not true: in MIPv6 RO both addresses (locator/care-of
   > and ULID/home) are in all packets.
   
   so, how does this affects the IPSEc processing? I mean the shim6 
   processing (and the MIP processing) are both performed before the IPSEc 
   processing,

=> thw word before without the context (inbound/outbound) has no meaning...

   so the ULIDs are restored to the IPv6 header address 
   fields, so in both cases there is a address restoration before the 
   IPSec processing
   
=> read the RFC 4301 for the definition of a BITW.

   I mean, i would really like to address this issue and make the changes 
   required to the shim6 protocol spec in order to satisfy this concern, 
   but i simply fail to understand what the problem is...

=> of course, you don't know what is a BITW.

   having a 
   detailed statement of what the problem is and why this is different 
   that what occurs in other protocols like mip would be really useful to 
   move forward (or at least it would be really useful for me to 
   understand what the problem is)
   
   if others do understand the problem and could enlighten me, i would 
   appreciate it...
   
=> Jim's argument is based on architectural considerations but ends with
the same issue: you have the locators when you need the ULIDs.   
   
Regards

[email-masked]

PS: from RFC 4301 section 3.3:

   c. The use of a dedicated, inline security protocol processor is a
      common design feature of systems used by the military, and of some
      commercial systems as well.  It is sometimes referred to as a
      "bump-in-the-wire" (BITW) implementation.  Such implementations
      may be designed to serve either a host or a gateway.  Usually, the
      BITW device is itself IP addressable.  When supporting a single
      host, it may be quite analogous to a BITS implementation, but in
      supporting a router or firewall, it must operate like a security
      gateway.

I know some real cases of BITW, the first one in Steve Bellovin's laptop
at the IETF (a Linux PC-Card acting as both an Ethernet NIC and
an IPsec BITW, BTW the laptop itself ran NetBSD), another in a Cisco
router (simply because it was to hard/expensive/... to integrate it
directly into the box itself) and many other examples in military
contexts (where there are very good reasons to use BITW).

BTW shim6 is very stack-integration oriented, perhaps it should consider for
itself other kinds of implementations...

Delivery-date: Tue, 01 Aug 2006 12:47:12 +0000
Cc: shim6-wg <[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: Tue, 1 Aug 2006 15:46:08 +0300
To: Francis Dupont <[email-masked]>

El 01/08/2006, a las 15:00, Francis Dupont escribi=F3:

>  In your previous mail you wrote:
>
>    My comment to Jim is that MIPv6 when using RO mode have a very=20
> similar
>    behaviour than shim6 (i copy the message that i have sent to the ml
>    some weeks ago below)
>
> =3D> but this is not true: in MIPv6 RO both addresses (locator/care-of
> and ULID/home) are in all packets.
>

so, how does this affects the IPSEc processing? I mean the shim6=20
processing (and the MIP processing) are both performed before the IPSEc=20=

processing, so the ULIDs are restored to the IPv6 header address=20
fields, so in both cases there is a address restoration before the=20
IPSec processing

I mean, i would really like to address this issue and make the changes=20=

required to the shim6 protocol spec in order to satisfy this concern,=20
but i simply fail to understand what the problem is... having a=20
detailed statement of what the problem is and why this is different=20
that what occurs in other protocols like mip would be really useful to=20=

move forward (or at least it would be really useful for me to=20
understand what the problem is)

if others do understand the problem and could enlighten me, i would=20
appreciate it...

Thanks, marcelo

>    So my question to you is: do you see relevant differences between=20=

> the
>    shim6 case and the MIP RO case in terms of IPSec processing?
>
> =3D> yes!
>
> Regards
>
> [email-masked]
>

Envelope-to: [email-masked]
Delivery-date: Tue, 01 Aug 2006 12:01:19 +0000
Message-Id: <[email-masked]>
From: Francis Dupont <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
cc: shim6-wg <[email-masked]>
Subject: Re: IPsec !?, was: Re: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006 
Date: Tue, 01 Aug 2006 14:00:44 +0200

 In your previous mail you wrote:

   My comment to Jim is that MIPv6 when using RO mode have a very similar 
   behaviour than shim6 (i copy the message that i have sent to the ml 
   some weeks ago below)
   
=> but this is not true: in MIPv6 RO both addresses (locator/care-of
and ULID/home) are in all packets.

   So my question to you is: do you see relevant differences between the 
   shim6 case and the MIP RO case in terms of IPSec processing?
   
=> yes!

Regards   
   
[email-masked]

Delivery-date: Tue, 01 Aug 2006 11:38:55 +0000
Cc: shim6-wg <[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: Tue, 1 Aug 2006 14:38:18 +0300
To: Francis Dupont <[email-masked]>

El 01/08/2006, a las 14:29, Francis Dupont escribi=F3:

>  In your previous mail you wrote:
>
>> 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.
>
>    i don't see any problems with IPSec and shim compatibility.... do=20=

> you
>    see any issues/troubles there? could you expand on this?
>
> =3D> you can read the thread initiated by Jim. To summary there is an=20=

> issue
> about what should be the traffic selectors and how to implement a BITW
> (Bump-in-the-Wire, cf. RFC 4301). As it was already discussed in this
> list please send questions directly to me (but solution(s) to the list=20=

> :-).
>

i know this issue was discussed in this ml, because it is exactly this=20=

thread

My comment to Jim is that MIPv6 when using RO mode have a very similar=20=

behaviour than shim6 (i copy the message that i have sent to the ml=20
some weeks ago below)

So my question to you is: do you see relevant differences between the=20
shim6 case and the MIP RO case in terms of IPSec processing?

---- start old message -----

> -----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

--- end old message   -------

> Regards
>
> [email-masked]
>

Envelope-to: [email-masked]
Delivery-date: Tue, 01 Aug 2006 11:31:09 +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: Tue, 01 Aug 2006 13:29:07 +0200

 In your previous mail you wrote:

   > 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.
   
   i don't see any problems with IPSec and shim compatibility.... do you 
   see any issues/troubles there? could you expand on this?
   
=> you can read the thread initiated by Jim. To summary there is an issue
about what should be the traffic selectors and how to implement a BITW
(Bump-in-the-Wire, cf. RFC 4301). As it was already discussed in this
list please send questions directly to me (but solution(s) to the list :-).

Regards

[email-masked]

Delivery-date: Tue, 01 Aug 2006 06:15:48 +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: Tue, 1 Aug 2006 09:15:17 +0300
To: Iljitsch van Beijnum <[email-masked]>

El 31/07/2006, a las 13:11, Iljitsch van Beijnum escribi=F3:

> On 31-jul-2006, at 11:44, marcelo bagnulo braun wrote:
>
>>> 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=20
>> that it has some local means to verify which its own locators are...=20=

>> (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=20=

> by the claimed Ericsson patent, but checking the HBA/CGA isn't. Or the=20=

> other way around.

that would be really strange imho.... i don't think we should be=20
designing solutions based on possible applications of the IPR...

>  Then someone may want to implement only the part that isn't covered=20=

> by the patent. Obviously in this case that's unlikely and not very=20
> useful because we need something that both ends can handle, but in the=20=

> case of PKI-derived security this is a normal situation: if I don't=20
> have certificate for myself but I do have the root certificates I can=20=

> check someone else's certificate but I can't protect my own locators=20=

> with this security mechanism.

this otoh, seems a perfectly possible scenario, but basically what you=20=

are saying is that a peer can support different validation mechanisms=20
(in particular other than the one it uses for its own locator set...)

>  So when we exchange capabilities, for the security stuff we need to=20=

> have separate lists for what we support for outgoing locator sets and=20=

> what we support for incoming locator sets.

but i think we can do this with the current spec (or at least sort of)=20=

since when you receive the locator set from the peer, the validation=20
method may be different than the one the local host is using for its=20
locator set, but still the local host can accept them, so i am not sure=20=

if we need to change anything here...

>
>>>> (the reception of packet is done solely based on the context tag,=20=

>>>> 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.
>

you need some information to do the demux, and currently is the context=20=

tag. If we use other information, then you would look for this=20
alternative information.... i guess it is coherent with current=20
specs...

>>> 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
>
> Ok.
>
> But is it worth the trouble to support this? We could say that if you=20=

> want to add any locators outside your HBA set you must use CGA for the=20=

> whole set. This way all locators share the same security mechanism=20
> which should make life a bit simpler.  :-)
>

maybe

the difference would be that instead of having a validation mechanism=20
for each locator, you have it for the whole set.... but what if the=20
next update message is using a different validation method? do we accpt=20=

that? is that an error?

regards, marcelo

> On the other hand the trouble with CGA is that you need to send a=20
> challenge to make sure the other side really holds the secret key so=20=

> validating the HBA locators using HBA has the advantage that you can=20=

> use those while waiting for the response to your challenge to validate=20=

> the CGA-only locators.
>
> Iljitsch
>

Delivery-date: Tue, 01 Aug 2006 06:09:07 +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: Tue, 1 Aug 2006 09:07:37 +0300
To: Francis Dupont <[email-masked]>

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

>  In your previous mail you wrote:
>
>    so, saying that IPSec provides much more benefits than HBA/CGA but=20=

> that
>
> =3D> 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=20=

> say
>    that IPSec is not a viable alternative, which imho should be the
>    conclusion from this exchange, would you agree with that?
>
> =3D> I agree if you add the word "general" in front of "alternative".
>

agree

meaning for the general case (in particular for the case that there is=20=

no IPSec SA currently being used for the communication)

> 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.

i don't see any problems with IPSec and shim compatibility.... do you=20
see any issues/troubles there? could you expand on this?

thanks, marcelo

>
> Regards
>
> [email-masked]
>