Subject: [Hipsec-rg] InfraHIP
From: [email-masked] (Julien Laganier)
Date: Wed Nov 24 05:16:01 2004

On Sunday 21 November 2004 15:18, Andrei Gurtov wrote:
> Hi,

Hi Andrei,

> I'm glad to announce that the InfraHIP project at HIIT has been
> funded for its first year by Finnish NSF and several companies in
> Finland. We would have about seven people working on the
> infrastructure that is necessary for HIP deployment. A rough plan
> of issues to study during the next 2-3 years includes following:

This is great news! HIP is going to rules with the functionalities 
below:

> -Extend hi3 implementation and experiment with it on PlanetLab
> (only the control plane)
> -Interface with DHT resolution service, OpenDHT
> -HIPL to Linux kernel, finalize native API, rendezvous server
> -Multiple HI per host
> -Process migration with HIP
> -HIP for trust in P2P
> -VPN, firewall, NAT, management tool

I would be very interested to collaborate on the following topics 
because they are working items of my PhD:

- OpenDHT, because it allows to bypass DNS for HIT->IP resolution
- Multiple HI per host, because it allows several entities sharing a 
single host to be logically separated.
- Process migration with HIP, and its relationship to clustering/grid 
computing.

So if you need some more cycles to work on any on the above, just tell 
me!

Cheers,

--julien

-- 
Julien Laganier 
SUN Microsystems Laboratories

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." -- Brian W.  Kernighan

From: [email-masked] (Henderson, Thomas R)
Date: Mon Nov 22 00:55:01 2004
Subject: [Hipsec-rg] workshop materials posted
Message-ID: <[email-masked]>

FYI, the materials from the recent HIP and Related Architectures =
workshop are available at:
http://hiprg.piuha.net/workshop/

Tom

From: [email-masked] (Henderson, Thomas R)
Date: Mon Nov 22 00:51:00 2004
Subject: [Hipsec-rg] A vs. B
Message-ID: <[email-masked]>

> -----Original Message-----
> From: Greg Perkins [mailto:[email-masked]]
> Sent: Friday, November 19, 2004 10:22 AM
> To: Henderson, Thomas R
> Cc: [email-masked]
> Subject: Re: [Hipsec-rg] A vs. B
>=20
>=20
> Tom,
>=20
> > I am not sure I agree with the above, or perhaps I don't understand
> > your point, or maybe there is a terminology issue.  The HI and HIT
> > really are identifiers.  They name the endpoint that holds the
> > corresponding private key.  It doesn't matter whether the=20
> identifiers
> > are well-known or anonymous or unregistered-- they are still
> > identifiers nonetheless.
>=20
> I am still getting up to speed on the terminology so forgive=20
> me since I
> misused it in some places.  In my mind a host identifier is a=20
> device/PC
> identifier, which a HIP HI can be but definitely doesn't have=20
> to be.  Any
> chance we can call them EI's then?  End-point identifiers?

See the terminology section in the HIP architecture draft, where
the Host Identity terminology is linked to the end-point terminology.
In the architecture draft, there is a distinction between public vs.=20
unpublished host identifiers, but they are both EIDs.

> > I don't know what you mean by 'dropping' the security features,
> > or running a base exchange without creating any ESP-- what is the
> > point of doing HIP in that case?
>   Currently, the internet works well without HIP but IPv6=20
> opens up a number
> of attacks that are currently not present (or IPv6 makes some=20
> attacks easier
> to perform).  Still, most sessions shouldn't need any active security
> because they aren't typically being attacked.  As I browse=20
> the Internet on
> my mobile phone I'd rather not spend cycles on security that=20
> most likely
> isn't needed.  If I detect that my session(s) are being=20
> hijacked then I can
> move into an active security state and re-claim ownership of=20
> sessions.  This
> is probably subject to some type of man-in-the-middle attack=20
> but for normal
> Internet use I somehow doubt that will be much of a threat.
>   On the other end the service provider can force active=20
> security if they
> perceive a DoS attack is under-way (or some other threat)=20
> (they up K for the
> puzzle, verify all sessions, etc.).  But during normal=20
> operations HIP is not
> 'enforced' but session identifiers can still be passed.
>   I guess I will call this passive-HIP.  I can see a use for=20
> this type of
> implementation.  Thoughts?
>=20

We've had some discussions previously as to whether a session could
be upgraded to full HIP protection after it started.  For example,
if one party decides to later change its addresses.  There are some
details that need to be worked out regarding what to use in the
transport pseudoheader, and how to do the IP-address-to-session
context mapping.  IIRC, there wasn't fundamental opposition to
this concept, but it seems to be a lower priority agenda item
to develop such a proposal more fully.=20

See also the lightweight HIP draft in the multi6 group, along these
same lines:
draft-nikander-multi6-hip-01

Tom=20

From: [email-masked] (Andrei Gurtov)
Date: Sun Nov 21 09:19:01 2004
Subject: [Hipsec-rg] InfraHIP
Message-ID: <[email-masked]>

Hi,

I'm glad to announce that the InfraHIP project at HIIT has been funded 
for its first year by Finnish NSF and several companies in Finland. We 
would have about seven people working on the infrastructure that is 
necessary for HIP deployment. A rough plan of issues to study during the 
next 2-3 years includes following:

-Extend hi3 implementation and experiment with it on PlanetLab (only the 
control plane)
-Interface with DHT resolution service, OpenDHT
-HIPL to Linux kernel, finalize native API, rendezvous server
-Multiple HI per host
-Process migration with HIP
-HIP for trust in P2P
-VPN, firewall, NAT, management tool

Andrei

-- 
Andrei Gurtov   http://www.hiit.fi/andrei.gurtov
PhD, Research Scientist, Project Manager
Helsinki Institute for Information Technology (HIIT)
Advanced Research Unit (ARU)
High Tech Center, Helsinki, Finland

From: [email-masked] (Greg Perkins)
Date: Fri Nov 19 13:09:01 2004
Subject: [Hipsec-rg] A vs. B
References: <[email-masked] g.com>
Message-ID: <0e3101c4ce64$ab53bde0$ef01a996@gmp>

Tom,

> I am not sure I agree with the above, or perhaps I don't understand
> your point, or maybe there is a terminology issue.  The HI and HIT
> really are identifiers.  They name the endpoint that holds the
> corresponding private key.  It doesn't matter whether the identifiers
> are well-known or anonymous or unregistered-- they are still
> identifiers nonetheless.

I am still getting up to speed on the terminology so forgive me since I
misused it in some places.  In my mind a host identifier is a device/PC
identifier, which a HIP HI can be but definitely doesn't have to be.  Any
chance we can call them EI's then?  End-point identifiers?

To clarify, I perceive a difference between an HI that can be used to
'look-me-up' somewhere as opposed to one I create and use as an end-point
identifier.  Like handing out a business card with a HI on it is more than
just a end-point identifier IMO.  I see the first being used to find out
someone's current location on the Internet while the second is used for
sessions over ports you may not want to be contacted through (firewall
issues, etc.).  This does go beyond base HIP, which is why I am trying (so
far unsuccessfully) to make the point here.

Now that I think about it, maybe there should be 'Lookup Identifiers'-LIs
and 'End-point Identifiers'-EIs.  LIs are static and can be handed out.  EIs
can be transient.  Both can be used to identify sessions. Hmmmm.

> I don't know what you mean by 'dropping' the security features,
> or running a base exchange without creating any ESP-- what is the
> point of doing HIP in that case?
  Currently, the internet works well without HIP but IPv6 opens up a number
of attacks that are currently not present (or IPv6 makes some attacks easier
to perform).  Still, most sessions shouldn't need any active security
because they aren't typically being attacked.  As I browse the Internet on
my mobile phone I'd rather not spend cycles on security that most likely
isn't needed.  If I detect that my session(s) are being hijacked then I can
move into an active security state and re-claim ownership of sessions.  This
is probably subject to some type of man-in-the-middle attack but for normal
Internet use I somehow doubt that will be much of a threat.
  On the other end the service provider can force active security if they
perceive a DoS attack is under-way (or some other threat) (they up K for the
puzzle, verify all sessions, etc.).  But during normal operations HIP is not
'enforced' but session identifiers can still be passed.
  I guess I will call this passive-HIP.  I can see a use for this type of
implementation.  Thoughts?

Greg

----- Original Message ----- 
From: "Henderson, Thomas R" <[email-masked]>
To: "Greg Perkins" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, November 17, 2004 5:02 PM
Subject: RE: [Hipsec-rg] A vs. B

