Subject: [Hipsec-rg] Agenda slot request for the HIP RG
From: [email-masked] (Pekka Nikander)
Date: Sun Jan 23 07:19:00 2005

Dear secretary,

We would like to request an agenda slot for the HIP Research Group:

  a. Working Group or BOF full name with acronym in brackets:

     Host Identity Protocol Research Group (HIP RG)

  b. AREA under which Working Group or BOF appears:

     IRTF

  c. CONFLICTS you wish to avoid, please be as specific as possible:

     DNA, HIP, MULTI6, SHIM6 BOF, IPV6, V6OPS, MOPOPTS

  d. Expected Attendance

     60

  e. Special requests (i.e. multicast):

     We would like to have a Friday _AFTERNOON_ slot, from 12:30pm to 
3:30pm.
     This is similar to Washington other than that we would like to start
     already at 12:30pm, not 1pm.

     Only a room is needed; we will take care of the projector ourselves.

  f. Number of slots:

     One

  g. Length of slot:

     All Friday afternoon, three hours.

Thanks,

Pekka Nikander
HIP RG co-chair

From: [email-masked] (Pekka Nikander)
Date: Sun Jan 23 07:09:01 2005
Subject: [Hipsec-rg] HIP RG meeting on Friday afternoon at Minneapolis
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Folks,

On Jan 17, 2005, at 13:30, I wrote:
> I think the Friday afternoon RG meeting in Washington DC was pretty 
> successful.  People in the meeting favoured continuing on Friday 
> afternoon, but how about those that couldn't make it?  If you would 
> like to attend the RG meeting in Minneapolis but Friday afternoon will 
> be bad for you, please let me know.  I will summarise on the list.

So far I have received two messages, both indicating that Friday 
afternoon would be somewhat inconvenient but still feasible.  Based on 
this, I will send a request for a Friday afternoon slot.  I do realise 
that some people may leave to early as result of this, even during the 
session.  I think that is OK.  I will be attending to the end, this 
time, though.  On the other hand, I think that we can start a little 
bit earlier, already at 12:30, instead of 1pm.  That will leave 
somewhat less time for lunch, but given the possibilities in 
Minneapolis, having a lunch in one hour is quite easy.

--Pekka

From: [email-masked] (Pekka Nikander)
Date: Thu Jan 20 06:28:00 2005
Subject: [Hipsec-rg] Re: The function of ULIDs and routable IPv6 LSIs?
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Tom,

It is indeed good to have this discussion.  I think I have some
important insights down below, but before that some details
and clarifications.

>> ... I have came down
>> with the following tentative list of desirable ULID properties.
>>
>>    - stability
>>    - referability
>>    - reachability
>>    - security
>
> I would add that there is another angle about ULIDs, and that is
> whether they are for backward-compatible APIs or not. ...
>                       ... problems arise when you try to preserve
> all of the beneficial properties but don't want to change APIs
> or applications-- I don't think it can be done.

I agree with you that this different angle is an important one.
I tried to clarify it somewhat later in my original message,
not in the discussion about the desired ULID properties that I
considered more as an academic exercise.  :-)

In the IPv4 API case I agree with you that it seems to be impossible
to fulfil all the desired properties at the same time.  However,
I would not be that sure for the IPv6 API.  Furthermore, quite a
lot of applications have been upgraded to support the IPv6 API.

>> With stability I mean ...
>>
>> With referability I mean ...
>
> I am assuming that you also mean, by the above, that the other
> user may be non-HIP-aware at the system level.  In short, that
> the other user on a non-HIP-aware system can do a connect(ULID)
> and have it succeed.

Well, my intention was not explicitly considering that in the
framing part of my mail, but I agree that it is an important
consideration, with respect to stability and referability.
Indeed, it would be good if we could provide a system
where connect(IPv6-API-ULID) would work independent of whether
the system supports HIP or not.   On the other hand, that has
also a flip side: it reduces the overall security of the system,
as sometimes you get a secure connection when using such an
ULID and sometimes you don't, depending on which system you
use.

>> Reachability ...
>>
>> With security I mean ...
>
> If I read the above correctly, it seems to argue for some type
> of routable IP(v6) address, with elements of a host ID embedded
> in the IID portion, and that you have enough lower-order bits
> for host ID that give you the security properties that you want.
> At least for a near-term solution that satisfies referral property
> for legacy hosts.

Well, I did not have any explicit solution in my mind.  Using
CGA addresses as ULIDs is indeed one possibility, but are people
willing to accept the IPRs attached to them?  Anyway, independent
of that, it would be an interesting exercise to see how that would
work.

>> In addition to trying to get these properties clear in my mind,
>> I have also started to suspect that, in the longer run,  the
>> ULIDs that we want to at the application level may not be HITs,
>> in the meaning of *Host* Identity Tags.
>
> That view is also expressed in:
> http://www.acm.org/sigs/sigcomm/sigcomm2004/ 
> papers.html#A_Layered_Naming

Yes, the Layered Naming Architecture paper was one reason
why I have started to consider these issues.

>> AFAIK, so far people have used or are planning to use the
>> following forms of LSIs in their HIP implementations:
>>
>>    1. Initial locators, or plain old IP addresses.
>>    2. IPv4 LSIs from the 1.0.0.0/8 subnet.
>>    3. "Old fashioned" HITs, or 01/10 HITs.
>>    4. "New" IPv6 LSIs, with a TBD/TBD prefix.
>>
>> If we consider the above list of properties, all 32-bit
>> LSIs suffer from problems related to stability, referability
>> and security.  Using IPv4 addresses provides reachability on
>> the cost of security, while using 1.0.0.0/8 LSIs loses
>> direct reachability completely while providing some level of
>> security and referability.
>
> I would probably interchange the use of the terms "reachability"
> and "referability" in the above.  I think all of the proposals
> satisfy reachability as you defined it above this numbered list.

Well, one issue that I apparently missed was that I seem to
make a distinction between "direct reachability", meaning
that you can use an ULID as an IP address and get packets
passed by the routing infrastructure, and "indirect reachability",
where you rely on some additional infrastructure, such as DHT.
In the statement above I was thinking about "direct reachability",
but failed to mention that.  Sorry for the confusion.

Referrability, on the other hand, has two aspects in it.
One is certainly reachability (either direct or indirect).
But that does not necessarily need to be absolute, right
now available reachability.  You can refer to a host without
being able to reach it.  The other aspec is global scope.
While HITs are not reachable (in the sense of direct
reachability), they are certainly referrable, as they denote
the same host everywhere.

Finally, there seems to be yet another property, referrability
between HIP-capable hosts and non-HIP-capable hosts.  That I
failed to include in my original list.  To recap, we seem
to come down to a new list:

  - stability
  - referability between new hosts
  - referability between new and legacy hosts
  - direct reachability / direct (as opposed to overlay) routeability
  - indirect reachability
  - security

But, again, I am wondering if these terms are of any good, and
if any better terms might be available.

>> Given all this, I would summarise the situation and the
>> recent proposals as follows:
>>
>>    - Your use of using initial IP addresses as LSIs suffers,
>>      in my opinion, from big security problems.  Personally,
>>      I find this so problematic that I almost consider the
>>      practise to violate the HIP architecture, as expressed
>>      in draft-ietf-hip-arch-02.txt, now at the IESG.
>
> I disagree strongly.  Instead, I think it has the best chance
> of allowing a smooth transition to HIP, and even though it does
> not have the security properties of other ULIDs, it potentially
> strengthens the existing situation considerably without losing
> the referral property.  And when one considers that there hasn't
> yet been a proposal that satisfies all of the above listed
> requirements (and appears that maybe there is no such solution),
> it seems even more reasonable to me.

I guess here we have currently no other choice but to agree to
disagree.  I certainly appreciate your viewpoint, but still think
that it is not consistent with the HIP architecture, at least in
the sense that I understand the architecture.

What comes to the utility value of you approach as a transition
mechanism, I see your point.  You do gain referrability between
HIP and legacy hosts, which is quite a lot.  But you lose or at
least greatly weaken the  ability to trust on ULIDs, or use them
for channel binding.  Anyway, from the transition point of view,
your approach may be the best we can do with the IPv4 API.
However, I still suspect that we can do better with the IPv6 API.

[I don't want to go to the IPv6 API here.  However, I just want
to note that CGA suffers from channel binding problems, and
therefore may not be the ideal solution for that purpose.]

> Today, if the app does a connect(A) to a routable IP address A,
> all the system can really guarantee (if it works at all) is that
> it has connected to a host reachable at address A.  With HIP,
> we can offer the following.  If there is some means (manual
> configuration, trusted name resolution) for a system to find out
> the HIT of the host that it is trying to connect to, the system
> can perform the additional checking to authenticate the host
> responding from address A.  If the HIT information is not readily
> available, then at least there is keying material set up with
> whomever you happen to be talking to that will allow direct
> authentication of announced locator changes.  Even in this latter
> scenario, it is no less secure than the current situation.

I completely agree with you here.  My security point is that when
an application does connect(A), it has no direct assurance on
whether the connection will be secure or not.  It has to rely on
local configuration for that.  On the other hand, if a host does
connect(HIT), there is assurance that either the connection is
secure and to a node having access to the private key corresponding
to the HIT, or there are no connection at all.  connect(A) clearly
succeeds sometimes when connect(HIT) does not, and some of those
cases are not secure, either due to local configuration mistakes
or due to some other problems.

Personally, I find the assurance that connect(HIT) provides very
valuable, and as one of the main personal motivations for trying
to get HIP into a level that I can use it myself.

Now, a good question is whether we could support both at the
same time on all HIP hosts?  I don't see any direct reasons why
we couldn't, but perhaps I am missing something.  Maybe you could
configure your DNS system to prefer either form, but accept both
in referrals and from the user?  The behaviour in both cases
would then depend on what configuration you happen to have a the
time, i.e., whether you have an active A <-> HIT mapping or not.

I need to think about this more, but as an initial reaction
that sounds like a good possible approach for the IPv4 API case.
However, I still suspect that we should be able to do something
better in the IPv6 case....  But I may be wrong.

> I think it is also important to note that the various
> HIP developers have managed to develop interoperable
> implementations based on different LSI assumptions. In fact,
> we have done so ourselves-- in one application scenario we
> have been using non-routable LSIs in our own implementation
> and it interworks with the variant that uses IP addresses
> as LSIs.

Well, there seems to be two "level" of interoperability
here.  I certainly agree with you that we've managed to
create interoperable implementations from the HIP protocol
point of view.  However, if you try to use some application
that does application level referrals with IP addresses,
the two different implementations most probably fail to
interoperate.  OTOH, if we decide and manage to go into
the direction where we support BOTH plain (IPv4) addresses
and 1.0.0.0/8 LSIs at the API level on BOTH hosts, we might
get quite good interoperability also at the apps level,
and also towards legacy hosts.

It would then be the admin/user/app choice to use either
an address or an 1.0.0.0/8 LSI.  Using an address would
promote referability on the cost of security assurance
while using an 1.0.0.0/8 LSI would provide security
assurance on the cost of reachability and legacy-host
referrability.

> That is why I am objecting to the current
> language in the base spec-- this issue doesn't affect
> interoperability and there are clearly multiple ways to
> solve it (and disagreement on how best to solve it) so it
> would be best to allow room for further experimentation
> and discussion.

It does affect interoperability, at the application level,
and that point _has_ been discussed in the architecture
draft.  Maybe not directly, but it does mention that the
local name abstraction should be usable in "existing
_protocols_ and APIs."  (emphasis mine)  It also explicitly
mentions their use "as the address in an FTP command".

--Pekka

From: [email-masked] (Jan Mikael Melen)
Date: Thu Jan 20 01:50:00 2005
Subject: [Hipsec-rg] RES: [Hipsec] Yet Anoher Question about how to test the HIP implementation in FreeBSD-5.1
In-Reply-To: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAAWpjS/7WDk0utMy4/[email-masked]>
References: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAAWpjS/7WDk0utMy4/[email-masked]>
Message-ID: <[email-masked]>

Hi,

Do NOT post these questions to HipSec-rg list as most of them are not=20
interested how you use specific implementation.

There should be a default policy configuration in your ipsec.conf if you ha=
ve=20
run the mergemaster if not then you can copy the default policy file=20
from /usr/src/etc/ipsec.conf to /etc/ipsec.conf. Remember to put the=20
ipsec_enable=3D"YES" in to your rc.conf.

Try running the daemon on both ends with options -nt 65535 and send the out=
put=20
to me.

If you have questions about our implementations post them to=20
hip(at)hip4inter.net address as said on the webpage.

    Regards,
	Jan

On Thursday 20 January 2005 03:27, Marcio Augusto de Lima e Silva wrote:
> Hello folks....
>
> Sorry to post it again, but I'm kinda stuck here...
>
> Two main doubts:
>
> Is an IPSEC Policy like "spdadd <HIT_source> <HIT_dest> any -P out ipsec
> esp/hip//require;" on each host enough to trigger the HIP negotiation ? It
> seems so, but I would like to double check with you (the IPSEC SA's will =
be
> handled by the HIP right ?)...
>
> Is the editing of the hipconf.xml required ? The hipconf.xml on each host
> has the HIT 69dc:c983:bc39:c7eb:a25d:4b38:220e:23cd (which comes from the
> kernel patch file hip.patch) and does not change with the generation of t=
he
> new HI (by removing /etc/hip entries)
>
> Thanks again for the help... I'd really appreciate it if anyone had a
> config example I could see...
>
> Marcio
>
>
> -----Mensagem original-----
> De: [email-masked]
> [mailto:[email-masked]] Em nome de Marcio Augusto de Li=
ma
> e Silva
> Enviada em: ter=E7a-feira, 18 de janeiro de 2005 03:04
> Para: [email-masked]
> Cc: 'Jan Mikael Melen'
> Assunto: RES: [Hipsec] Yet Anoher Question about how to test the HIP
> implementation in FreeBSD-5.1
>
> Thanks for the previous answer
>
> Since I'm still facing a problem during the test, I would like to ask for
> further explanation of the configuration.
>
> Is a IPSEC Policy like "spdadd <HIT_source> <HIT_dest> any -P out ipsec
> esp/hip//require;" on each host enough to trigger the HIP negotiation ? It
> seems so, but I would like to double check (the IPSEC SA's will be handled
> by the HIP right ?).
>
> Is the editing of the hipconf.xml required ? The hipconf.xml on each host
> has the HIT 69dc:c983:bc39:c7eb:a25d:4b38:220e:23cd (which comes from the
> kernel patch file hip.patch) and does not change with the generation of t=
he
> new HI (by removing /etc/hip entries)
>
> The (reproducible) behavior that I'm seeing (in a HIP patched ethereal
> 0.10.7) is:
>
> - one or two I1 HIP
> - one or two R1 HIP
> - one or two I2 HIP
> - one or two R2 HIP
> - approx 8 seconds delay
> - unencrypted regular TCP/IP connection (with ssh or ftp), no ESP ipsec
> traffic.
>
> Running hipd -n -d4 shows some errors in the source side:
>
> Errno  : No such file or directory
> Errno  : Unknown error: 0
> Errno  : No such file or directory
> Errno  : Unknown error: 0
> N
> Trace:   [hipd_pfhip_write]: hipd_pfhip.c(194): ENTER
> Hex:     [hipd_pfhip_write]: HIP packet outgoing
> Hex:      03000000 5865ef5f 18d87f17 01000000
>           00000000 00000000 00000000 00000000
> Error:   [hipd_io_write]: [FAIL] Write to fd8, errno 2
> Error:   [hipd_pfhip_write]: Write to PFHIP failed
>
> Running hipd -n -t10 shows only warnings like:
>
> Warning: [hipd_states_default_handle_r1]: Received an unexpected R1 in
> state=3DI2 sent!!! (which should be caused by the double I1,I2,R1,R2 pack=
ets)
>
> Well.....that's all......any clarifications or even a example config would
> be greatly appreciated.
>
> Thanks again,
>
> Marcio
>
> -----Mensagem original-----
> De: [email-masked]
> [mailto:[email-masked]] Em nome de Jan Mikael Melen
> Enviada em: quarta-feira, 12 de janeiro de 2005 07:07
> Para: [email-masked]
> Cc: Marcio Augusto de Lima e Silva
> Assunto: Re: [Hipsec] Yet Anoher Question about how to test the HIP
> implementation in FreeBSD-5.1
>
> Hi Marcio
>
> On Tuesday 11 January 2005 18:19, Marcio Augusto de Lima e Silva wrote:
> > Hi all,
> >
> > I've read some old posts (January 2004) on the above subject and I'm
> > still have some questions. After I bind the HITs to a network
> > interface (on each of the two hosts), and place the HITs in /etc/hosts
> > in the form <HIT> <HOSTNAME>, how can I associate the IPv4 (or even
> > the IPv6) address to a HIT ?
>
> Your /etc/hosts should look like this:
> <HIT> <HOSTNAME>
> <IPv4> <HOSTNAME>
> <IPv6> <HOSTNAME>
>
> This way when the hostname is resolved the resolver gets the appropriate
> HIT and IP addresses.
>
> > Also, is the mutual copy o the public keys (from /etc/hip) from each
> > peer host required (it seems to be the case for the linux
> > implementation)
>
> ?
>
> Mutual copies of public keys are NOT required.
>
>    Regards,
> 	Jan
> _______________________________________________
> Hipsec mailing list
> [email-masked]
> http://honor.trusecure.com/mailman/listinfo/hipsec
>
>
> --
> No virus found in this incoming message.
> Checked by AVG Anti-Virus.
> Version: 7.0.300 / Virus Database: 265.6.10 - Release Date: 10/1/2005
>
>
>
>
> --
> No virus found in this outgoing message.
> Checked by AVG Anti-Virus.
> Version: 7.0.300 / Virus Database: 265.6.13 - Release Date: 16/1/2005
>
> _______________________________________________
> Hipsec mailing list
> [email-masked]
> http://honor.trusecure.com/mailman/listinfo/hipsec
>
>
> --
> No virus found in this incoming message.
> Checked by AVG Anti-Virus.
> Version: 7.0.300 / Virus Database: 265.6.13 - Release Date: 16/1/2005