>
>
> > -----Original Message-----
> > From: Greg Perkins [mailto:[email-masked]]
> > Sent: Wednesday, November 17, 2004 10:54 AM
> > To: [email-masked]; Henderson, Thomas R; Robert Moskowitz
> > Cc: Pekka Nikander; [email-masked]
> > Subject: Re: [Hipsec-rg] A vs. B
> >
> >
> > I'd like to point out that the public key HI really isn't an
> > identifier but
> > a means for showing proof that you are the rightful owner of an IPv6
> > address.  When proof of ownership is not needed then the
> > security features
> > of HIP can be 'dropped'.  I believe that in such cases the
> > base HIP exchange
> > can be made but no authentication or SA is created.  Later,
> > if problems
> > arise, the information passed can be used to prove ownership
> > and to then
> > setup a secure session.  So one can split A and B, though it
> > is debatable if
> > this is good/bad.
> >
> > The HI being a real identfier versus only a means to prove
> > address ownership
> > has issues in how others look-up addresses via an HI.  But
> > the fact that the
> > HI can be either is another selling point for HIP.  I can
> > have an HI which
> > is an identfier and that can be used to 'look me up' and
> > other HIs that I
> > use in anonymous mode.
> >
>
> Greg,
> I am not sure I agree with the above, or perhaps I don't understand
> your point, or maybe there is a terminology issue.  The HI and HIT
> really are identifiers.  They name the endpoint that holds the
> corresponding private key.  It doesn't matter whether the identifiers
> are well-known or anonymous or unregistered-- they are still
> identifiers nonetheless.
>
> I don't know what you mean by 'dropping' the security features,
> or running a base exchange without creating any ESP-- what is the
> point of doing HIP in that case?
>
> In the second paragraph, it sounds like you are equating anonymous
> mode with proving address ownership.  I don't think that anonymous
> mode proves address ownership-- on the contrary, anonymous mode can
> set you up for a man-in-the-middle attack.  Anonymous mode does
> assure you that the host you started to talk to at the beginning of
> the session remains the same, whether or not its address(es) change.
>
> Tom
>
>

From: [email-masked] (Pekka Nikander)
Date: Fri Nov 19 05:07:01 2004
Subject: [Hipsec-rg] A vs. B
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

>> The question seems to boil down to making sure it is still the *same* 
>> entity and that the entity are able to *receive* packets at the given 
>> locator.  B seems to be mostly about the latter, leaving the question 
>> of what the entity is more open.  (In the case of HIP, the entity is 
>> whatever possesses the private key corresponding to the public key.)
>
> I agree with your refinement of B above, except that I would suggest 
> that B is both about the former (*same* entity) and latter (*receive* 
> packets), even though B is agnostic about what the identifier 
> semantics are.

I agree with you.  It is about both.

However, somehow I seem to feel that it is *more* about the latter 
(receiving packets), but I find it hard time to explain (even to 
myself) why I feel so.  Maybe because there could be various degrees of 
"sameness"?  I mean, public key based "sameness" is apparently stronger 
than "sameness" based on a simple cookie, while "sameness" based on 
hash chains is somewhere in between.  IIRC, what Ion called for was 
identifiers that would not even take stance on the level of "sameness" 
but mostly leave even that for upper layers.  Now, I don't necessarily 
agree with Ion, due to my concerns about flooding attacks, but we 
_should_ understand his concerns.

>>> 1) decouples identity from locators, below the transport layer,
>>> but above the IP layer
>>> 2) defines a protocol to securely bind identifier to locators
>>> 3) has non-IP-routable identifiers with specific crypto semantics;
>>> namely, keys and hashes of keys
>>> 4) resolves identifier to locator at the endpoints
>>> 5) uses ESP headers as a context tag for demultiplexing the
>>> locator to identifier binding

<snip>

> The practical question is whether we need to split out 1+2 and 3 in 
> some way-- whether HIP should define a monolithic 1+2+3 or some 
> modular way forward (1+2, plus mandatory 3, but written in such a way 
> that some other 3 is possibly defined in the future).

This is a very good question, indeed.  For clarity, I would continue to 
call 1+2+3 as HIP, and call the other thing ("B") as something else, 
not even LHIP.  We don't call UDP as Light Weight TCP, do we?

Maybe we should call the "B-only" protocol as LIP, for Lightweight 
Identity Protocol.  To me, it looks like that LIP should be very 
simple, just providing semantics-free end-to-end identifiers with bare 
bones connectivity across routing realms.

> A good thought experiment might be to consider whether one could 
> support
> something like WIMP or HBA by using HIP protocols.

Well, we most probably could reuse the HIP packet formats.  We might 
also be able to (and want to) share much of the forthcoming 
infrastructure, e.g., DHTs, architected middle boxes, and such. 
However, I think that from the multiplexing point of view it most 
probably makes sense to have another protocol number.  If not end 
hosts, then middle boxes would probably want to handle the two cases 
differently.

Another important issue is the APIs.  There is the question of how to 
support these at the current APIs and retain manageability.  Then there 
is the other question of what would be the right abstractions for the 
future APIs for these.

--Pekka

From: [email-masked] (Henderson, Thomas R)
Date: Thu Nov 18 10:29:01 2004
Subject: [Hipsec-rg] A vs. B
Message-ID: <[email-masked]>

> -----Original Message-----
> From: Pekka Nikander [mailto:[email-masked]]=20
> Sent: Thursday, November 18, 2004 12:14 AM
> To: Henderson, Thomas R
> Cc: [email-masked]
> Subject: Re: [Hipsec-rg] A vs. B
>=20
>=20
> > B.  securely binds the identifier to the locators (this is=20
> what the HIP
> > "on-the-wire" protocol is all about)
>=20
> Well, what this "B" is, exactly, seems to be partially unclear, at=20
> least to me.  I have to admit that when considering a number of=20
> possible cases, especially in the light of the proposed extended=20
> locators, I am not sure what a "secure binding" between an identifier=20
> and locator would be.  As a base line, we seem to have the return=20
> routability test.  If you are able to receive packets sent to a=20
> locator, you can be considered to have some right to "own" that=20
> locator.
>=20
> The question seems to boil down to making sure it is still the *same*=20
> entity and that the entity are able to *receive* packets at the given=20
> locator.  B seems to be mostly about the latter, leaving the question=20
> of what the entity is more open.  (In the case of HIP, the entity is=20
> whatever possesses the private key corresponding to the public key.)
>=20
> But maybe I am missing something here?

I agree with your refinement of B above, except that I would suggest =
that
B is both about the former (*same* entity) and latter (*receive* =
packets),
even though B is agnostic about what the identifier semantics are.

>=20
> > I think that the current HIP could be succinctly described=20
> as follows:
> >
> > 1) decouples identity from locators, below the transport layer,
> > but above the IP layer
> > 2) defines a protocol to securely bind identifier to locators
> > 3) has non-IP-routable identifiers with specific crypto semantics;
> > namely, keys and hashes of keys
> > 4) resolves identifier to locator at the endpoints
> > 5) uses ESP headers as a context tag for demultiplexing the
> > locator to identifier binding
>=20
> This is a very good list, indeed.
>=20
> > Now, I guess we can debate which of the above is the core HIP.
> > My vote would be for 1 and 2.
>=20
> Well, depending on what you mean with the secure binding with=20
> identifiers and locators, I would consider 1+2 to roughly=20
> correspond to=20
> the "B" property above.
>=20
> With regard to HIP, I would still consider 3 to be core HIP.  Leaving=20
> that out would require us to reconsider the security model, and the=20
> result would not, IMHO, be HIP any more.
>
<snip>
>=20
> Along the same lines, I think providing B alone is probably a good=20
> idea.  It may have security concerns, but so has many current=20
> IP based=20
> protocols.  It is more a matter of clearly spelling out those=20
> security=20
> concerns than being overly protective, at least IMHO.
>=20

So it seems to me that we are differing only slightly, maybe on semantic
issues.  The practical question is whether we need to split out 1+2
and 3 in some way-- whether HIP should define a monolithic 1+2+3 or
some modular way forward (1+2, plus mandatory 3, but written in such
a way that some other 3 is possibly defined in the future).

A good thought experiment might be to consider whether one could support =

something like WIMP or HBA by using HIP protocols.

Tom

From: [email-masked] (Pekka Nikander)
Date: Thu Nov 18 02:02:01 2004
Subject: [Hipsec-rg] A vs. B
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Tom,

> A.  more than just bound to a public key, identifiers *are* public
> keys (or hashes thereof) and have inherent self-certifying properties

I agree with you, I was not clear in stating A.

Trying to think more clearly now, I wholeheartedly agree that in HIP 
the public key is the actual identifier, not the hash of it.  
Consequently, going into details, a B-only protocol would probably have 
a HIT that is a hash of something else, and that may also have other 
properties but A.