=2D-=20
Jan M. Mel=E9n
Research Scientist,
NomadicLab, IP Networks,=20
Ericsson Research, Corporate Unit.=20
Tel. + 358 9 2993056=20
=46ax. + 358 9 2992448
Mobile + 358 400 836926

From: [email-masked] (Marcio Augusto de Lima e Silva)
Date: Wed Jan 19 20:28:01 2005
Subject: [Hipsec-rg] RES: [Hipsec] Yet Anoher Question about how to test the HIP implementation in FreeBSD-5.1
In-Reply-To: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAAWpjS/7WDk0utMy4/[email-masked]>
Message-ID: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAAWpjS/7WDk0utMy4/[email-masked]>

Hello folks....

Sorry to post it again, but I'm kinda stuck here...=20

Two main doubts:

Is an IPSEC Policy like "spdadd <HIT_source> <HIT_dest> any -P out ipsec
esp/hip//require;" on each host enough to trigger the HIP negotiation ? =
It
seems so, but I would like to double check with you (the IPSEC SA's will =
be
handled by the HIP right ?)...

Is the editing of the hipconf.xml required ? The hipconf.xml on each =
host
has the HIT 69dc:c983:bc39:c7eb:a25d:4b38:220e:23cd (which comes from =
the
kernel patch file hip.patch) and does not change with the generation of =
the
new HI (by removing /etc/hip entries)

Thanks again for the help... I'd really appreciate it if anyone had a =
config
example I could see...

Marcio
=20

-----Mensagem original-----
De: [email-masked]
[mailto:[email-masked]] Em nome de Marcio Augusto de =
Lima
e Silva
Enviada em: ter=E7a-feira, 18 de janeiro de 2005 03:04
Para: [email-masked]
Cc: 'Jan Mikael Melen'
Assunto: RES: [Hipsec] Yet Anoher Question about how to test the HIP
implementation in FreeBSD-5.1

Thanks for the previous answer

Since I'm still facing a problem during the test, I would like to ask =
for
further explanation of the configuration.

Is a IPSEC Policy like "spdadd <HIT_source> <HIT_dest> any -P out ipsec
esp/hip//require;" on each host enough to trigger the HIP negotiation ? =
It
seems so, but I would like to double check (the IPSEC SA's will be =
handled
by the HIP right ?).

Is the editing of the hipconf.xml required ? The hipconf.xml on each =
host
has the HIT 69dc:c983:bc39:c7eb:a25d:4b38:220e:23cd (which comes from =
the
kernel patch file hip.patch) and does not change with the generation of =
the
new HI (by removing /etc/hip entries)

The (reproducible) behavior that I'm seeing (in a HIP patched ethereal
0.10.7) is:

- one or two I1 HIP
- one or two R1 HIP
- one or two I2 HIP
- one or two R2 HIP
- approx 8 seconds delay
- unencrypted regular TCP/IP connection (with ssh or ftp), no ESP ipsec
traffic.

Running hipd -n -d4 shows some errors in the source side:

Errno  : No such file or directory
Errno  : Unknown error: 0
Errno  : No such file or directory
Errno  : Unknown error: 0
N
Trace:   [hipd_pfhip_write]: hipd_pfhip.c(194): ENTER
Hex:     [hipd_pfhip_write]: HIP packet outgoing
Hex:      03000000 5865ef5f 18d87f17 01000000
          00000000 00000000 00000000 00000000
Error:   [hipd_io_write]: [FAIL] Write to fd8, errno 2
Error:   [hipd_pfhip_write]: Write to PFHIP failed

Running hipd -n -t10 shows only warnings like:

Warning: [hipd_states_default_handle_r1]: Received an unexpected R1 in
state=3DI2 sent!!! (which should be caused by the double I1,I2,R1,R2 =
packets)

Well.....that's all......any clarifications or even a example config =
would
be greatly appreciated.

Thanks again,

Marcio =20

-----Mensagem original-----
De: [email-masked]
[mailto:[email-masked]] Em nome de Jan Mikael Melen
Enviada em: quarta-feira, 12 de janeiro de 2005 07:07
Para: [email-masked]
Cc: Marcio Augusto de Lima e Silva
Assunto: Re: [Hipsec] Yet Anoher Question about how to test the HIP
implementation in FreeBSD-5.1

Hi Marcio

On Tuesday 11 January 2005 18:19, Marcio Augusto de Lima e Silva wrote:
> Hi all,
>
> I've read some old posts (January 2004) on the above subject and I'm=20
> still have some questions. After I bind the HITs to a network=20
> interface (on each of the two hosts), and place the HITs in /etc/hosts =

> in the form <HIT> <HOSTNAME>, how can I associate the IPv4 (or even=20
> the IPv6) address to a HIT ?

Your /etc/hosts should look like this:
<HIT> <HOSTNAME>
<IPv4> <HOSTNAME>
<IPv6> <HOSTNAME>

This way when the hostname is resolved the resolver gets the appropriate =
HIT
and IP addresses.

> Also, is the mutual copy o the public keys (from /etc/hip) from each=20
> peer host required (it seems to be the case for the linux=20
> implementation)
?

Mutual copies of public keys are NOT required.

   Regards,
	Jan
_______________________________________________
Hipsec mailing list
[email-masked]
http://honor.trusecure.com/mailman/listinfo/hipsec

--
No virus found in this incoming message.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 265.6.10 - Release Date: 10/1/2005

--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 265.6.13 - Release Date: 16/1/2005

_______________________________________________
Hipsec mailing list
[email-masked]
http://honor.trusecure.com/mailman/listinfo/hipsec

--
No virus found in this incoming message.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 265.6.13 - Release Date: 16/1/2005

-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 265.7.0 - Release Date: 17/1/2005

From: [email-masked] (Henderson, Thomas R)
Date: Tue Jan 18 12:11:01 2005
Subject: [Hipsec-rg] RE: The function of ULIDs and routable IPv6 LSIs?
Message-ID: <[email-masked]>

Pekka,
Rather than opening a can of worms, I think it is very
helpful to have this discussion, because it seems we have
some different fundamental assumptions.

> -----Original Message-----
> From: Pekka Nikander [mailto:[email-masked]]=20
> Sent: Tuesday, January 18, 2005 3:51 AM
> To: Henderson, Thomas R
> Cc: [email-masked]
> Subject: The function of ULIDs and routable IPv6 LSIs?
>=20
>=20
> Tom,
>=20
> The more I think about this, the more I get a feeling that
> we are opening a can of worms.  But maybe we need to do that now.
> The real question does not seem to be so much about LSIs,
> at least in the sense that you seem to understand them, but
> more generally about ULIDs and their semantics.
>=20
> Based on discussions with a number of people, I have came down
> with the following tentative list of desirable ULID properties.
> (I have still trouble in giving proper names to the these
> properties; suggestions for better names are appreciated.)
>=20
>    - stability
>    - referability
>    - reachability
>    - security