> B.  securely binds the identifier to the locators (this is what the HIP
> "on-the-wire" protocol is all about)

Well, what this "B" is, exactly, seems to be partially unclear, at 
least to me.  I have to admit that when considering a number of 
possible cases, especially in the light of the proposed extended 
locators, I am not sure what a "secure binding" between an identifier 
and locator would be.  As a base line, we seem to have the return 
routability test.  If you are able to receive packets sent to a 
locator, you can be considered to have some right to "own" that 
locator.

The question seems to boil down to making sure it is still the *same* 
entity and that the entity are able to *receive* packets at the given 
locator.  B seems to be mostly about the latter, leaving the question 
of what the entity is more open.  (In the case of HIP, the entity is 
whatever possesses the private key corresponding to the public key.)

But maybe I am missing something here?

> I think that the current HIP could be succinctly described as follows:
>
> 1) decouples identity from locators, below the transport layer,
> but above the IP layer
> 2) defines a protocol to securely bind identifier to locators
> 3) has non-IP-routable identifiers with specific crypto semantics;
> namely, keys and hashes of keys
> 4) resolves identifier to locator at the endpoints
> 5) uses ESP headers as a context tag for demultiplexing the
> locator to identifier binding

This is a very good list, indeed.

> Now, I guess we can debate which of the above is the core HIP.
> My vote would be for 1 and 2.

Well, depending on what you mean with the secure binding with 
identifiers and locators, I would consider 1+2 to roughly correspond to 
the "B" property above.

With regard to HIP, I would still consider 3 to be core HIP.  Leaving 
that out would require us to reconsider the security model, and the 
result would not, IMHO, be HIP any more.

I agree with the rest of your analysis on the 5-point list.

>>> There might be some value in separating A and B, and allowing upper
>>> layers to select either A+B or just B.
>
> The way that you state this, is it an explicit choice of functionality
> in your mind, or just an implicit selection based on what names
> that the upper layers choose to use?

Well, I am currently agnostic about this.  Basically, from an 
architectural and semantic point of view, an explicit choice would be 
better.  However, considering backward compatibility issues, carefully 
controlled and administered implicit selection might also make sense.

> I think it is the latter; upper layers are not directly selecting "I 
> want A+B" but are instead selecting a name that may or may not give 
> them the A and/or B properties.

Well, the security models for A+B or B would be different.  Most 
probably it would not be "safe" to use B-only with some upper layer 
protocols.  That may make implicit selection hard, and at least it 
warrants administrative control mechanisms, at least IMHO.

>>> B would provide enough  security just to protect innocent bystanders 
>>> from flooding and other related attacks that might be created by B 
>>> itself.
>
> How does B provide this by itself, without any secure binding?  B by
> itself seems worse than what we currently have on the Internet.

Well, that *might* well be the case for B alone.  The upper layers may 
make a difference, case-by-case.

I still think that providing UDP in parallel with TCP has had great 
value.  Even if you can use UDP to harm the Internet, most upper layer 
protocols use it in a responsible way.  On the other hand, UDP being 
there has definitely fostered innovation.

Along the same lines, I think providing B alone is probably a good 
idea.  It may have security concerns, but so has many current IP based 
protocols.  It is more a matter of clearly spelling out those security 
concerns than being overly protective, at least IMHO.

>> The trouble I have with this classification to A and B is
>> that I'm not sure anyone is providing, or can provide just B.
>> There seems to be a need to ensure a cryptographic binding so
>> that no vulnerabilities are opened by B.

Well, it is a different matter of creating an on-the-fly cryptographic 
binding when you open an host-to-host association and requiring that 
the identifier has any specific cryptographic bindings per se.

If we take the stance that the "layer 3.5" protocol level identifier is 
a hash of *something*, we may engineer a "B-only" protocol where the 
hash is created from the "upper layer" identifier and some on-the-fly 
created cryptographically meaningful piece of data, e.g., a hash 
anchor.

> If the question is whether public-key-based names are useful themselves
> as names, outside of the HIP context, I would think probably not,
> unless we are talking strictly machine-to-machine communication,
> because humans will almost certainly want to assign human-friendly
> aliases like URIs to the keys, in which case we are back to the
> binding again.

While I almost agree with you, I want to point out that according to at 
least some forecasts, there will be much more machine-to-machine 
communication in the future.  Yes, I agree that humans do want to have 
human-friendly names, but I also tend to think that those names are 
likely to have only non-global scope.  That would leave the public keys 
as the only globally scoped names.  There is value in that, indeed.

--Pekka N.

From: [email-masked] (Pekka Nikander)
Date: Thu Nov 18 01:29:00 2004
Subject: [Hipsec-rg] A vs. B
In-Reply-To: <6.1.2.0.2.20041117115610.046ae238@localhost>
References: <[email-masked]> <[email-masked]> <6.1.2.0.2.20041117115610.046ae238@localhost>
Message-ID: <[email-masked]>

This is good discussion!

> To consider a non-cryptographic identity, the impact on the risk model 
> has to be reviewed.

I want to only clarify one thing.

As far as I understood the discussions going on at the Nov 6th workshop 
and afterwards at the IETF, nobody was proposing that we would consider 
non-cryptographic identifiers within the scope of *HIP*.  That would be 
like considering TCP without congestion control.  It is not the same 
thing any more.

The point was, more or less, that maybe we would like to consider 
another parallel protocol at the same layer.  One with less features, 
mainly targeted to those upper layer protocols that already provide the 
same kind of security features that HIP does.  TLS, probably with some 
slight modifications, comes to my mind.

Yes, I agree that if we consider such another protocol, parallel to 
HIP, we have to start from the very beginning, security wise, and 
clearly specify the assumed risk, threat, and trust models in the 
applicability statement.

--Pekka Nikander

From: [email-masked] (Henderson, Thomas R)
Date: Wed Nov 17 15:51:01 2004
Subject: [Hipsec-rg] A vs. B
Message-ID: <[email-masked]>

> -----Original Message-----
> From: Greg Perkins [mailto:[email-masked]]=20
> Sent: Wednesday, November 17, 2004 10:54 AM
> To: [email-masked]; Henderson, Thomas R; Robert Moskowitz
> Cc: Pekka Nikander; [email-masked]
> Subject: Re: [Hipsec-rg] A vs. B
>=20
>=20
> I'd like to point out that the public key HI really isn't an=20
> identifier but
> a means for showing proof that you are the rightful owner of an IPv6
> address.  When proof of ownership is not needed then the=20
> security features
> of HIP can be 'dropped'.  I believe that in such cases the=20
> base HIP exchange
> can be made but no authentication or SA is created.  Later,=20
> if problems
> arise, the information passed can be used to prove ownership=20
> and to then
> setup a secure session.  So one can split A and B, though it=20
> is debatable if
> this is good/bad.
>=20
> The HI being a real identfier versus only a means to prove=20
> address ownership
> has issues in how others look-up addresses via an HI.  But=20
> the fact that the
> HI can be either is another selling point for HIP.  I can=20
> have an HI which
> is an identfier and that can be used to 'look me up' and=20
> other HIs that I
> use in anonymous mode.
>=20

Greg,
I am not sure I agree with the above, or perhaps I don't understand
your point, or maybe there is a terminology issue.  The HI and HIT=20
really are identifiers.  They name the endpoint that holds the=20
corresponding private key.  It doesn't matter whether the identifiers=20
are well-known or anonymous or unregistered-- they are still=20
identifiers nonetheless.

I don't know what you mean by 'dropping' the security features,=20
or running a base exchange without creating any ESP-- what is the=20
point of doing HIP in that case? =20

In the second paragraph, it sounds like you are equating anonymous=20
mode with proving address ownership.  I don't think that anonymous
mode proves address ownership-- on the contrary, anonymous mode can
set you up for a man-in-the-middle attack.  Anonymous mode does=20
assure you that the host you started to talk to at the beginning of
the session remains the same, whether or not its address(es) change.

Tom =20

From: [email-masked] (Greg Perkins)
Date: Wed Nov 17 12:28:01 2004
Subject: [Hipsec-rg] A vs. B
References: <[email-masked] g.com><[email-masked]> <6.1.2.0.2.20041117115610.046ae238@localhost>
Message-ID: <0d4101c4ccd6$cd5824b0$ef01a996@gmp>

I'd like to point out that the public key HI really isn't an identifier but
a means for showing proof that you are the rightful owner of an IPv6
address.  When proof of ownership is not needed then the security features
of HIP can be 'dropped'.  I believe that in such cases the base HIP exchange
can be made but no authentication or SA is created.  Later, if problems
arise, the information passed can be used to prove ownership and to then
setup a secure session.  So one can split A and B, though it is debatable if
this is good/bad.