I would add that there is another angle about ULIDs, and that is
whether they are for backward-compatible APIs or not.  That is,
whether there are additional constraints on the solution (such
as being 32 or 128 bits long).  IMO, if you have a richer API
and cognizant apps, these issues become more explicit and=20
straightforward-- more problems arise when you try to preserve
all of the beneficial properties but don't want to change APIs
or applications-- I don't think it can be done.

>=20
> With stability I mean that an ULID should be usable for a long
> time, preferably years or even longer.  Given the current status
> of technology, most probably we can't expect ULIDs to be usable
> for longer than a few decades, but even a decade or two would be
> pretty good.
>=20
> With referability I mean that it should be possible to given an
> ULID to some other party, and it be usable by that party.  In
> other words, there should be a global (implicit) context where
> anyone can use ULIDs, independent on the user's location, type of
> connectivity, identity, or other properties.

I am assuming that you also mean, by the above, that the other
user may be non-HIP-aware at the system level.  In short, that
the other user on a non-HIP-aware system can do a connect(ULID)
and have it succeed.

>=20
> Reachability (or whatever would be a better name) is most
> probably the most important property.  That is, given an ULID,
> there must be sufficient mechanisms in place so that one can
> send messages to the identified party, and receive back answers.
> In a more concrete level, it should be possible to make a
>    connect(ULID)
> system call, in order to provide backward compatibility for
> (most) current applications.
>=20
> With security I mean that there are reasonable bases to believe
> that using the ULID does reach the identified party.  That is,
> there is a reasonable amount of assurance that the ULID and
> the underlying mechanisms make sure that any message are
> received, as sent, by the denoted party, or that the connection
> is opened by the denoted party and not with some other party.
> They may also be additional security properties, such as
> confidentiality, but they go beyond the point.

If I read the above correctly, it seems to argue for some type
of routable IP(v6) address, with elements of a host ID embedded
in the IID portion, and that you have enough lower-order bits
for host ID that give you the security properties that you want.
At least for a near-term solution that satisfies referral property
for legacy hosts.

If not, can you provide a counter-example?

>=20
> In addition to trying to get these properties clear in my mind,
> I have also started to suspect that, in the longer run,  the
> ULIDs that we want to at the application level may not be HITs,
> in the meaning of *Host* Identity Tags.
>=20
> Let me clarify the last statement a little bit.  While it is a
> common practise in the Internet to identify services by denoting
> the host that hosts the service and a port number, that practise
> does not seem to be that reasonable any more.  It would be much
> better to denote services by unique identifiers.  The underlying
> mechanism would then convert this service identifier (SID) into
> whatever is needed to contact the service, i.e., most probably
> through a series of intermediate identifiers down to a locator
> (and other info, denoting the protocol(s) and port.)
>=20
That view is also expressed in:
http://www.acm.org/sigs/sigcomm/sigcomm2004/papers.html#A_Layered_Naming

> Thus, the practise of using LSIs or HITs as ULIDs seems to
> be a temporary one, to be replaced with something more advanced
> as soon as we get some more infrastructure defined.
>=20
> Now, given all of the above as a framework for thought, we
> can start to consider various forms of LSIs and their
> properties.  In my opinion, the real question here is about
> the kind of ULID properties we want to provide with LSIs,
> given that their use is likely to be relatively temporary
> (i.e. years) and solely in the context of backwards
> compatibility.
>=20
> AFAIK, so far people have used or are planning to use the
> following forms of LSIs in their HIP implementations:
>=20
>    1. Initial locators, or plain old IP addresses.
>=20
>    2. IPv4 LSIs from the 1.0.0.0/8 subnet.
>=20
>    3. "Old fashioned" HITs, or 01/10 HITs.
>=20
>    4. "New" IPv6 LSIs, with a TBD/TBD prefix.
>=20
> If we consider the above list of properties, all 32-bit
> LSIs suffer from problems related to stability, referability
> and security.  Using IPv4 addresses provides reachability on
> the cost of security, while using 1.0.0.0/8 LSIs loses
> direct reachability completely while providing some level of
> security and referability. =20

I would probably interchange the use of the terms "reachability"
and "referability" in the above.  I think all of the proposals
satisfy reachability as you defined it above this numbered list.

> It looks like that it is impossible
> to reach any ideal situation in this scope, and therefore it
> may be wise to experiment with different designs.  My suggestion
> of using a routable A-class for LSIs would have provided some
> level of reachability without compromising the little security
> that 1.0.0.0/8 LSIs currently have.
>=20
> Using IPv6 addresses (as in case 1. above) seems to provide
> some stability (subject to change due to SEND, RFC3041, etc),
> good referability and reachability, but almost no security.
>=20
> The "old fashioned" 01/10 128-bit HITs seem to provide for
> pretty good stability, referrability, and security, with no
> direct reachability.
>=20
> The "new" TBD/TBD 128-bit LSIs seem to provide for fairly
> good stability, referability, and reachability, no direct
> reachability, and further problems in indirect reachability.
> That is, if we provide indirect reachability for 128-bit LSIs
> with something like Hi3, it looks like that all hosts need
> to register two triggers: both their HIT and their 128-bit
> LSI.
>=20
> Given all this, I would summarise the situation and the
> recent proposals as follows:
>=20
>    - Your use of using initial IP addresses as LSIs suffers,
>      in my opinion, from big security problems.  Personally,
>      I find this so problematic that I almost consider the
>      practise to violate the HIP architecture, as expressed
>      in draft-ietf-hip-arch-02.txt, now at the IESG.

I disagree strongly.  Instead, I think it has the best chance
of allowing a smooth transition to HIP, and even though it does
not have the security properties of other ULIDs, it potentially
strengthens the existing situation considerably without losing
the referral property.  And when one considers that there hasn't
yet been a proposal that satisfies all of the above listed
requirements (and appears that maybe there is no such solution),
it seems even more reasonable to me.

Today, if the app does a connect(A) to a routable IP address A,
all the system can really guarantee (if it works at all) is that
it has connected to a host reachable at address A.  With HIP,
we can offer the following.  If there is some means (manual
configuration, trusted name resolution) for a system to find out
the HIT of the host that it is trying to connect to, the system
can perform the additional checking to authenticate the host
responding from address A.  If the HIT information is not readily
available, then at least there is keying material set up with
whomever you happen to be talking to that will allow direct
authentication of announced locator changes.  Even in this latter
scenario, it is no less secure than the current situation.

Now if the address A leaves the system (in a referral) and ends
up on a non-HIP host, then things will default back to the way
they are presently.  The address A in this case doesn't have
any more semantics than it does in a non-HIP world.  Why is
this so problematic to fall back to the present way of doing
things?

But let's assume that I have upgraded my system and can guarantee
that all of my apps that I care about do not perform application-level
referrals.  Then, I can move to non-routable LSIs as handles and
obtain some additional granularity at the API level (that is, the
system can distinguish between the different semantics of ping(A) and=20
ping(LSI(A))).=20

>=20
>      Personally, I prefer LSIs that
>      - are clearly distinguishable from IP addresses
>      - are unambiguously mappable to HIs, i.e. contain
>        a long enough partial hash of the HI
>=20
>    - My separate, WG side proposal of temporarily limiting
>      HITs to the 01/10 prefixes seem to provide some
>      remedy to the indirect reachability problem to those
>      implementations that would accept them as LSIs.
>=20
>    - My proposal of making the TBD/TBD IPv6 LSIs routable
>      seems ideal to me.  That would provide us with LSIs
>      that seem to provide a reasonable level of stability,
>      referability, reachability and security.  It would also
>      provide something for legacy applications.
>=20
>      But, certainly, this proposal of simply making the
>      TBD/TBD prefix routable is a sane one is debatable.
>      It might be better to provide some other means to
>      reach the proposed DHT based resolution/overlay
>      infrastructure.
>=20
> But there are also other details that we might want to
> tinker, like the checksums, as Julien proposed.  In my
> opinion, we should spend quite a lot of time in trying to
> understand this situation better.
>=20

I think it is also important to note that the various
HIP developers have managed to develop interoperable
implementations based on different LSI assumptions. In fact,
we have done so ourselves-- in one application scenario we
have been using non-routable LSIs in our own implementation
and it interworks with the variant that uses IP addresses
as LSIs.  That is why I am objecting to the current
language in the base spec-- this issue doesn't affect=20
interoperability and there are clearly multiple ways to
solve it (and disagreement on how best to solve it) so it
would be best to allow room for further experimentation
and discussion.

Tom

From: [email-masked] (Pekka Nikander)
Date: Tue Jan 18 06:51:00 2005
Subject: [Hipsec-rg] The function of ULIDs and routable IPv6 LSIs?
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Tom,

The more I think about this, the more I get a feeling that
we are opening a can of worms.  But maybe we need to do that now.
The real question does not seem to be so much about LSIs,
at least in the sense that you seem to understand them, but
more generally about ULIDs and their semantics.

Based on discussions with a number of people, I have came down
with the following tentative list of desirable ULID properties.
(I have still trouble in giving proper names to the these
properties; suggestions for better names are appreciated.)

   - stability
   - referability
   - reachability
   - security

With stability I mean that an ULID should be usable for a long
time, preferably years or even longer.  Given the current status
of technology, most probably we can't expect ULIDs to be usable
for longer than a few decades, but even a decade or two would be
pretty good.

With referability I mean that it should be possible to given an
ULID to some other party, and it be usable by that party.  In
other words, there should be a global (implicit) context where
anyone can use ULIDs, independent on the user's location, type of
connectivity, identity, or other properties.

Reachability (or whatever would be a better name) is most
probably the most important property.  That is, given an ULID,
there must be sufficient mechanisms in place so that one can
send messages to the identified party, and receive back answers.
In a more concrete level, it should be possible to make a
   connect(ULID)
system call, in order to provide backward compatibility for
(most) current applications.

With security I mean that there are reasonable bases to believe
that using the ULID does reach the identified party.  That is,
there is a reasonable amount of assurance that the ULID and
the underlying mechanisms make sure that any message are
received, as sent, by the denoted party, or that the connection
is opened by the denoted party and not with some other party.
They may also be additional security properties, such as
confidentiality, but they go beyond the point.

In addition to trying to get these properties clear in my mind,
I have also started to suspect that, in the longer run,  the
ULIDs that we want to at the application level may not be HITs,
in the meaning of *Host* Identity Tags.

Let me clarify the last statement a little bit.  While it is a
common practise in the Internet to identify services by denoting
the host that hosts the service and a port number, that practise
does not seem to be that reasonable any more.  It would be much
better to denote services by unique identifiers.  The underlying
mechanism would then convert this service identifier (SID) into
whatever is needed to contact the service, i.e., most probably
through a series of intermediate identifiers down to a locator
(and other info, denoting the protocol(s) and port.)

Thus, the practise of using LSIs or HITs as ULIDs seems to
be a temporary one, to be replaced with something more advanced
as soon as we get some more infrastructure defined.

Now, given all of the above as a framework for thought, we
can start to consider various forms of LSIs and their
properties.  In my opinion, the real question here is about
the kind of ULID properties we want to provide with LSIs,
given that their use is likely to be relatively temporary
(i.e. years) and solely in the context of backwards
compatibility.

AFAIK, so far people have used or are planning to use the
following forms of LSIs in their HIP implementations:

   1. Initial locators, or plain old IP addresses.

   2. IPv4 LSIs from the 1.0.0.0/8 subnet.

   3. "Old fashioned" HITs, or 01/10 HITs.

   4. "New" IPv6 LSIs, with a TBD/TBD prefix.

If we consider the above list of properties, all 32-bit
LSIs suffer from problems related to stability, referability
and security.  Using IPv4 addresses provides reachability on
the cost of security, while using 1.0.0.0/8 LSIs loses
direct reachability completely while providing some level of
security and referability.  It looks like that it is impossible
to reach any ideal situation in this scope, and therefore it
may be wise to experiment with different designs.  My suggestion
of using a routable A-class for LSIs would have provided some
level of reachability without compromising the little security
that 1.0.0.0/8 LSIs currently have.

Using IPv6 addresses (as in case 1. above) seems to provide
some stability (subject to change due to SEND, RFC3041, etc),
good referability and reachability, but almost no security.

The "old fashioned" 01/10 128-bit HITs seem to provide for
pretty good stability, referrability, and security, with no
direct reachability.

The "new" TBD/TBD 128-bit LSIs seem to provide for fairly
good stability, referability, and reachability, no direct
reachability, and further problems in indirect reachability.
That is, if we provide indirect reachability for 128-bit LSIs
with something like Hi3, it looks like that all hosts need
to register two triggers: both their HIT and their 128-bit
LSI.

Given all this, I would summarise the situation and the
recent proposals as follows:

   - Your use of using initial IP addresses as LSIs suffers,
     in my opinion, from big security problems.  Personally,
     I find this so problematic that I almost consider the
     practise to violate the HIP architecture, as expressed
     in draft-ietf-hip-arch-02.txt, now at the IESG.

     Personally, I prefer LSIs that
     - are clearly distinguishable from IP addresses
     - are unambiguously mappable to HIs, i.e. contain
       a long enough partial hash of the HI

   - My separate, WG side proposal of temporarily limiting
     HITs to the 01/10 prefixes seem to provide some
     remedy to the indirect reachability problem to those
     implementations that would accept them as LSIs.

   - My proposal of making the TBD/TBD IPv6 LSIs routable
     seems ideal to me.  That would provide us with LSIs
     that seem to provide a reasonable level of stability,
     referability, reachability and security.  It would also
     provide something for legacy applications.

     But, certainly, this proposal of simply making the
     TBD/TBD prefix routable is a sane one is debatable.
     It might be better to provide some other means to
     reach the proposed DHT based resolution/overlay
     infrastructure.

But there are also other details that we might want to
tinker, like the checksums, as Julien proposed.  In my
opinion, we should spend quite a lot of time in trying to
understand this situation better.

--Pekka

From: [email-masked] (Henderson, Thomas R)
Date: Mon Jan 17 13:50:00 2005
Subject: [Hipsec-rg] Routable IPv6 LSIs?
Message-ID: <[email-masked]>

> My worry is, mainly, what can the other host do with them,
> especially in the beginning.
>=20
> > in which case, it might make sense to make
> > them non-routable.
>=20
> That is certainly one approach.  However, a more user friendly
> approach would to route them to somewhere that could either
> handle them somehow (act as a proxy) or to provide the user
> with some message that instructs them to upgrade their OS.

I thought that is what you might have been driving at in your
original post.  However, I am not sure how that would work,
unless the LSI had "non-local" scope-- i.e., if there was=20
some middlebox that could resolve the LSI to an actual host
somehow.    =20

The problem with LSIs is that, if one provides non-routable
LSIs to the application, they work fine locally, but cannot
be passed around in referrals.  If LSIs are routable, then
they work better in referrals, but the operating system may
have trouble distinguishing them from IP addresses in some
cases (i.e., deciding when to invoke HIP or not). =20

We have favored the approach (in our implementation) of using
the initial locators as the LSIs, and keeping track of the
binding to host context within the kernel.  That means that
we have to set up our HIPsec policy tables in terms of IP addresses.
This seems to work fine except for some corner cases in mobility
that are ambiguous or break anyway in the current Internet architecture.
That way, we should naturally be able to handle referrals in all
legacy applications.  The only possible downside that I perceive
is a lack of granularity available to applications that want
to connect to address A while only using HIP for some of those
flows.  For example, if an application does a connect() to address A,
and address A matches in the SPDB and HIP is invoked =
(opportunistically),
then all subsequent packets (either new connects() or sendto()) to A =
will
be put into the resulting SA.  To me, this seems like the preferred
behavior anyway.

The addresses in the HIP SPDB can be augmented with HITs, either =
configured
manually or obtained via the resolution process.  For example, if one
were to put the tuple <A, A's HIT> into the database, then when the =
policy
matched on the basis of matching address A, A's HIT could be used =
instead
of running the handshake in opportunistic mode.  There are a couple of =
ways
that A's HIT could be potentially fetched (reverse/forward DNS query, =
some
to-be-defined HIT resolution service) even if it were not known a =
priori.

Tom

From: [email-masked] (Pekka Nikander)
Date: Mon Jan 17 07:35:03 2005
Subject: [Hipsec-rg] HIP RG meeting on Friday afternoon at Minneapolis
Message-ID: <[email-masked]>

Folks,

I think the Friday afternoon RG meeting in Washington DC was pretty 
successful.  People in the meeting favoured continuing on Friday 
afternoon, but how about those that couldn't make it?  If you would 
like to attend the RG meeting in Minneapolis but Friday afternoon will 
be bad for you, please let me know.  I will summarise on the list.

Unless there are many people to whom Friday afternoon is bad, I'll go 
ahead and request a meeting slot on Friday, March 11, at 12:30pm to 
4pm.