The HI being a real identfier versus only a means to prove address ownership
has issues in how others look-up addresses via an HI.  But the fact that the
HI can be either is another selling point for HIP.  I can have an HI which
is an identfier and that can be used to 'look me up' and other HIs that I
use in anonymous mode.

> >>1) decouples identity from locators, below the transport layer,
> >>but above the IP layer
This applies to both cases.

> >>2) defines a protocol to securely bind identifier to locators
This applis to both.

> >>3) has non-IP-routable identifiers with specific crypto semantics;
> >>namely, keys and hashes of keys
This applies only when the HI is an identifier rather than a proof of
ownership.

> >>4) resolves identifier to locator at the endpoints
> >>5) uses ESP headers as a context tag for demultiplexing the
> >>locator to identifier binding

Therefore I argue that 1, 2 and 3 are all main points of HIP (along with
some others Pekka mentioned).

Greg Perkins

----- Original Message ----- 
From: "Robert Moskowitz" <[email-masked]>
To: <[email-masked]>; "Henderson, Thomas R"
<[email-masked]>
Cc: "Pekka Nikander" <[email-masked]>;
<[email-masked]>
Sent: Wednesday, November 17, 2004 1:00 PM
Subject: Re: [Hipsec-rg] A vs. B

> At 11:34 AM 11/17/2004, Jari Arkko wrote:
> >Henderson, Thomas R wrote:
> >
> >>1) decouples identity from locators, below the transport layer,
> >>but above the IP layer
> >>2) defines a protocol to securely bind identifier to locators
> >>3) has non-IP-routable identifiers with specific crypto semantics;
> >>namely, keys and hashes of keys
> >>4) resolves identifier to locator at the endpoints
> >>5) uses ESP headers as a context tag for demultiplexing the
> >>locator to identifier binding
> >
> >This is an excellent breakdown, thanks!
> >
> >>Now, I guess we can debate which of the above is the core HIP.
> >>My vote would be for 1 and 2.
> >
> >I tend to agree. Note that #3 does have some issues with
> >current applications and referrals, leading the Multi6 folks
> >to look at CGA-like solutions that do not create a new non-routable
> >identifier space.
>
> To consider a non-cryptographic identity, the impact on the risk model has
> to be reviewed.  What sort of significant resource attacks are possible in
> this situation?  What sort of attacks against the HIP exchange are now
> possible?
>
> Anyone looking at alternatives really needs to do that analysis.  Again.
>
>
>
>
> _______________________________________________
> Hipsec-rg mailing list
> [email-masked]
> http://honor.trusecure.com/mailman/listinfo/hipsec-rg
>

From: [email-masked] (Jari Arkko)
Date: Wed Nov 17 12:19:00 2004
Subject: [Hipsec-rg] A vs. B
In-Reply-To: <6.1.2.0.2.20041117115610.046ae238@localhost>
References: <[email-masked]> <[email-masked]> <6.1.2.0.2.20041117115610.046ae238@localhost>
Message-ID: <[email-masked]>

Robert Moskowitz wrote:

>> I tend to agree. Note that #3 does have some issues with
>> current applications and referrals, leading the Multi6 folks
>> to look at CGA-like solutions that do not create a new non-routable
>> identifier space.
> 
> 
> To consider a non-cryptographic identity, the impact on the risk model 
> has to be reviewed.  What sort of significant resource attacks are 
> possible in this situation?  What sort of attacks against the HIP 
> exchange are now possible?
> 
> Anyone looking at alternatives really needs to do that analysis.  Again.

Sure, but in the case that I referred to above people were
NOT considering a non-cryptographic identity. They were considering
a *routable cryptographic identity* as opposed to a non-routable
cryptographic identity...

--Jari

From: [email-masked] (Robert Moskowitz)
Date: Wed Nov 17 11:48:01 2004
Subject: [Hipsec-rg] A vs. B
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <6.1.2.0.2.20041117115610.046ae238@localhost>

At 11:34 AM 11/17/2004, Jari Arkko wrote:
>Henderson, Thomas R wrote:
>
>>1) decouples identity from locators, below the transport layer,
>>but above the IP layer
>>2) defines a protocol to securely bind identifier to locators
>>3) has non-IP-routable identifiers with specific crypto semantics; 
>>namely, keys and hashes of keys
>>4) resolves identifier to locator at the endpoints
>>5) uses ESP headers as a context tag for demultiplexing the
>>locator to identifier binding
>
>This is an excellent breakdown, thanks!
>
>>Now, I guess we can debate which of the above is the core HIP.
>>My vote would be for 1 and 2.
>
>I tend to agree. Note that #3 does have some issues with
>current applications and referrals, leading the Multi6 folks
>to look at CGA-like solutions that do not create a new non-routable
>identifier space.

To consider a non-cryptographic identity, the impact on the risk model has 
to be reviewed.  What sort of significant resource attacks are possible in 
this situation?  What sort of attacks against the HIP exchange are now 
possible?

Anyone looking at alternatives really needs to do that analysis.  Again.

From: [email-masked] (Jari Arkko)
Date: Wed Nov 17 11:25:01 2004
Subject: [Hipsec-rg] A vs. B
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Henderson, Thomas R wrote:

> 1) decouples identity from locators, below the transport layer,
> but above the IP layer
> 2) defines a protocol to securely bind identifier to locators
> 3) has non-IP-routable identifiers with specific crypto semantics; 
> namely, keys and hashes of keys
> 4) resolves identifier to locator at the endpoints
> 5) uses ESP headers as a context tag for demultiplexing the
> locator to identifier binding

This is an excellent breakdown, thanks!

> Now, I guess we can debate which of the above is the core HIP.
> My vote would be for 1 and 2.

I tend to agree. Note that #3 does have some issues with
current applications and referrals, leading the Multi6 folks
to look at CGA-like solutions that do not create a new non-routable
identifier space.

--Jari

From: [email-masked] (Henderson, Thomas R)
Date: Wed Nov 17 11:18:01 2004
Subject: [Hipsec-rg] A vs. B
Message-ID: <[email-masked]>

Pekka, I agreed with most of your personal view message, but some
comments
below.=20

> -----Original Message-----
> From: Jari Arkko [mailto:[email-masked]]
> Sent: Monday, November 15, 2004 11:08 AM
> To: Pekka Nikander
> Cc: [email-masked]
> Subject: [Hipsec-rg] A vs. B (Was: Re: [Hipsec] Pekka Nikander's=20
> personal view on HIPrelated discussions at DC)
>=20
> Pekka Nikander wrote:
>=20
> > A and B, or the value of non-secure identifiers=20
> > =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> >=20
> > Right now, HIP seems to provide two "services" at its core.=20
>  It aims
> > to provide identifiers that
> >   A. have a cryptographically strong binding to a public key, and
> >   B. have a location-independent end-to-end semantics, at
> the lowest
> > possible layer in the stack.

I would define slightly differently what HIP currently is, but maybe the
distinction is important. I would restate A and B as:

A.  more than just bound to a public key, identifiers *are* public
keys (or hashes thereof) and have inherent self-certifying properties
B.  securely binds the identifier to the locators (this is what the HIP
"on-the-wire" protocol is all about)

The proposal from the academic contingent at the HIP workshop=20
was, I believe, to consider whether A is absolutely necessary
(or whether other options are possible, including names without
crypto semantics such as i3 triggers).

Moreover, as for B, HIP does an early (endpoint) binding rather=20
than a late binding as in i3; i.e., HIP does not route on the
identifiers, although proposals such as Hi3 propose to extend
it that direction.

So in summary, beyond A and B identified above, I think that=20
the current HIP could be succinctly described as follows:

1) decouples identity from locators, below the transport layer,
but above the IP layer
2) defines a protocol to securely bind identifier to locators
3) has non-IP-routable identifiers with specific crypto semantics;=20
namely, keys and hashes of keys
4) resolves identifier to locator at the endpoints
5) uses ESP headers as a context tag for demultiplexing the
locator to identifier binding

Now, I guess we can debate which of the above is the core HIP.
My vote would be for 1 and 2.  I like 3 and would like to
stay focused on it, but might be convinced to generalize on that=20
point if 2 is retained for some other type of identifiers.  For
example, CGA/HBA is an IP-routable variant of 3 with slightly=20
different crypto and usage properties.  Hi3 and overlays and
delegation servers (rendezvous) are variants of 4, and lightweight=20
HIP is a variant of 5.

> >=20
> > There might be some value in separating A and B, and allowing upper=20
> > layers to select either A+B or just B. =20

The way that you state this, is it an explicit choice of functionality
in your mind, or just an implicit selection based on what names
that the upper layers choose to use?  I think it is the latter; upper
layers are not directly selecting "I want A+B" but are instead
selecting a name that may or may not give them the A and/or B=20
properties.

> > B would provide enough=20
> > security just to protect innocent bystanders from flooding=20
> and other=20
> > related attacks that might be created by B itself. =20

How does B provide this by itself, without any secure binding?  B by
itself seems worse than what we currently have on the Internet.

(This was Jari's comment below, as well).=20

> > A+B, on=20
> the other=20
> > hand, would provide the full package, i.e., that "You know whom you=20
> > are talking to", where whom is defined by the public key.  That is,=20
> > you know that you are talking to whoever/whatever possesses (a copy=20
> > of) the private key corresponding to the public key that=20
> you are using a reference.
> >=20
> > Punch line:  Let's make sure that *someone* (multi6?)=20
> provides plain=20
> > B, too.
>=20
> The trouble I have with this classification to A and B is=20
> that I'm not sure anyone is providing, or can provide just B.=20
> There seems to be a need to ensure a cryptographic binding so=20
> that no vulnerabilities are opened by B. The strength of that=20
> binding may vary, perhaps, and it can in some cases be=20
> replaced by an assumption of an ever-present home address and=20
> some additional requirements (as in Mobile IPv6). But my gut=20
> feeling is that B provides most of A too. For instance,=20
> proposed MULTI6 scheme provides a hard binding to a public key.
>=20
> Secondly, I wonder what the value of A is outside its=20
> intrinsic use in B. We have seen that applications in the=20
> Internet mostly use application layer security. Can we loosen=20
> some of the requirements for application layer security by=20
> providing A? As a first answer I would note that even if some=20
> of the underlying security were used, all authorization=20
> questions (a big part of the whole problem) would still be=20
> left for the application.
>=20

Considering A by itself, without coupling with B, if A binds identity=20
to public key, that is what we have today at higher layers, right?
(e.g., certificates).

If the question is whether public-key-based names are useful themselves
as names, outside of the HIP context, I would think probably not,=20
unless we are talking strictly machine-to-machine communication,=20
because humans will almost certainly want to assign human-friendly=20
aliases like URIs to the keys, in which case we are back to the=20
binding again.

Tom

From: [email-masked] (Jari Arkko)
Date: Mon Nov 15 09:57:01 2004
Subject: [Hipsec-rg] A vs. B (Was: Re: [Hipsec] Pekka Nikander's personal view on HIP related discussions at DC)
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Pekka Nikander wrote:

> A and B, or the value of non-secure identifiers
> ===============================================
> 
> Right now, HIP seems to provide two "services" at its core.  It aims to 
> provide identifiers that
>   A. have a cryptographically strong binding to a public key, and
>   B. have a location-independent end-to-end semantics, at the lowest 
> possible layer in the stack.
> 
> There might be some value in separating A and B, and allowing upper 
> layers to select either A+B or just B.  B would provide enough security 
> just to protect innocent bystanders from flooding and other related 
> attacks that might be created by B itself.  A+B, on the other hand, 
> would provide the full package, i.e., that "You know whom you are 
> talking to", where whom is defined by the public key.  That is, you know 
> that you are talking to whoever/whatever possesses (a copy of) the 
> private key corresponding to the public key that you are using a reference.
> 
> Punch line:  Let's make sure that *someone* (multi6?) provides plain B, 
> too.

The trouble I have with this classification to A and B is that
I'm not sure anyone is providing, or can provide just B. There
seems to be a need to ensure a cryptographic binding so that no
vulnerabilities are opened by B. The strength of that binding
may vary, perhaps, and it can in some cases be replaced by
an assumption of an ever-present home address and some additional
requirements (as in Mobile IPv6). But my gut feeling is that B
provides most of A too. For instance, proposed MULTI6 scheme
provides a hard binding to a public key.

Secondly, I wonder what the value of A is outside its intrinsic
use in B. We have seen that applications in the Internet
mostly use application layer security. Can we loosen some
of the requirements for application layer security by providing
A? As a first answer I would note that even if some of the
underlying security were used, all authorization questions
(a big part of the whole problem) would still be left for
the application.

--Jari

From: [email-masked] (Pekka Nikander)
Date: Mon Nov 15 05:29:01 2004
Subject: [Hipsec-rg] Pekka Nikander's personal view on HIP related discussions at DC
Message-ID: <[email-masked]>

Folks,

This collection of notes provides a _personal_ point of view to the 
discussions that I participated to during the DC meeting.  Most 
probably contains some controversial issues; if you want to discuss 
those, PLEASE DO START A NEW THREAD and make sure that you redirect 
your responses to the appropriate list, either WG or RG.  Thank you for 
keeping the mailing list discussions organised.

Outline/Summary
===============

- A lowest location-independent layer of identification
- A and B, or the value of non-secure identifiers
- What is core HIP?
- DNS semantics
- PATH, or HIP NAT traversal
- Extending the idea of locator
- Separation of signalling and data

A lowest location-independent layer of identification
=====================================================

In the good olde days, it was possible to use IPv4 addresses as 
universal identifiers for reaching *any* host in the Internet.  As 
argued in more detail in the architecture document, this had a great 
value, just as such.  Furthermore, this value has now been lost by the 
introduction of NATs, firewalls, IPv4 and IPv6 in parallel, mobility, 
address-based multi-homing, and a plethora of other things that break 
the "end-to-end", in some sense.

Currently, people are trying to fix the situation by introducing new 
location-independent name spaces.  Today, SIP identifiers are probably 
the most prominent example of this.  However, these new identifiers 
tend to be located at the application layer, and tend to be, at least 
to an extent, application specific.

If we could engineer and *deploy* a new *lowest* layer that provides 
universal, location-independent identifiers, that might re-establish 
the end-to-end connectivity that we used to have.  While SIP provides 
such a service in a limited way, it might not be at the right place in 
the stack.  On the other hand, there seems to be more momentum 
currently behind SIP, and in the usual Betamax vs. VHS fashion, SIP may 
be good enough so that few if any people bother even to try HIP.

Punch line:  Let's make HIP to go through current middle boxes at least 
as well as SIP does!

A and B, or the value of non-secure identifiers
===============================================

Right now, HIP seems to provide two "services" at its core.  It aims to 
provide identifiers that
   A. have a cryptographically strong binding to a public key, and
   B. have a location-independent end-to-end semantics, at the lowest 
possible layer in the stack.

There might be some value in separating A and B, and allowing upper 
layers to select either A+B or just B.  B would provide enough security 
just to protect innocent bystanders from flooding and other related 
attacks that might be created by B itself.  A+B, on the other hand, 
would provide the full package, i.e., that "You know whom you are 
talking to", where whom is defined by the public key.  That is, you 
know that you are talking to whoever/whatever possesses (a copy of) the 
private key corresponding to the public key that you are using a 
reference.

Punch line:  Let's make sure that *someone* (multi6?) provides plain B, 
too.

What is core HIP?
=================

An important question raised on Saturday's workshop was that of what is 
"core" to HIP?  In a way, this was a reaction to people using the term 
"HIP" to denote anything that is taking place at the working or 
research groups.  That seems to be confusing.  Hence, we should define 
in specific terms what are the fundamental properties of HIP and what 
are features that are build on the top of that.

As a starting point, I would propose the following:

   - A+B, from above, is core

   - being the *lowest* location-independent layer is core

   - the *idea* of location-independence (such as in middle box
     traversal) is core
     - the specific mechanisms for traversing specific middle
       boxes are NOT core

   - the *idea* of location-independence (such as in mobility)
     is core
     - mobility and multi-homing, as defined in the mobility
      and multi-homing draft, are NOT core

   - even the idea of rendezvous is NOT core but just as
     something that is needed for location-independence

The fact that HIP will eventually require us to reconsider the 
placement of various functions, such as congestion control, in the 
stack, is a feature and not a bug.  Hence, it is a direct consequence 
of what is core to HIP.

Punch line: Use "lowest location-independent" as Occam's razor!

DNS semantics
=============

Today, a (leaf) DNS name defines a service, not a host.  In many cases, 
the same service is provided by many hosts.  The current practise is to 
list the IP addresses of all of the hosts providing to that service 
under the given DNS name.  This is the semantics that HIP must conform 
to.

There is a separate thread on this on the WG mailing list, so no more 
on this here.

Punch line: Don't tell me what to put in my DNS!

Preferred Alternatives to Tunnelling HIP (PATH)
===============================================

I have changed my mind on HIP legacy NAT traversal.  Two years ago I 
opposed it on architectural bases.  A year ago I would not have done it 
myself but didn't oppose it any more.  Now I am doing it.

To make HIP the lowest location-independent layer in today's networks, 
we must make HIP to go through current NATs and firewalls.  While 
making pinholes through firewalls seems like an arms race, there is no 
question in the value of making HIP to go through current "convenience" 
NATs.  Those NATs are primarily there to solve the address space 
problem, and there are a hoard of applications that already make it 
possible to open a connection to a host behind a firewall.  STUN, ICE 
and other specifications already define how you should do that, for 
your application.  Let's make this application independent, allowing 
you to use both existing and future applications without having to 
worry about NATs.

Given that we can directly employ the mechanisms in STUN and ICE, this 
seems to be a relatively easy piece of work, now.  That might not have 
been the case two years ago.  In the future, we can probably lean even 
more to the work in produced by the BEHAVE and other working groups, 
without spending too much cycles on making this clean and mean.

Basically, we agreed to write two drafts:

   1. Packet formats for HIP over UDP and UDP as locator.

   2. A document specifying a STUN-server like HIP rendezvous server, 
and the protocols that you use to register to the server and making HIP 
connections to the host behind the NAT with the help of such a server.

Both documents should be relatively short, as they can mostly rely on 
work done elsewhere.

Punch line: Make UDP based NAT traversal a trivial combination of 
methods developed elsewhere.

What is a locator?
==================

As a starting point, HIP was designed to function on the top of the two 
versions of IP, providing connectivity over both of them.  
Unfortunately, IPv4 does not provide end-to-end connectivity today.  
Instead, one must use various kinds of hacks, like tunnelling other 
protocols on the top of UDP.

To keep the HIP architecture relatively clean, it looks preferable to 
model all the different means of providing end-to-end connectivity as 
locators.  That is, whenever there is an "address", i.e. a piece of 
information that allows one to make a connection, this is modelled as a 
locator.

The first such locator type to be defined would be for HIP-over-UDP 
tunnelling.  Basically, this requires one to convey information about 
IP addresses and UDP ports, and their usage; should a given port be 
used for HIP traffic, for ESP traffic, or for both?  If the latter, how 
exactly one should determine whether a received packet is a HIP or an 
ESP packet?

Hence, to me it looks like that we want to generalise the notion of 
locator, making HIP an universal non-tunnelling tunnelling protocol.  
That is, providing HIP with the generic hooks that allow HIP to 
traverse all the imaginable kinds of protocols, providing the "HIP 
connectivity service" on the top of that.  Note that while we use here 
tunnelling like mechanisms, this is not really tunnelling in the sense 
that we are providing something more than what is available below the 
tunnel, the A+B property from above, and we also provide the property 
of mobility across these various tunnelling methods.

As a result, I think that we should define an extensible locator data 
type, to be used the REA payload.  Additionally, it *might* make sense 
to define a new DNS resource record that allows one to store these 
additional locators into the DNS.  OTOH, my current feeling is that it 
is too early to propose the new DNS resource record.  We might as well 
try to get some operational experience with rendezvous and mobility 
based NAT traversal mechanisms first.

Punch line: HIP over Anything and Everything (HAE)

Separation of signalling and data
=================================

The way HIP is currently defined provide a convenient way of separating 
signalling and data traffic.  Basically, host-to-host signalling 
traffic is carried within the HIP protocol while data traffic is 
carried within the ESP protocol.  In the future, I surmise that we will 
support other data protocols but ESP, too.

As we now aim to support legacy NAT traversal, we probably need to 
provide some more flexibility on this.  For example, we may want to 
provide one UDP port for HIP traffic while using another one for ESP 
traffic.  More generally, we may want to express that one particular 
locator is only valid for HIP traffic while the other locator may be 
used for ESP traffic.  Even more generally, we probably want to add 
capabilities to locators, allowing us to express explicitly what each 
locator is good for.

The telecom people will love this, I am sure.  Finally they can 
understand TCP/IP, at least when HIP is used :-)

Punch line:  Let's make HIP appealing both to Internet and Telecom 
folks :-)