--Pekka

From: [email-masked] (Pekka Nikander)
Date: Mon Jan 17 05:50:01 2005
Subject: [Hipsec-rg] Routable IPv6 LSIs?
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

>> I am reviewing the new base spec (02-pre1) for the WG, and I
>> started to wonder whether we should aim for routable IPv6
>> (and maybe also IPv4) LSIs.  That is, now that we have also
>> made the distinction between HITs (with don't have a
>> prefix) and LSIs (which do have a prefix) in the IPv6 side,
>> and we have something like Hi3 emerging, maybe we could make
>> LSIs routable?
>
> I did not follow this argument.  Perhaps because I seem to have a
> different perception of the scope of LSIs than others do-- that they
> are truly local, they never leave the box, and hence don't
> even need to be written up other than informational RFCs.

Well, in an ideal world I would certainly agree with you.
That is, if all applications used a new API that takes HITs
as end-point identifiers, then I wouldn't be that concerned
about LSIs.

However, I think that there are two assets in the Internet
that will move very slowly.  One is the applications, i.e.,
the complete set of all application implementations that
people are using.  The other one is routers.  The rest, i.e.,
the set of protocols implemented in the kernels, the boxes
needed for infrastructure support, etc, move faster, but of
course relatively slowly even them.

Hence, I think that we will see legacy applications that will
use the current IPv4 and IPv6 APIs for a long time to come.
Some of these applications will be also exposing what they
think are IP addresses, i.e., LSIs, also to other apps and
other parties.

What I am mostly concerned with is how do we handle these.

> The only time that they leave the box would be if they
> were accidentally embedded in some legacy application
> data stream,

Well, I wouldn't necessarily call this "accidental."

My worry is, mainly, what can the other host do with them,
especially in the beginning.

> in which case, it might make sense to make
> them non-routable.

That is certainly one approach.  However, a more user friendly
approach would to route them to somewhere that could either
handle them somehow (act as a proxy) or to provide the user
with some message that instructs them to upgrade their OS.

> In Hi3, why can't this be done (anycasting to a Hi3 server)
> regardless of LSIs?

Sure it can there.  Perhaps my reference to Hi3 was misleading.

--Pekka

From: [email-masked] (Henderson, Thomas R)
Date: Sun Jan 16 22:36:01 2005
Subject: [Hipsec-rg] Routable IPv6 LSIs?
Message-ID: <[email-masked]>

> -----Original Message-----
> From: Pekka Nikander [mailto:[email-masked]]=20
> Sent: Tuesday, January 11, 2005 1:58 AM
> To: [email-masked]
> Subject: [Hipsec-rg] Routable IPv6 LSIs?
>=20
>=20
> Folks,
>=20
> I am reviewing the new base spec (02-pre1) for the WG, and I=20
> started to=20
> wonder whether we should aim for routable IPv6 (and maybe also IPv4)=20
> LSIs.  That is, now that we have also made the distinction=20
> between HITs=20
> (with don't have a prefix) and LSIs (which do have a prefix) in the=20
> IPv6 side, and we have something like Hi3 emerging, maybe we=20
> could make=20
> LSIs routable?
>=20
<snip>=20
> Thoughts?  Pitfalls?
>=20

I did not follow this argument.  Perhaps because I seem to have a
different perception of the scope of LSIs than others do-- that they
are truly local, they never leave the box, and hence don't
even need to be written up other than informational RFCs.  The only
time that they leave the box would be if they were accidentally
embedded in some legacy application data stream, in which case, it
might make sense to make them non-routable.

In Hi3, why can't this be done (anycasting to a Hi3 server)
regardless of LSIs? =20

Tom

From: [email-masked] (Julien Laganier)
Date: Wed Jan 12 05:27:03 2005
Subject: [Hipsec-rg] Routable IPv6 LSIs?
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Tuesday 11 January 2005 16:00, Pekka Nikander wrote:

<snip>

> > So my question is: What is the benefit of having multiple
> > anycast addresses compared to a fixed anycast address allocated
> > for Hi3 discovery/relay purpose (like 6to4) ? But perhaps I
> > completely missed your point :)
>
> Well, the point is that we don't actually need anycast to support
> the scheme.  We can use just normal routing, at least initially.
> Secondly, we don't need to allocate or define the anycast address.
> We just use an LSI prefix that someone running the DHT "happens" to
> have allocated for themselves.

I understand. 

FYI, an IPv4 route to the anycast prefix 192.88.99.0/24 is advertised, 
and route to an available 6to4 relay router, while the anycast 
address of the nearest 6to4 relay router is 192.88.99.1.

--julien

From: [email-masked] (Pekka Nikander)
Date: Tue Jan 11 10:01:02 2005
Subject: [Hipsec-rg] Routable IPv6 LSIs?
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

>> To make LSIs routable, we would make the whole LSI prefix (either
>> IPv6 or IPv4) to act as a kind of anycast prefix.  That is, when
>
> This seems related to the Anycast 6to4 technique. One thing I don't
> get is that "the whole LSI prefix act as a _kind_ of anycast prefix".
> Why "a kind of" ? Doesn't Anycast work straightforward for this
> purpose?

Well, I am not too familiar with anycast, but my understanding is that
anycast works usually at the level of addresses, not prefixes.  Hence,
while this certainly fits in to some definition of anycast, this may
not be identical with the current definition of anycast.  But I can't
say, I don't know the specs well enough.

>> the knowledge of where the closest Hi3 node is
>> reachable could be moved from the host to the network.
>
> I'd rather say "(...) could be moved from the end host to the routing
> fabric". This seems to be more precise.

Right.  I agree.

> I had myself the idea to route I1 to a gateway part of DHT, which
> would take care of the final delivery (i.e. locating the HIT owner),
> while the gateway would be discovered by the initiator using an
> allocated anycast address.

That's more or less what I was thinking about earlier, too.

> Above you wrote: "the sending host does not need to know anything else
> but the LSI (or HIT, if the prefix is fixed)". If I understand
> correctly, you envision two situations:
>
> o A HIT-based routing with a fixed anycast address to discover a
> gateway to the Hi3.
>
> o A LSI-based routing with multiple anycast addresses to discover the
> "nearest" gateway to the Hi3.

Well, not only multiple anycast addresses but the whole LSI prefix
being anycasted.

> So my question is: What is the benefit of having  multiple anycast
> addresses compared to a fixed anycast address allocated for Hi3
> discovery/relay purpose (like 6to4) ? But perhaps I completely missed
> your point :)

Well, the point is that we don't actually need anycast to support
the scheme.  We can use just normal routing, at least initially.
Secondly, we don't need to allocate or define the anycast address.
We just use an LSI prefix that someone running the DHT "happens" to
have allocated for themselves.

--Pekka

From: [email-masked] (Julien Laganier)
Date: Tue Jan 11 08:18:01 2005
Subject: [Hipsec-rg] Routable IPv6 LSIs?
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Hi Pekka,

Your message triggered some thoughts and questions in my mind. More 
below,

On Tuesday 11 January 2005 10:58, Pekka Nikander wrote:
> Folks,
>
> I am reviewing the new base spec (02-pre1) for the WG, and I
> started to wonder whether we should aim for routable IPv6 (and
> maybe also IPv4) LSIs.  That is, now that we have also made the
> distinction between HITs (with don't have a prefix) and LSIs (which
> do have a prefix) in the IPv6 side, and we have something like Hi3
> emerging, maybe we could make LSIs routable?
>
> To make LSIs routable, we would make the whole LSI prefix (either
> IPv6 or IPv4) to act as a kind of anycast prefix.  That is, when
> you send a packet to *any* address within that prefix, the packet
> is routed to the closed "Hi3" node.  From the routing system point
> of view this could be considered as a massively multi-homed
> network, each of the Hi3 nodes acting as a "gateway" to the virtual
> network.  The Hi3 nodes would then use the overlay, just like in
> the current Hi3 specification, to route the packet to the right
> destination.

This seems related to the Anycast 6to4 technique. One thing I don't 
get is that "the whole LSI prefix act as a _kind_ of anycast prefix". 
Why "a kind of" ? Doesn't Anycast work straightforward for this 
purpose?

> Hence, everything would work pretty much like today with Hi3, with
> the exception that for the first packet the sending host does not
> need to know anything else but the LSI (or HIT, if the prefix is
> fixed). Basically, the knowledge of where the closest Hi3 node is
> reachable could be moved from the host to the network.

I'd rather say "(...) could be moved from the end host to the routing 
fabric". This seems to be more precise.