--Pekka

From: [email-masked] (Henderson, Thomas R)
Date: Sun Nov 14 21:25:00 2004
Subject: [Hipsec-rg] Draft of hiprg meeting minutes
Message-ID: <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C4CAC4.68F31260
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Attached are the minutes from Friday's meeting.  Please send
any corrections to the list.

Tom

------_=_NextPart_001_01C4CAC4.68F31260
Content-Type: text/plain;
	name="hiprg_minutes.txt"
Content-Transfer-Encoding: base64
Content-Description: hiprg_minutes.txt
Content-Disposition: attachment;
	filename="hiprg_minutes.txt"

------_=_NextPart_001_01C4CAC4.68F31260--

From: [email-masked] (Brian E Carpenter)
Date: Tue Nov  9 18:10:03 2004
Subject: [Hipsec-rg] Re: A lowest layer with location independent identifiers with more than one protocols
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> Indeed, I think that designing such a
> protocol would be quite an interesting thing.  More generally, it
> looks that we need to redesign the stack from roughly middle of
> layer 3 to the socket API.  Such redesign is likely to involve
> more than just adding a new layer 3.5 or 4.5. 

Interesting indeed, but way out of scope for multi6.

    Brian

Pekka Nikander wrote:
>>> Firstly, it was determined that there seems to be some value of
>>> providing
>>>
>>>   "a lowest layer that supports location independent identifiers"
>>
>>
>> Could you explain a little bit more what you mean by this?  Lowest layer
>> of what & what value is there?  Do you mean a lowest layer 3.5?
> 
> 
> Well, it was really John Wroclawski who made the statement, but
> I'll try to explain how I understood it.
> 
> In the good old days, i.e. before NATs, firewalls, and mobility,
> when you had an IP address you could hand it around and know that
> you can make a connection to that host without too much worries.
> As we know well, that was all broken by NATs, firewalls, mobility,
> etc.
> 
> Today, we have a number of layers where you do have identifiers
> that still have the property that you can hand them around and get
> your communication done.  E-mail addresses and SIP URLs are good
> examples.  But they are application level entities, not lower in
> the stack.
> 
> Now, if we had somewhere down the stack a layer with identifiers
> that you can hand around and use independent of your own current
> location in the network and the other node's current location,
> that would have some value.  In more practical terms, that means
> that the layer would need to support mobility, multi-homing, middle
> box traversal including legacy NATs and future architected middle
> boxes, and probably some amount of security awareness to allow
> authorised firewall traversal.
> 
> I am not saying that layer 3.5 is necessarily the right place
> for this.  There are many reasons why layer 4.5 or even 5 _might_
> be more appropriate.  On the other hand, having the functionality
> below the socket API might have some value from the point of view
> of better supporting legacy applications.  But you could probably
> implement things also at layer 4.5 and still make it to support
> the current socket API.  Indeed, I think that designing such a
> protocol would be quite an interesting thing.  More generally, it
> looks that we need to redesign the stack from roughly middle of
> layer 3 to the socket API.  Such redesign is likely to involve
> more than just adding a new layer 3.5 or 4.5.
> 
>>> Secondly, some people expressed their discomfort with the HIP approach
>>> of combining identifiers and security.  Ion Stoica and Scott Shenker
>>> put it out nicely, saying that HIP provides
>>>
>>>    A.  A mapping from a public key to an identifier, and
>>>    B.  A mapping from an identifier to a set of locators
>>>
>>> Based on this observation, we came to an analogy.  Consider the case
>>> with current TCP and UDP.  They are on the same layer, and provide the
>>> same kind of *identifier* abstraction.  However, they provide different
>>> communication semantics.  In a way, one could perhaps characterise that
>>> "UDP is TCP without congestion control".  (I know, that is not quite
>>> true, but I wish you get the point.)
>>
>>
>> I get this point, but you should at least add that different protocols
>> use different transport protocols because these transport protocols
>> provide different services.
> 
> 
> Right.  That is exactly the point.  Some protocols might want to
> have B but not A, for example, because they rely on other security
> measures and would not get any value from A.
> 
>>> In the same way, there might be value to have more than one protocols
>>> at the "lowest layer that supports location independent identifiers".
>>
>>
>> This might be useful, but you should be mindful that [the different
>> protocols], then, could potentially provide different services to
>> the protocols that run on top of them.  The reasons for [selecting
>> to use a specific protocol], then, could be based upon the services
>> provided.
> 
> 
> If generalised as I suggest to interpret your words above, I fully
> concur.
> 
> --Pekka Nikander
> 
> 

From: [email-masked] ([email-masked])
Date: Tue Nov  9 18:10:01 2004
Subject: [Hipsec-rg] RE: A lowest layer with location independent identifiers with more than one protocols
Message-ID: <[email-masked]>

Pekka,

> Firstly, it was determined that there seems to be some value of=20
> providing
>=20
>   "a lowest layer that supports location independent identifiers"

Could you explain a little bit more what you mean by this?  Lowest layer
of what & what value is there?  Do you mean a lowest layer 3.5? =20
=20
> In a way, that seems to be exactly what multi6 is trying to provide.
>=20
> Secondly, some people expressed their discomfort with the HIP approach
> of combining identifiers and security.  Ion Stoica and Scott Shenker
> put it out nicely, saying that HIP provides
>=20
>    A.  A mapping from a public key to an identifier, and
>    B.  A mapping from an identifier to a set of locators
>=20
> Based on this observation, we came to an analogy.  Consider the case
> with current TCP and UDP.  They are on the same layer, and provide the
> same kind of *identifier* abstraction.  However, they provide =
different
> communication semantics.  In a way, one could perhaps characterise =
that
> "UDP is TCP without congestion control".  (I know, that is not quite=20
> true, but I wish you get the point.)

I get this point, but you should at least add that different protocols=20
use different transport protocols because these transport protocols
provide different services. =20
=20
> In the same way, there might be value to have more than one protocols
> at the "lowest layer that supports location independent identifiers".
> These multiple protocols would all provide the same kind of =
*identifier*
> abstraction, but different semantics.  One of the protocols might be
> HIP, with both A and B.  Another protocol might be something else, =
maybe
> with just B without A.  That might be what multi6 is aiming for.

This might be useful, but you should be mindful that HIP and Multi6, =
then,
could potentially provide different services to the protocols that run
on top of them.  The reasons for using HIP vs. Multi6, then, could be
based upon the services provided.

John

From: [email-masked] (Pekka Nikander)
Date: Mon Nov  8 18:47:00 2004
Subject: [Hipsec-rg] Re: A lowest layer with location independent identifiers with more than one protocols
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

>> Firstly, it was determined that there seems to be some value of
>> providing
>>
>>   "a lowest layer that supports location independent identifiers"
>
> Could you explain a little bit more what you mean by this?  Lowest 
> layer
> of what & what value is there?  Do you mean a lowest layer 3.5?

Well, it was really John Wroclawski who made the statement, but
I'll try to explain how I understood it.

In the good old days, i.e. before NATs, firewalls, and mobility,
when you had an IP address you could hand it around and know that
you can make a connection to that host without too much worries.
As we know well, that was all broken by NATs, firewalls, mobility,
etc.

Today, we have a number of layers where you do have identifiers
that still have the property that you can hand them around and get
your communication done.  E-mail addresses and SIP URLs are good
examples.  But they are application level entities, not lower in
the stack.

Now, if we had somewhere down the stack a layer with identifiers
that you can hand around and use independent of your own current
location in the network and the other node's current location,
that would have some value.  In more practical terms, that means
that the layer would need to support mobility, multi-homing, middle
box traversal including legacy NATs and future architected middle
boxes, and probably some amount of security awareness to allow
authorised firewall traversal.

I am not saying that layer 3.5 is necessarily the right place
for this.  There are many reasons why layer 4.5 or even 5 _might_
be more appropriate.  On the other hand, having the functionality
below the socket API might have some value from the point of view
of better supporting legacy applications.  But you could probably
implement things also at layer 4.5 and still make it to support
the current socket API.  Indeed, I think that designing such a
protocol would be quite an interesting thing.  More generally, it
looks that we need to redesign the stack from roughly middle of
layer 3 to the socket API.  Such redesign is likely to involve
more than just adding a new layer 3.5 or 4.5.

>> Secondly, some people expressed their discomfort with the HIP approach
>> of combining identifiers and security.  Ion Stoica and Scott Shenker
>> put it out nicely, saying that HIP provides
>>
>>    A.  A mapping from a public key to an identifier, and
>>    B.  A mapping from an identifier to a set of locators
>>
>> Based on this observation, we came to an analogy.  Consider the case
>> with current TCP and UDP.  They are on the same layer, and provide the
>> same kind of *identifier* abstraction.  However, they provide 
>> different
>> communication semantics.  In a way, one could perhaps characterise 
>> that
>> "UDP is TCP without congestion control".  (I know, that is not quite
>> true, but I wish you get the point.)
>
> I get this point, but you should at least add that different protocols
> use different transport protocols because these transport protocols
> provide different services.

Right.  That is exactly the point.  Some protocols might want to
have B but not A, for example, because they rely on other security
measures and would not get any value from A.

>> In the same way, there might be value to have more than one protocols
>> at the "lowest layer that supports location independent identifiers".
>
> This might be useful, but you should be mindful that [the different
> protocols], then, could potentially provide different services to
> the protocols that run on top of them.  The reasons for [selecting
> to use a specific protocol], then, could be based upon the services
> provided.

If generalised as I suggest to interpret your words above, I fully
concur.

--Pekka Nikander

From: [email-masked] (Henderson, Thomas R)
Date: Mon Nov  8 16:23:01 2004
Subject: [Hipsec-rg] A lowest layer with location independent identifiers with more than one protocols
Message-ID: <[email-masked]>

=20

>=20
> My point is that the difficulties with mobility support are=20
> not strictly related with using routable addresses as ULPID=20
> but with using HBAs

OK, agreed-- I was not thinking of the CGA/HBA combined example.

>=20
> also note that HBAs and cga approaches are compatible so you=20
> can use HBAs when no mobility support is required and use=20
> CGAs when you need mobility support. Moreover, as HBAs are=20
> defines as a CGA extension, you can have both capabilities=20
> simoultaneously available in a single address and use HBA=20
> capabilities when not moving and use CGA capabilities when moving.
>=20

So it does then seem that HBA + CGA provides the A/B
functionality discussed at the workshop, with certain security
and mobility protections on these mappings.  =20
>
>    A.  A mapping from a public key to an identifier, and
>    B.  A mapping from an identifier to a set of locators

So maybe, to return to Pekka's original point, multi6 may be
aiming for B without A (HBA), but may be able to also get A=20
under certain circumstances as well (CGA/HBA)?

Thanks for clarifying,=20
Tom

From: [email-masked] (marcelo bagnulo braun)
Date: Mon Nov  8 15:22:02 2004
Subject: [Hipsec-rg] A lowest layer with location independent identifiers with more than one protocols
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

El 08/11/2004, a las 22:25, Henderson, Thomas R escribi=F3:

>
> Maybe that was poor terminology on my part, but what I meant was
> that the identifier generated in hash based addresses is
> dependent on the a priori knowledge of the multiple prefixes
> and doesn't cover a new prefix that one might acquire through
> mobility.  Please clarify if I misunderstood how it works.

Your understanding is correct AFAICT
And i agree that this is problematic for supporting mobility
but also note that you can use CGA instead of HBAs, in which case, i=20
guess that mobility is properly supported.
I mean, HBAs provide a more cost efficient option, but with=20
restrictions as you well note, but a cga approach to multi6 provides=20
routable ULPIDs while supporting mobility properly

My point is that the difficulties with mobility support are not=20
strictly related with using routable addresses as ULPID but with using=20=

HBAs

also note that HBAs and cga approaches are compatible so you can use=20
HBAs when no mobility support is required and use CGAs when you need=20
mobility support. Moreover, as HBAs are defines as a CGA extension, you=20=

can have both capabilities simoultaneously available in a single=20
address and use HBA capabilities when not moving and use CGA=20
capabilities when moving.

regards, marcelo

> It was not to say that you couldn't use other techniques such
> as mobile IP in conjunction with hash based addresses.
>
> Tom
>
>
------------------------------------------
Please note that my former email address
[email-masked] is no longer in use
Please send mail to:
marcelo at it dot uc3m dot es
------------------------------------------

From: [email-masked] (Henderson, Thomas R)
Date: Mon Nov  8 15:15:01 2004
Subject: [Hipsec-rg] A lowest layer with location independent identifiers with more than one protocols
Message-ID: <[email-masked]>

=20