> It should be pretty easy to bootstrap such a scheme.  Get a short
> enough IPv6 prefix, and connect one Hi3 node to act as a gateway to
> all nodes behind that prefix.  If we get some ISP to co-operate, we
> should be able to easily get something like /36, to test this out. 
> For actual production use, of course, it would be better to have a
> much shorter prefix, such as /12 or /16.
>
> Thoughts?  Pitfalls?

I had myself the idea to route I1 to a gateway part of DHT, which 
would take care of the final delivery (i.e. locating the HIT owner), 
while the gateway would be discovered by the initiator using an 
allocated anycast address.

However, as opposed to your proposal, at that time I didn't think to 
use the LSI for that purpose, just the HIT.

Above you wrote: "the sending host does not need to know anything else 
but the LSI (or HIT, if the prefix is fixed)". If I understand 
correctly, you envision two situations:

o A HIT-based routing with a fixed anycast address to discover a 
gateway to the Hi3.

o A LSI-based routing with multiple anycast addresses to discover the 
"nearest" gateway to the Hi3.

So my question is: What is the benefit of having  multiple anycast 
addresses compared to a fixed anycast address allocated for Hi3 
discovery/relay purpose (like 6to4) ? But perhaps I completely missed 
your point :)

Thanks,

--julien

From: [email-masked] (Pekka Nikander)
Date: Tue Jan 11 04:59:01 2005
Subject: [Hipsec-rg] Routable IPv6 LSIs?
Message-ID: <[email-masked]>

Folks,

I am reviewing the new base spec (02-pre1) for the WG, and I started to 
wonder whether we should aim for routable IPv6 (and maybe also IPv4) 
LSIs.  That is, now that we have also made the distinction between HITs 
(with don't have a prefix) and LSIs (which do have a prefix) in the 
IPv6 side, and we have something like Hi3 emerging, maybe we could make 
LSIs routable?

To make LSIs routable, we would make the whole LSI prefix (either IPv6 
or IPv4) to act as a kind of anycast prefix.  That is, when you send a 
packet to *any* address within that prefix, the packet is routed to the 
closed "Hi3" node.  From the routing system point of view this could be 
considered as a massively multi-homed network, each of the Hi3 nodes 
acting as a "gateway" to the virtual network.  The Hi3 nodes would then 
use the overlay, just like in the current Hi3 specification, to route 
the packet to the right destination.

Hence, everything would work pretty much like today with Hi3, with the 
exception that for the first packet the sending host does not need to 
know anything else but the LSI (or HIT, if the prefix is fixed).  
Basically, the knowledge of where the closest Hi3 node is reachable 
could be moved from the host to the network.

It should be pretty easy to bootstrap such a scheme.  Get a short 
enough IPv6 prefix, and connect one Hi3 node to act as a gateway to all 
nodes behind that prefix.  If we get some ISP to co-operate, we should 
be able to easily get something like /36, to test this out.  For actual 
production use, of course, it would be better to have a much shorter 
prefix, such as /12 or /16.

Thoughts?  Pitfalls?

--Pekka

From: [email-masked] (Pekka Nikander)
Date: Wed Jan  5 09:57:01 2005
Subject: [Hipsec-rg] Locators clarified
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Thanks, Tom, for your clarifications, questions, and comments!
They are good indeed!

>> Using this framework, we can classify current HIP as follows:
>>
>>    A. Signalling traffic is carried directly over IP, using the HIP
>>       payload format as specified in the base specification, forwarded
>>       based on the destination IP and destination HIT, and
>>       demultiplexed based on the destination HIT only.
>
> this may be terminology issue, but isn't demultiplexing
> based on the HIT pair?  that is, finding the right HIP
> association for the signaling packet (and HIP associations
> can be identified by the HIT pair).  Or are you just referring
> to the first stage of demultiplexing only?

You are right; I was sloppy in my thinking.  Thanks for the
correction.  I was merely thinking about finding the right
local HIT at the destination end; that is trivial in the case
of HIP packets, but it is NOT trivial in the case of user data
packets.  But yes, more generally you are not interested in
merely finding the right local HIT at the destination but also
what is the sender's HIT.

> Also, what do you mean that forwarding in current HIP is
> based on the HIT?

I was referring to the so called "layer 3.5" routing, or
architected NATs (SPINAT), which basically can hide several
hosts  behind a single IP(v4) address.  Or, in general, they
can bridge different routing domains.

>> For user data, we do not seem to need addressing symmetry.
>> That is, it is NOT a requirement that just reversing the locators 
>> makes
>> it possible to send packets back.  With ESP, we don't have that, but 
>> we
>> still have the potential ability of getting ICMPs back.  Hence, some 
>> care is
>> needed here.
>
> I agree that we don't strictly have that in ESP, but since SAs are
> usually maintained in pairs, hosts effectively have some
> reversability besides ICMP.

Hosts do, yes, but not because of addressing symmetry but because of
the state they have.  The routers in between can send ICMPs only
based on the source IP; if there is any layer 3.5 routing going on,
the layer 3.5 router will most probably consume the ICMP message.
This may make it difficult to implement features like Path MTU 
discovery,
and we need to think about these issues more.

>> I think that we want to have more flexibility wrt.
>> demultiplexing, too.  It looks like that *sometimes* we may be
>> able to use just the standard IP fields, i.e., IP addresses
>> and possibly TCP/UDP port numbers, for determining which local
>> HIT the traffic is destined to.  That would allow HIP to be
>> used without any encapsulation, i.e., not even ESP, for
>> data traffic.
>
> Do you mean host ID embedded in the IID?

That's one possibility, sure.  However, I was merely thinking
about the case where you have one-to-one mapping between hosts
and IP addresses (even in an IPv4 case).  Embedding HI into some
other part of the IP header, such as the IID, certainly adds
flexibility to the scheme.

> If not, I am not seeing
> how having no new demultiplexing context whatsoever provides useful
> new functionality.

Well, it may be that some people just want to have the ability
to support mobility and multi-homing, and nothing else.

> (but I agree with wanting to allow more flexibility
> in demultiplexing, such as a new shim layer perhaps--
> something other than ESP)

Yes, something like that might also be needed, as you may not
necessarily ensure one-to-one mapping between IPs and HITs.

>> Now, if the argument above holds, the future locator format should
>> define the following:
>>
>> 1. Traffic type (signalling, user data, both)
>> 2. Encapsulation format for a) signalling b) user data
>
> I think that you mean "Encapsulation format" period (not
> for a) or b) separately-- if 1. is "both", then, if 2. is
> different for signaling and data, then perhaps those cases
> should be split apart into two locators.)

Right.  I just tried to shy away from actual syntax for the
time being, as I see there several different options, and I
am not sure which one I would favour.  The basic question in
actual locator format is simplicity vs. compression of
representation.

>> 3. Locator parameters for a) signalling b) user data
>
> Same comment for 3.

Right; likewise.

> I think also we may need a "locator type" field of some sort that
> defines the semantics of #3 (e.g., is it an IPv4 address or an
> IPv6 address or an i3 trigger (etc)).

Yes, definitely.  I had that in mind, but it apparently was too
implicit to me.  That would be number zero:

   0. Locator type

> Also, we probably want to retain the concept of "preferred"
> locator when there are more than one to choose from.

Indeed.  But that goes beyond mere locators, into the multi-homing
domain.  But I agree that it should be considered when defining
the concrete syntax.

>> In many cases, much of this will be implied.  The current SPI
>> parameter is a good example of almost extreme compression of this 
>> data.
>
> I'm not seeing where SPI is saying anything about the control plane,
> although I agree that your enumerated list maps to the way current
> HIP works.

Well, the SPI parameter dates from the time when we did not even
think about separating signalling and user data into possibly
different locators.  Hence, it is implicit that if you can send
user data traffic to a given IP address using ESP and given SPI,
you can also send HIP packets to the very same IP address.

> Also, I sense that locators (addresses) and demultiplexing context
> (SPIs) are getting conflated in the above discussion (intentionally?),

Such conflation seems to be an implication of my current thinking.

> and I wonder whether we need to think more about that issue.

Yes, definitely.  That's one of the reasons I sent the message at
this point.

> In particular, I view SPI as being extreme compression of the host
> context (the HIT pair) but not the locators.

If, if you consider using UDP, you see that the "UDP locator" also
has that kind of host context, i.e., the port number.  Hence, at least
in that particular case we cannot really make a difference.