> -----Original Message-----
> From: marcelo bagnulo braun [mailto:[email-masked]]=20
> Sent: Monday, November 08, 2004 3:34 PM
> To: Henderson, Thomas R
> Cc: [email-masked]; Pekka Nikander
> Subject: Re: [Hipsec-rg] A lowest layer with location=20
> independent identifiers with more than one protocols
>=20
> Hi Tom,
>=20
> a clarification request...
> >
>=20
> > If you consider mobile IP home address as location independent=20
> > identifier (in some sense), I would argue that we are=20
> already at the=20
> > point where we have multiple protocols and multiple=20
> semantics, but is=20
> > presently implicit and hidden from the applications.  The multi6-dt=20
> > identifiers and MIP home addresses are *partially* location=20
> > independent.  By not making them fully location independent, some=20
> > benefits arise-- namely, less need to change the upper=20
> layers of the=20
> > stack that might implicitly assume in many cases that the=20
> identifier=20
> > serves as a locator.
> > However, they have some limitations from that feature as well--=20
> > multi6-dt identifiers are not mobility friendly,
>=20
>=20
> what do you mean by not being mobility friendly?
> or of you like, how would an identifier by mobility friendly?
>=20
> thanks, marcelo
>=20

Maybe that was poor terminology on my part, but what I meant was
that the identifier generated in hash based addresses is=20
dependent on the a priori knowledge of the multiple prefixes
and doesn't cover a new prefix that one might acquire through
mobility.  Please clarify if I misunderstood how it works.
It was not to say that you couldn't use other techniques such
as mobile IP in conjunction with hash based addresses.

Tom

From: [email-masked] (marcelo bagnulo braun)
Date: Mon Nov  8 14:22:02 2004
Subject: [Hipsec-rg] A lowest layer with location independent identifiers with more than one protocols
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <75A0514C-31C5-11D9-8179-000D93ACD0FE@it>

Hi Tom,

a clarification request...
>

> If you consider mobile IP home address as location independent
> identifier (in some sense), I would argue that we are already
> at the point where we have multiple protocols and multiple
> semantics, but is presently implicit and hidden from the
> applications.  The multi6-dt identifiers and MIP home addresses
> are *partially* location independent.  By not making them fully
> location independent, some benefits arise-- namely, less need
> to change the upper layers of the stack that might implicitly
> assume in many cases that the identifier serves as a locator.
> However, they have some limitations from that feature as well--
> multi6-dt identifiers are not mobility friendly,

what do you mean by not being mobility friendly?
or of you like, how would an identifier by mobility friendly?

thanks, marcelo

>  and mobile IP
> has some home network dependencies and middlebox implications.
>
> I agree with considering the splitting of A and B, and that
> in so doing, the use of some identifiers might not allow for
> the use of certain features (e.g., network-layer transparent
> mobility).  To me, this has the implication of hoisting
> more decisions (semantics) on the upper-layer protocols based
> on identifier types and/or protocols that are selected.  In HIP
> so far, we have been trying to hide all of this in the interests
> of backward compatibility (e.g. spoofing of DNS resolutions,
> etc.) but maybe that is not the right mindset for this problem.
> Perhaps it may provide a better path forward for deployment if
> we can generalize the approach so that all of these protocols
> (mobile IP, multi6, i3, etc.) that are struggling to fix the
> overloading of IP address as locator and identifier can fit
> within a common framework.
>
> I also think that we need to articulate better the reasons for
> building in forward-compatibility for completely location
> independent identifiers at layer 3.5.
>
> Tom
> _______________________________________________
> Hipsec-rg mailing list
> [email-masked]
> http://honor.trusecure.com/mailman/listinfo/hipsec-rg
>
>
------------------------------------------
Please note that my former email address
[email-masked] is no longer in use
Please send mail to:
marcelo at it dot uc3m dot es
------------------------------------------

From: [email-masked] (Henderson, Thomas R)
Date: Mon Nov  8 10:29:01 2004
Subject: [Hipsec-rg] A lowest layer with location independent identifiers with more than one protocols
Message-ID: <[email-masked]>

 (replying only to hipsec-rg)

> -----Original Message-----
> From: Pekka Nikander [mailto:[email-masked]]=20
> Sent: Monday, November 08, 2004 10:46 AM
> To: [email-masked]
> Cc: Multi6 List
> Subject: [Hipsec-rg] A lowest layer with location independent=20
> identifiers with more than one protocols
>=20
> [Replies directed to hipsec-rg, be careful.]
>=20
> As some of you may know, we had a workshop on "HIP and=20
> Related Architectures" on Saturday.  There were a number=20
> of conclusions from the workshop; they will be presented at=20
> the HIP RG=20
> on Saturday.
     ^^^^^^^^
     Friday.

>=20
> Secondly, some people expressed their discomfort with the HIP=20
> approach of combining identifiers and security.  Ion Stoica=20
> and Scott Shenker put it out nicely, saying that HIP provides
>=20
>    A.  A mapping from a public key to an identifier, and
>    B.  A mapping from an identifier to a set of locators

To clarify, I do not think that there was discomfort with how
HIP does this, but discomfort in restricting it to only the way
that HIP does it and in only using public keys as these location
independent identifiers.  (That is, HIP binds A and B but it need=20
not necessarily be so).

>=20
> Based on this observation, we came to an analogy.  Consider=20
> the case with current TCP and UDP.  They are on the same=20
> layer, and provide the same kind of *identifier* abstraction.=20
>  However, they provide different communication semantics.  In=20
> a way, one could perhaps characterise that "UDP is TCP=20
> without congestion control".  (I know, that is not quite=20
> true, but I wish you get the point.)

I am not sure that I agree or understand the analogy, because
I don't see these protocols providing identifier abstraction.

>=20
> In the same way, there might be value to have more than one=20
> protocols at the "lowest layer that supports location=20
> independent identifiers".
> These multiple protocols would all provide the same kind of=20
> *identifier* abstraction, but different semantics.  One of=20
> the protocols might be HIP, with both A and B.  Another=20
> protocol might be something else, maybe with just B without=20
> A.  That might be what multi6 is aiming for.
>=20

If you consider mobile IP home address as location independent
identifier (in some sense), I would argue that we are already
at the point where we have multiple protocols and multiple=20
semantics, but is presently implicit and hidden from the
applications.  The multi6-dt identifiers and MIP home addresses
are *partially* location independent.  By not making them fully
location independent, some benefits arise-- namely, less need
to change the upper layers of the stack that might implicitly
assume in many cases that the identifier serves as a locator.
However, they have some limitations from that feature as well--
multi6-dt identifiers are not mobility friendly, and mobile IP
has some home network dependencies and middlebox implications.

I agree with considering the splitting of A and B, and that
in so doing, the use of some identifiers might not allow for
the use of certain features (e.g., network-layer transparent
mobility).  To me, this has the implication of hoisting
more decisions (semantics) on the upper-layer protocols based
on identifier types and/or protocols that are selected.  In HIP
so far, we have been trying to hide all of this in the interests
of backward compatibility (e.g. spoofing of DNS resolutions,
etc.) but maybe that is not the right mindset for this problem.
Perhaps it may provide a better path forward for deployment if=20
we can generalize the approach so that all of these protocols=20
(mobile IP, multi6, i3, etc.) that are struggling to fix the=20
overloading of IP address as locator and identifier can fit
within a common framework.

I also think that we need to articulate better the reasons for
building in forward-compatibility for completely location
independent identifiers at layer 3.5. =20

Tom

From: [email-masked] (Pekka Nikander)
Date: Mon Nov  1 06:02:01 2004
Subject: [Hipsec-rg] HIPRG agenda for IETF61 at Washington, D.C.
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

HIP research group (hiprg)

Friday, November 12 at 1300-1530
================================

CHAIRS: Tom Henderson <[email-masked]>
         Pekka Nikander <[email-masked]>

AGENDA:

  5 min  Agenda bashing
  5 min  RG status update
20 min  Report from HIP and Related Architectures workshop

15 min  HIP Resolution and Rendezvous Problem Description
         - draft-eggert-hiprg-rr-prob-desc-00.txt
15 min  NAT and Firewall Traversal for HIP
         - draft-tschofenig-hiprg-hip-natfw-traversal-00.txt
15 min  Exchanging Host Identities in SIP
         - draft-tschofenig-hiprg-host-identities-00.txt

15 min  HIP Experiment Report
         - draft-irtf-hip-experiment-00.txt
30 min  Open mike discussion on HIP deployment

From: [email-masked] (Joseph So)
Date: Mon Nov  1 04:24:01 2004
Subject: [Hipsec-rg] 128bit LSI -- why?
Message-ID: <[email-masked]>

Dear All,
  I found that in the new ID (draft-ietf-hip-base-01), a 128 bits LSI is
introduced.  In my understanding, 32bits LSI is used in the IPv4 headers to
replace IP4 addresses. HIT is already 128bits and can be used in the IPv6
Header. What is the purpose of the 128bits LSI?
Yours,
Joseph

-- 
NEU +++ DSL Komplett von GMX +++ http://www.gmx.net/de/go/dsl
GMX DSL-Netzanschluss + Tarif zum supergünstigen Komplett-Preis!