Also, if you consider SPINAT, the SPI becomes an integral part of
the user data locator.

--Pekka

From: [email-masked] (Henderson, Thomas R)
Date: Wed Jan  5 01:19:00 2005
Subject: [Hipsec-rg] Locators clarified
Message-ID: <[email-masked]>

Pekka, I agree in principle with what you are describing.  Some comments
and questions below:

>=20
> Using this framework, we can classify current HIP as follows:
>=20
>    A. Signalling traffic is carried directly over IP, using the HIP
>       payload format as specified in the base specification, forwarded
>       based on the destination IP and destination HIT, and=20
> demultiplexed
>       based on the destination HIT only.

this may be terminology issue, but isn't demultiplexing based on the
HIT pair?  that is, finding the right HIP association for the signaling
packet (and HIP associations can be identified by the HIT pair).  Or
are you just referring to the first stage of demultiplexing only?

Also, what do you mean that forwarding in current HIP is based on the =
HIT?
=20
>=20
> For user data, we do not seem to need addressing symmetry. =20
> That is, it=20
> is NOT a requirement that just reversing the locators makes=20
> it possible=20
> to send packets back.  With ESP, we don't have that, but we=20
> still have=20
> the potential ability of getting ICMPs back.  Hence, some care is=20
> needed here.

I agree that we don't strictly have that in ESP, but since SAs are
usually maintained in pairs, hosts effectively have some=20
reversability besides ICMP.

>=20
> I think that we want to have more flexibility wrt.=20
> demultiplexing, too.=20
>   It looks like that *sometimes* we may be able to use just=20
> the standard=20
> IP fields, i.e., IP addresses and possibly TCP/UDP port numbers, for=20
> determining which local HIT the traffic is destined to.  That would=20
> allow HIP to be used without any encapsulation, i.e., not=20
> even ESP, for=20
> data traffic. =20

Do you mean host ID embedded in the IID?  If not, I am not seeing
how having no new demultiplexing context whatsoever provides useful
new functionality. (but I agree with wanting to allow more flexibility
in demultiplexing, such as a new shim layer perhaps-- something other
than ESP)

> On the other hand, when using UDP=20
> encapsulation (for NAT=20
> traversal), we may want to use cryptographic protection, but at the=20
> same time we do not seem to need the SPI for anything. =20
> Hence, there we=20
> might want to have a yet another encapsulation format, using just the=20
> destination UDP port for HIT-level demultiplexing.
>=20
> -------------
>=20
> Now, if the argument above holds, the future locator format should=20
> define the following:
>=20
> 1. Traffic type (signalling, user data, both)
> 2. Encapsulation format for a) signalling b) user data

I think that you mean "Encapsulation format" period (not
for a) or b) separately-- if 1. is "both", then, if 2. is
different for signaling and data, then perhaps those cases
should be split apart into two locators.)

> 3. Locator parameters for a) signalling b) user data

Same comment for 3.

I think also we may need a "locator type" field of some sort that
defines the semantics of #3 (e.g., is it an IPv4 address or an
IPv6 address or an i3 trigger (etc)).

Also, we probably want to retain the concept of "preferred"
locator when there are more than one to choose from.

>=20
> In many cases, much of this will be implied.  The current S PI=20
> parameter=20
> is a good example of almost extreme compression of this data.=20
>  That is,=20
> a single SPI number can be understood to denote the following:
>=20
> 1. Both signalling and user data
> 2. "Null encapsulation" for signalling, ESP encapsulation for=20
> user data
> 3. < Source IP address from IP header, protocol 99 > for signalling,
>     < Source IP address from IP header, SPI from parameter > for user=20
> data
>=20

I'm not seeing where SPI is saying anything about the control plane,
although I agree that your enumerated list maps to the way current
HIP works.

Also, I sense that locators (addresses) and demultiplexing context
(SPIs) are getting conflated in the above discussion (intentionally?),
and I wonder whether we need to think more about that issue.  In
particular, I view SPI as being extreme compression of the host
context (the HIT pair) but not the locators.

Tom

From: [email-masked] (Pekka Nikander)
Date: Mon Jan  3 08:26:00 2005
Subject: [Hipsec-rg] Locators clarified
Message-ID: <[email-masked]>

Folks,

I have now been thinking a little bit more about locators, based on our 
discussions at the last IETF meeting, and I think that I am reaching 
some level of clarity in this process.  The somewhat lengthy text below 
is an attempt to write up my current ideas.

If we consider the current HIP architecture, we basically carry two 
kinds of traffic: HIP signalling, which are generated and consumed 
within the HIP layer and which are carried as an explicit protocol 
(currently 99), directly on the top of IP; and user datagrams, which 
are basically anything that comes from transport to IP, and which are 
carried within ESP envelope.

I find it important that we make a separation of four dimensions here:
1.  Traffic type (signalling or user data)
2.  Encapsulation
3.  Locators and forwarding
4.  HIT-level demultiplexing at the receiving end

Using these dimensions, one can easily classify the current schemes.  
On the other hand, it also becomes clear that the dimensions are NOT 
independent but that there are many interactions between them.  Only 
some choices make sense from an engineering point of view.

One of the early issues here, stemming from the Hi3 work, was the 
realisation that the locator set for signalling traffic may be a 
different set than the locator set for user data traffic.  That is, in 
Hi3 the signalling locator set includes the Hi3 servers while the user 
data locator set includes only the final end-point, plus any possible 
forwarding agents.

A second issue, which popped up (at least for me) during the last IETF 
meeting, was the idea of defining alternative formats for encapsulation 
(e.g. UDP), alternative methods for forwarding (e.g. UDP NAT), with the 
implied implications on demultiplexing.

Using this framework, we can classify current HIP as follows:

   A. Signalling traffic is carried directly over IP, using the HIP
      payload format as specified in the base specification, forwarded
      based on the destination IP and destination HIT, and demultiplexed
      based on the destination HIT only.

   B. User data traffic is carried as wrapped in ESP, over IP, using
      the ESP format as specified in the IPsec ESP specification,
      forwarded based on the destination IP and ESP SPI (SPINAT), and
      HIT-level demultiplexing based on the ESP SPI only.

What comes to signalling traffic, I think that is is important that
we keep the following properties invariant:

   A1. Demultiplexing at the destination is based on destination HIT 
only.
   A2. It is always possible to reply to a HIP signalling packet by
       reversing the HITs and any encapsulating identifiers, such as
       UDP port numbers or IP addresses.  This implies symmetric
       encapsulation format.  (E.g. ESP cannot be used)

While keeping those issues in mind, we can define new encapsulation 
formats and forwarding mechanisms for passing around HIP signalling 
packets, such as UDP-based NAT traversal.

What comes to user data, the situation seems more complex.  We 
seemingly want to have more flexibility in passing the traffic.  
Sometimes we want to have the security properties provided by ESP, 
sometimes we don't.  In any case, it looks better to get rid of the 
current dependency on ESP, and provide at least the *potentiality* for 
something more flexible.

For user data, we do not seem to need addressing symmetry.  That is, it 
is NOT a requirement that just reversing the locators makes it possible 
to send packets back.  With ESP, we don't have that, but we still have 
the potential ability of getting ICMPs back.  Hence, some care is 
needed here.

I think that we want to have more flexibility wrt. demultiplexing, too. 
  It looks like that *sometimes* we may be able to use just the standard 
IP fields, i.e., IP addresses and possibly TCP/UDP port numbers, for 
determining which local HIT the traffic is destined to.  That would 
allow HIP to be used without any encapsulation, i.e., not even ESP, for 
data traffic.  On the other hand, when using UDP encapsulation (for NAT 
traversal), we may want to use cryptographic protection, but at the 
same time we do not seem to need the SPI for anything.  Hence, there we 
might want to have a yet another encapsulation format, using just the 
destination UDP port for HIT-level demultiplexing.

-------------

Now, if the argument above holds, the future locator format should 
define the following:

1. Traffic type (signalling, user data, both)
2. Encapsulation format for a) signalling b) user data
3. Locator parameters for a) signalling b) user data

In many cases, much of this will be implied.  The current SPI parameter 
is a good example of almost extreme compression of this data.  That is, 
a single SPI number can be understood to denote the following:

1. Both signalling and user data
2. "Null encapsulation" for signalling, ESP encapsulation for user data
3. < Source IP address from IP header, protocol 99 > for signalling,
    < Source IP address from IP header, SPI from parameter > for user 
data

-----------

Any comments?  Something that I am missing?

--Pekka