Subject: [Hipsec] Overlay work: status and request for input

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 20 Jul 2009 13:33:00 +0300

Folks,

here you have a summary of the status of the overlay work.
Additionally, we have some questions for the WG related to our
milestones and their related charter items. Your input on those
questions is very welcome.

1) We have the following milestone:

"Specify a framework to build HIP-based overlays. This framework will
describe how HIP can perform some of the tasks needed to build an
overlay and how technologies developed somewhere else (e.g., a peer
protocol developed in the P2PSIP WG) can complement HIP by performing
the tasks HIP was not designed to perform."

The WG item for this milestone is the following draft, which should be
ready for WGLC:

http://tools.ietf.org/id/draft-ietf-hip-bone-02.txt

This draft defines a high-level framework to build HIP-based overlays.
Additionally, its previous version defined how to build a HIP-based
overlay using RELOAD. The authors have chosen to move this definition to
a separate document because while the high-level framework is
informational in nature, the definition makes use of normative language.
The resulting document is the draft below. We would like to ask the WG
if it is OK to split our current milestone in two so that they cover the
high-level framework and the definition in separate documents.

http://tools.ietf.org/internet-drafts/draft-keranen-hip-reload-instance-00.txt

Additionally, we would like to ask the WG if we should take the draft
above as the WG item associated to the milestone for the definition.

2) We have the following milestone:

"Specify how to carry upper-layer data over specified HIP
packets. These include some of the existing HIP packets and possibly
new HIP packets (e.g., a HIP packet that occurs outside a HIP base
exchange)."

We still do not have a WG item for it but the following draft has been
around for some time. We would like to ask the WG if we should adopt the
following draft as the WG item for this milestone.

http://tools.ietf.org/internet-drafts/draft-nikander-hip-hiccups-02.txt

Revision 02 of the draft above is identical to 01 (the only changes are
the date and the new copyright). The authors intend to address the
comments received on the list shortly.

3) In order to be able to support the functionality provided by RELOAD,
HIP needs to support multi-hop routing. Instead of specifying it in the
HIP BONE draft, having a separate draft seem to make more sense given
that this functionality has a more general applicability than overlays.
We would like to ask the WG if we should spin off a new milestone from
our original milestone for overlays that covers multihop routing in HIP.

The following draft takes a stab at specifying multihop routing in HIP.
We would like to ask the WG if we should adopt it as a WG item for the
milestone above (assuming we decide to create the milestone).

http://tools.ietf.org/internet-drafts/draft-camarillo-hip-via-00.txt

4) We have the following milestone:

"Specify how to generate ORCHIDs from other node identifiers
including both cryptographic ones (leading to cryptographic
delegation) and non-cryptographic ones (e.g., identifiers defined by a
peer protocol)."

When we created that milestone, we expected to have a generic mechanism
to transform node IDs into ORCHIDs. However, at this point, it seems
that such transformation will be done in different ways depending on the
peer protocol used in a particular overlay. For example, the instance
specification for RELOAD draft defines such transformation for RELOAD
peer identifiers. The fact that nobody has submitted a draft for that
milestone seems to confirm the previous impression. We would like to ask
the WG if we should remove that milestone from our charter.

Thanks,

Gonzalo
HIP co-chair

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Mon, 20 Jul 2009 22:09:32 -0700

Gonzalo, below I've expressed my (somewhat negative, sorry) opinions on
your questions: 

> -----Original Message-----
> From: Gonzalo Camarillo [mailto:[email-masked]] 
> Sent: Monday, July 20, 2009 3:33 AM
> To: HIP
> Subject: [Hipsec] Overlay work: status and request for input
> 
> Folks,
> 

I remain very uneasy about the above draft, which I think is not very
clear and skirts over some hard issues.

The document tries to provide a generalized framework for HIP-based
overlays, but it is not clear how it will work when there are multiple
peer protocols (multiple overlays) and when the peer IDs are not the
same as the node IDs.  The specific instance draft does not handle these
issues; it assumes that the peer ID is the ORCHID (which was not
acceptable to some in the P2PSIP WG due to possible chosen ID attacks),
and is, of course, only one instance.

In general, I recommend not trying to complete work on a framework for
multiple overlays until there is an example of at least how two
independent overlays (perhaps with different peer protocols and
different peer ID structures) coexists on some of the same nodes, and
the peer IDs are not HITs.  

The draft states:
"Since HIP needs
ORCHIDs (and not any type of Peer ID) to work, hosts in the overlay
will transform their Peer IDs into ORCHIDs, for example, by taking a
hash of the Peer IDs or taking a hash of the Peer ID and the public
key."

I don't see how this would work since for an ORCHID to be used as a HIT,
it must hash a public key.

It is not clear from the document what IDs are being routed if the peer
ID is not the same as the HIT.  I think the answer is that it is the
peer IDs that are being routed, and HIP is just providing the links
between the peer IDs.  It may be that the peer IDs are the same as HITs
in some instances, but it should be architecturally clear that transport
connections are being terminated at each hop in the overlay.

If the document were to describe an overlay architecture where you
recommend to the peer protocols "Use HITs like you would otherwise use
IP addresses, and HIP will take care of the rest of the ugly business of
NAT traversal, mobility, and multihoming," then it would seem to be
relatively straightforward, so long as HIP took it upon itself with no
dependency on the peer protocol to do anything for it.

Where I think it becomes conflated, however, is when you try to use the
overlay to forward HIP signaling traffic.  I see why you are trying to
do this but it leads to these questions:

1) the overlay may stitch together addressing realms that have no hope
of supporting end-to-end HIP associations between them.  For instance,
this simple topology:

node A <--------Ipv4 network -----> node B <--------Ipv6 network
---------> node C

The overlay may route the I1 from node A to node C and R1 back, but no
HIP association between A and C can actually be formed.

2) what if node B above belongs to multiple other HIP-based overlays?
How does it know on which overlay to forward the I1?

Also, from a performance perspective, I think there may be some danger
in abstracting the underlying topology away from a peer protocol.  From
the peer protocol layer perspective, HIP makes every node look like it
is "on link" whereas in fact, each node is possibly different number of
hops away, in different administrative domains of the network, etc.

To summarize, I think there is some value in defining how P2PSIP-based
overlay could use HIP to form its links and deal with NAT, mobility, and
multihoming.  However, before allowing RELOAD nodes to perform the HIP
distributed rendezvous service, I would first define:
1) how the system works in the case where the enrollment server chooses
PeerIds that are not HITs
2) how two such independent overlays (run by different organizations)
could operate on the same node, and how the node would ensure that
messages got onto the right overlays

The above can all be done by assuming that HIP rendezvous is done in the
underlay, not overlay.  As a final step, one might consider whether one
of these overlays itself could be leveraged to forward HIP traffic.  If
all of this holds together, then I think we might have a framework
document that completes the charter item.

As an editorial note, I also would recommend skipping section 2 because
RFC 4423 and other documents are available to provide HIP tutorials.

> above as the WG item associated to the milestone for the definition.

I think it is good to split framework from instance documents.  I might
suggest that Delay Tolerant Networks (DTN) be another instance document.

> comments received on the list shortly.

In January I made a number of comments that the semantics for this new
service were not very clear.  I still would like to understand the
service semantics and requirements; could they be stated clearly
somewhere?  I am not really questioning that such a need for HIP DATA
might exist, but it seems premature to specify message syntax for these
packets when there is no implementation that implements it and no API
for HIP-aware applications to access this service.  How can we build
interoperable implementations without this?

> http://tools.ietf.org/internet-drafts/draft-camarillo-hip-via-00.txt

I'm fine with your suggestion. 

> the WG if we should remove that milestone from our charter.

(note:  the charter seems to now be missing from
http://www.ietf.org/dyn/wg/charter/hip-charter.html)

RFC4843 already specifies how to generate ORCHIDs from other node
identifiers.  If they are unique, they can serve as the Input in the
ORCHID algorithm.  But they cannot be used as HITs.  Was that the intent
of the charter item, to allow non-HIT ORCHIDs to serve the role as HITs
in the protocol?  (See above discussion about overlays)

I think the interesting question is how to bind other node identifiers
that are not public keys to HIP's public keys.  I have been assuming
that certificates and HIP-CERT are the answer there.  At least, that has
been the direction that we have been interested in at Boeing.

- Tom

---

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 21 Jul 2009 19:32:40 +0300

Hi Tom,

thanks for your feedback. I would like to keep this thread focused on 
our milestones. I will answer your questions about the HIP BONE draft in 
a different thread.

Thanks,

Gonzalo

---

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 21 Jul 2009 20:04:19 +0300

Hi Tom,

> clear and skirts over some hard issues.

we have moved a few things to the RELOAD instance draft, which is still 
very much work in progress (as you can see if you read the draft). Some 
issues will be addressed there. Of course, any general issues belonging 
to the framework should be addresses in this document.

> and is, of course, only one instance.

The framework does not assume that Peer IDs are used at the HIP level. 
It just tells you that depending on the Peer IDs used in your overlay, 
you need to convert them to something HIP can use. Originally, we 
thought of having a draft that described that conversion in general (you 
yourself was working on a similar draft at some point) but now we tend 
to think that this type of conversion is better defined in the instance 
specs.

Regarding the RELOAD instance draft, this is one of the open issues. 
That is, whether we can use RELOAD peer IDs directly or if we need some 
type of transformation (ORCHIDs have a prefix; therefore, there are less 
than 128 bits available).

> the peer IDs are not HITs.  

RELOAD has its own way of identifying particular overlays. Other peer 
protocols may have different ways. Therefore, this does not seem to be a 
framework issue. Each instance draft would need to describe it 
separately... in any case, I agree it is worthwhile talking a bit more 
about this in the framework.

> it must hash a public key.

The text wants to indicate that conversions between Peer IDs and ORCHIDs 
are up to each particular instance specification. I agree removing the 
examples may be a good idea so that they do not mislead readers.

> between the peer IDs.

Yes, routing tables contain Peer IDs.

> It may be that the peer IDs are the same as HITs

Yes, transport connections are between hops in the overlay, as usual.

> do this but it leads to these questions:

we had a lot of discussions in the past about this. There were different 
proposals, one of which proposed the simple use you described above. The 
conclusion was to do what HIP BONE specifies. I do not think it would be 
productive to go through the same discussions again at this point.

> HIP association between A and C can actually be formed.

This is not a problem specific to the use of HIP in the overlay. It is a 
general problem of the overlay, even if it was not using HIP. If no 
direct connections can be formed between nodes in an overlay, the 
overlay will most likely keep on routing stuff through the overlay.

> How does it know on which overlay to forward the I1?

This is one of the open issues of the instance draft. RELOAD has its own 
way to identify different overlays. We need to decide how we want to 
covey that information in an I1.

> hops away, in different administrative domains of the network, etc.

Not really. When HIP is not used, the ICE module takes care of 
establishing those "links". The complexity of connection management is 
abstracted out even when HIP is not used.

> PeerIds that are not HITs

The framework already says this is possible... and the instance draft 
will need to define how that is done for RELOAD, of course.

> messages got onto the right overlays

This will also need to be defined by the instance draft... in any case, 
I agree with you that the framework needs to talk more about this (it 
does not discuss this issue right now).

> document that completes the charter item.

You make valid points above. After addressing your points in a new 
revision of the draft (possibly after more list discussions), I think 
the best way to proceed will be to progress the framework and the 
instance draft together so that they can be reviewed at the same time. 
In that way, it will be clearer for the reviewers.

> RFC 4423 and other documents are available to provide HIP tutorials.

This is the typical comment we often get from HIP experts :o)... 
however, application-layer people really appreciated that part of the 
draft when they read it. Before writing it, we sent them all types of 
links to HIP documents and tutorials but they did not find them useful. 
I actually believe that having that type of tutorial material in the 
draft makes it much easier for application-layer people to understand 
the draft (and eventually decide to use it). So, I strongly suggest to 
keep it in the draft.

Thanks,

Gonzalo

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Thu, 23 Jul 2009 21:56:33 -0700

> productive to go through the same discussions again at this point.

I am not trying to rathole things, I would just like to understand how
it is supposed to work.  Maybe if I sketched out some use cases, you
could suggest how you think it would work.  For instance, consider five
nodes A-E, and two overlays (X.org's overlay, and Q.com's overlay).
Nodes A-D belong to Q.com's overlay, and A and C to X.org's overlay.  

Peer-ID:  X.org-AID             X.org-CID   

Peer-ID:  Q.com-AID  Q.com-BID  Q.com-CID  Q.com-DID

HIT:      A-HIT      B-HIT      C-HIT      D-HIT        E-HIT

IP-addr:  A-IP       B-IP       C-IP       D-IP         E-IP

Case 1:  The overlay process belonging to Q.com on node E wants to join
overlay Q.com.  What assumptions do you make about the bootstrapping
record that Q.com's overlay process must have about well-known, stable
nodes?  Does this bootstrapping record store the tuple {Q.com-AID,
A-HIT, A-IP) or just (Q.com-AID, A-HIT)?

Case 2:  Suppose on node A, the peer protocol on node A for overlay
Q.com decides to initiate a HIP association to node C.  What name does
it use for node C?  Presumably, its peer-id "Q.com-CID".  So, it needs
to discover the C-HIT and ultimately the C-IP.  So, as part of the peer
protocol, it resolves Q.com-CID to C-HIT.  I suppose that it does this
with the existing connections that it has.  Does it also at this time
obtain C-IP?  Next, it issues a connect(HIT) socket call.  What happens
next?  There is an outbound I1 to a HIT.  Does the I1 go to the HIP
routing layer, or does the HIP process try to do a DNS/DHT lookup, or
both?  If there are no such records, how does the I1 propagate through
the Q.com overlay, which is not routing HITs but Peer-IDs?  If you
suggest, as below, that Q.com's overlay name is stored in the I1, how
does this "Q.com" get passed through the socket API so that HIP knows
that the process that used the socket API to connect(HIT) was associated
with Q.com?  Or is the native socket API not involved in this framework?

Suppose a HIP association is built between node A and node C, based on
the Q.com peer protocol.  Is this association exported to overlay X.org?
If so, suppose A later leaves Q.com overlay, but stays on X.org overlay.
Does the HIP association from A to C persist?  Are HIP records inserted
into the HIP routing table by a particular peer protocol "owned" by that
protocol, and must be removed by that protocol (just as IP routes are
tagged by the routing protocols that insert them into the FIB)?

Case 3:  the stack on Node A is asked to open a session to F-HIT.  It
doesn't know this yet, but F-HIT is not a known HIT in any of the
overlays that it belongs to.  What happens?

> overlay will most likely keep on routing stuff through the overlay.

It depends on the type of overlay, whether the overlay allows "cut
through" forwarding like you are proposing or whether data is forwarded
hop-by-hop at the overlay layer.  But HIP requires the end-to-end
association-- you can't just terminate it hop-by-hop (unless perhaps you
are using HIP DATA packets).

> covey that information in an I1.

If I1s need to be extended, that is an important framework issue.

> abstracted out even when HIP is not used.

I was thinking that some overlays (such as content delivery networks)
may want to run heuristics on IP addresses to determine network
distances. 

> In that way, it will be clearer for the reviewers.

I agree that it may be better to progress these together.

> the draft (and eventually decide to use it). So, I strongly 

OK, as I said, it was just an editorial suggestion.

Regards,
Tom

---

From: Ari Keranen <[email-masked]>
Date: Fri, 24 Jul 2009 19:59:31 +0300

Hi,

I think it makes sense to split the RELOAD specifics out of the HIP BONE 
draft and make it a separate WG item. Also +1 for adopting HICCUPS and 
HIP-VIA as WG items and removing generic ORCHID transformation milestone.

Cheers,
Ari

Gonzalo Camarillo wrote:
> _______________________________________________
> Hipsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hipsec
>

---

From: "wangjun" <[email-masked]>
Date: Tue, 28 Jul 2009 10:36:44 +0200

Hi Gonzalo,

About the HIP ID and Peer ID, My understandings:
1) The HIP Bone is a p2p overlay, each other between peers  talk p2p
protocol, HIP can be encapsulated in a p2p payload..
2)Every HIP host is a p2p client or a p2p agnostic terminal, and attach to
arbitrary peer(s) of the overlay; they register their locator-HIP_ID
bindings into the HIP bone.
So the HIP Hosts may be designated  a peer ID, but  it's really not
mandated. 

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 代表
Gonzalo Camarillo
发送时间: 2009年7月21日 19:04
收件人: Henderson, Thomas R
抄送: HIP
主题: [Hipsec] Comments on the HIP-BONE draft

Hi Tom,

> clear and skirts over some hard issues.

we have moved a few things to the RELOAD instance draft, which is still very
much work in progress (as you can see if you read the draft). Some issues
will be addressed there. Of course, any general issues belonging to the
framework should be addresses in this document.

> same as the node IDs.  The specific instance draft does not handle 
> these issues; it assumes that the peer ID is the ORCHID (which was not 
> acceptable to some in the P2PSIP WG due to possible chosen ID 
> attacks), and is, of course, only one instance.

The framework does not assume that Peer IDs are used at the HIP level. 
It just tells you that depending on the Peer IDs used in your overlay, you
need to convert them to something HIP can use. Originally, we thought of
having a draft that described that conversion in general (you yourself was
working on a similar draft at some point) but now we tend to think that this
type of conversion is better defined in the instance specs.

Regarding the RELOAD instance draft, this is one of the open issues. 
That is, whether we can use RELOAD peer IDs directly or if we need some type
of transformation (ORCHIDs have a prefix; therefore, there are less than 128
bits available).

RELOAD has its own way of identifying particular overlays. Other peer
protocols may have different ways. Therefore, this does not seem to be a
framework issue. Each instance draft would need to describe it separately...
in any case, I agree it is worthwhile talking a bit more about this in the
framework.

> I don't see how this would work since for an ORCHID to be used as a 
> HIT, it must hash a public key.

The text wants to indicate that conversions between Peer IDs and ORCHIDs are
up to each particular instance specification. I agree removing the examples
may be a good idea so that they do not mislead readers.

> It is not clear from the document what IDs are being routed if the 
> peer ID is not the same as the HIT.  I think the answer is that it is 
> the peer IDs that are being routed, and HIP is just providing the 
> links between the peer IDs.

> It may be that the peer IDs are the same as HITs in some instances, 
> but it should be architecturally clear that transport connections are 
> being terminated at each hop in the overlay.

> IP addresses, and HIP will take care of the rest of the ugly business 
> of NAT traversal, mobility, and multihoming," then it would seem to be 

This is not a problem specific to the use of HIP in the overlay. It is a
general problem of the overlay, even if it was not using HIP. If no direct
connections can be formed between nodes in an overlay, the overlay will most
likely keep on routing stuff through the overlay.

> How does it know on which overlay to forward the I1?

This is one of the open issues of the instance draft. RELOAD has its own way
to identify different overlays. We need to decide how we want to covey that
information in an I1.

> in abstracting the underlying topology away from a peer protocol.  
> From the peer protocol layer perspective, HIP makes every node look 
> like it is "on link" whereas in fact, each node is possibly different 
> number of hops away, in different administrative domains of the network,
etc.

Not really. When HIP is not used, the ICE module takes care of establishing
those "links". The complexity of connection management is abstracted out
even when HIP is not used.

> overlay could use HIP to form its links and deal with NAT, mobility, 
> and multihoming.  However, before allowing RELOAD nodes to perform the 
> HIP distributed rendezvous service, I would first define:
> 1) how the system works in the case where the enrollment server 
> chooses PeerIds that are not HITs

The framework already says this is possible... and the instance draft will
need to define how that is done for RELOAD, of course.

> messages got onto the right overlays

This will also need to be defined by the instance draft... in any case, I
agree with you that the framework needs to talk more about this (it does not
discuss this issue right now).

> The above can all be done by assuming that HIP rendezvous is done in 
> the underlay, not overlay.  As a final step, one might consider 
> whether one of these overlays itself could be leveraged to forward HIP 
> traffic.  If all of this holds together, then I think we might have a 
> framework document that completes the charter item.

You make valid points above. After addressing your points in a new revision
of the draft (possibly after more list discussions), I think the best way to
proceed will be to progress the framework and the instance draft together so
that they can be reviewed at the same time. 
In that way, it will be clearer for the reviewers.

> As an editorial note, I also would recommend skipping section 2 
> because RFC 4423 and other documents are available to provide HIP
tutorials.

This is the typical comment we often get from HIP experts :o)... 
however, application-layer people really appreciated that part of the draft
when they read it. Before writing it, we sent them all types of links to HIP
documents and tutorials but they did not find them useful. 
I actually believe that having that type of tutorial material in the draft
makes it much easier for application-layer people to understand the draft
(and eventually decide to use it). So, I strongly suggest to keep it in the
draft.

Thanks,

Gonzalo

---

From: Ari Keranen <[email-masked]>
Date: Tue, 28 Jul 2009 14:46:10 +0300

Hi Tom,

> IP-addr:  A-IP       B-IP       C-IP       D-IP         E-IP

Many of the details depend on the particular instance specification, and 
the RELOAD instance spec is still very much work-in-progress, so how 
things are done is likely to evolve from current situation. Anyway, 
here's how I see these use cases could work.

> A-HIT, A-IP) or just (Q.com-AID, A-HIT)?

Especially bootstrapping is a peer protocol dependent feature (as noted 
in Sections 3.1 and 3.4 of the HIP BONE draft), but in general, you need 
at minimum an IP address (+ possibly port) of an overlay node to contact 
and some overlay identifier (not necessary a peer ID) used to tell the 
contacted node which overlay you want to join. Adding also HIT to the 
tuple increases security, but is not mandatory if the overlay uses an 
enrollment server that gives certificates for the HITs and the nodes can 
use the certificates to prove that they truly belong to that overlay.

> with Q.com?  Or is the native socket API not involved in this framework?

If Peer-IDs are not HITs, the peer protocol uses "Q.com-CID" as the peer 
name for node C. If this is the case, presumably there is a mapping 
(using some transformation) between Peer ID and HIT, so that there is no 
need for any discovery step.

There is no need to query for C-IP in the overlay since the HIP base 
exchange is done via the overlay and the C-IP (or, the "best" C-IP) is 
discovered using ICE as defined in the NAT traversal draft. And the BeX 
is done using existing overlay connections.

I1 (and the rest of the BeX) is routed using the overlay routing table 
constructed by the overlay protocol, so there is no additional (DNS/DHT) 
lookup for this. If there is no mapping from HIT to Peer ID, we may need 
to convey also the Peer IDs in the HIP packets.

The interaction with peer protocol is likely to require more features 
than what the current HIP native socket API can provide, but at least my 
view on this is that the peer protocol and HIP daemon are integrated so 
that they don't need to use the socket API for sharing the routing table 
(e.g., they are run in the same process, or they use IPC).

> the Q.com peer protocol.  Is this association exported to overlay X.org?

IMO, no. The different overlays likely have different finger tables 
(i.e., peer protocol connections between peers) and thus it would be 
unlikely (at least in a big network) that they would share connections. 
Also, the HITs for different overlays are likely to be different. This 
could be considered as an optimization though.

> tagged by the routing protocols that insert them into the FIB)?

Whether a HIP association persists, would depend on the implementation 
of the optimization. If the association was created for something else 
than P2P protocol traffic (e.g., SIP call), it should persist as long as 
it is used.

The routing table records would be overlay instance specific (even if 
they use the same protocol) so they would be added and removed by the 
same overlay process.

> overlays that it belongs to.  What happens?

The overlay tries to route I1 to F-HIT but when it fails to do so, the 
node that detects this (i.e., the node that is responsible for the part 
of the overlay where F would be) responds with an error message. The 
MESSAGE_NOT_RELAYED notify packet type could be used for this, but I 
think the behavior is HIP BONE instance specification specific.

> are using HIP DATA packets).

HIP DATA packets could be used for this. Also, it is possible to use a 
TURN server with IPv4-IPv6 translation. If a TURN server implementing 
the turn-ipv6 draft is used, ICE would take care of this.

> If I1s need to be extended, that is an important framework issue.

The RELOAD HIP BONE instance spec defines OVERLAY_ID attribute for this 
purpose. The (next version of) HIP BONE draft will define a generic 
format for the parameter and instance specs define how it is encoded for 
each specific protocol. All HIP overlay messages should have this 
parameter to indicate which overlay they belong to.

I understand that we want to keep I1 as simple as possible to prevent 
DoS attacks, but this parameter would not create any state in the 
receiving or forwarding node and it would be trivial to process, so I 
don't think it is a problem to have it there.

> may want to run heuristics on IP addresses to determine network

I guess you're referring to the IP addresses of the hosts that you have 
a direct HIP association with (since even without HIP you don't know the 
addresses of the intermediate nodes forwarding the messages in the 
overlay). For such nodes, I assume one can ask the current IP address 
using the native HIP API and SHIM_LOC_PEER_SEND (or SHIM_LOCLIST_PEER?) 
socket option. That said, because of TURN servers and other relays, this 
may not be really a good idea.

>> will need to define how that is done for RELOAD, of course.

With RELOAD, the enrollment server can generate Peer IDs that have 
ORCHID prefix either by generating the key pair or by generating random 
ID and using certificates.

>> does not discuss this issue right now).

This will be addressed with the generic OVERLAY_ID in the framework draft.

Cheers,
Ari

---

From: Ari Keranen <[email-masked]>
Date: Tue, 28 Jul 2009 14:53:39 +0300

Hi,

> protocol, HIP can be encapsulated in a p2p payload..

Actually, the current idea is that peer protocol messages would be 
encapsulated in HIP messages to keep the protocol layering consistent.

> bindings into the HIP bone.

The HIP hosts don't actually need to register locators to the overlay 
since the HIP base exchange is done via the overlay and the (best) 
locator is discovered using ICE (see [1] but replace HIP relay server 
with a HIP BONE overlay).

> So the HIP Hosts may be designated  a peer ID, but  it's really not

HIP hosts have peer IDs when they are part of a HIP BONE overlay, but 
preferably the peer ID is a one of the HITs of the host.

Cheers,
Ari

[1] http://tools.ietf.org/html/draft-ietf-hip-nat-traversal-08

---

From: [email-masked]
Date: Tue, 28 Jul 2009 16:00:15 +0200

Hi,

   That means every HIP Host must be a p2p peer, and the deployment model 
is same  as the P2P applications such as skype? In such a scenario,only 
HIP hosts can communicate each other, so what about the interworking 
solution between HIP and non-HIP host?
  I prefer that HIP bone acts as a distributed service system and every 
ordinary HIP host is just a p2p client, and combining with the mechnisms 
described in draft-melen-hip-proxy, the generic interworking solution can 
be provided to any hip and non-hip hosts.

> > It just tells you that depending on the Peer IDs used in your overlay, 
you
> > working on a similar draft at some point) but now we tend to thinkthat 
this
> > That is, whether we can use RELOAD peer IDs directly or if we needsome 
type

> > framework issue. Each instance draft would need to describe it 
separately...

> > general problem of the overlay, even if it was not using HIP. If no 
direct
> > connections can be formed between nodes in an overlay, the overlaywill 
most

> > Not really. When HIP is not used, the ICE module takes care of 
establishing
> > The framework already says this is possible... and the instance draft 
will

> > You make valid points above. After addressing your points in a new 
revision
> > however, application-layer people really appreciated that part of the 
draft
> > I actually believe that having that type of tutorial material in the 
draft
> > (and eventually decide to use it). So, I strongly suggest to keep it 
in the

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Tue, 28 Jul 2009 08:51:52 -0700

Hi Ari, some responses inline below.

> From: Ari Keranen [mailto:[email-masked]] 
> Sent: Tuesday, July 28, 2009 4:46 AM
> To: Henderson, Thomas R
> Cc: Gonzalo Camarillo; HIP
> Subject: Re: [Hipsec] Comments on the HIP-BONE draft
> 
> Hi Tom,
> 

This is perhaps my main concern.  I do not understand how you can form
HITs from Peer IDs, in general, unless the Peer IDs are HITs or public
keys themselves.  I see how you can bind a HIT to a Peer ID using a
certificate, but that is not the same.

> exchange is done via the overlay 

which overlay?  Are you assuming that the routing table has an explicit
entry for an overlay next hop for C?  If there is no entry for C-HIT, is
the I1 sent on both overlays?

> and the C-IP (or, the "best" 
> C-IP) is 
> view on this is that the peer protocol and HIP daemon are 
> integrated 

Ah, OK, perhaps this suggests a misunderstanding on my part about what
you are trying to define.  I was not assuming that HIP and peer protocol
were integrated, but that HIP was providing a service to different peer
protocols, so that other WGs like P2PSIP could build an overlay on the
service offered by a HIP BONE.  Maybe this point could be clarified in
the next draft version.

> so 

If peer protocol and HIP are integrated, offering a specialized API,
then I think my questions about how information is shared between
overlays are not so relevant.

> HIP DATA packets could be used for this. 

Probably not in the media-stream, RELOAD use case.

> Also, it is possible 
> to use a 

OK

> may not be really a good idea.

Again, I think my concern here is based on my assumption that HIP is
offering a service to a peer protocol, and may be abstracting away
details from it that it may care about.  However, your comments above
suggest that since the peer protocol and HIP are part of an integrated
design, so maybe this is less of a concern.  Mainly, the concern I was
raising was along the same lines of spoofing HITs for IP addresses to
applications that may really want the IP addresses.

> This will be addressed with the generic OVERLAY_ID in the 

OK, I will wait to see that.

Regards,
Tom

---

From: Petri Jokela <[email-masked]>
Date: Wed, 29 Jul 2009 11:23:03 +0200

> "Specify a framework to build HIP-based overlays. This framework will
...
> above as the WG item associated to the milestone for the definition.

The proposal sounds reasonable, taking also into account the  
discussion that has been going on in another thread.

> 2) We have the following milestone:
...
> http://tools.ietf.org/internet-drafts/draft-nikander-hip- 

For me, this sounds good. As in the previous case, taking into account  
also the ongoing discussion on the related thread.

> http://tools.ietf.org/internet-drafts/draft-camarillo-hip-via-00.txt

This sounds ok.

> the WG if we should remove that milestone from our charter.

While there is no activity, it seems reasonable to remove it now.

/petri

-- 
Petri Jokela                        Tel:    +358 9 299 2413
Research scientist                  Fax:    +358 9 299 3535
NomadicLab, Ericsson Research       Mobile: +358 44 299 2413
Oy L M Ericsson Ab                  email: [email-masked]

---

From: Ari Keranen <[email-masked]>
Date: Wed, 29 Jul 2009 14:07:49 +0300

> certificate, but that is not the same.

The easiest solution is to require/recommend that Peer IDs are created 
just like HITs. This should be possible, with minor modifications, at 
least with the peer protocols and algorithms we have been looking into 
so far. However, to be future proof, I agree that a general mechanism 
would be useful.

I think we should consider creating "HITs" (or ORCHIDs) that are not 
hashes of cryptographic keys (and maybe call them ORIDs :). Is there 
some technical reason that prevents you from having an arbitrary, but 
random enough, ID after the ORCHID prefix that is not based on a public 
key if you include anyway certificates and host identities as HIP 
parameters in the HIP base exchange?

Another option would be to leave this out of scope of the current 
documents and define such transformation when there is a protocol or 
algorithm that really needs one. And we can fall back to having Peer IDs 
in HIP parameters and route based on those for overlays whose IDs can't 
be transformed into HITs.

> the I1 sent on both overlays?

Q.com overlay if the node A is (in that context) initiating connection 
to node C at overlay Q.com. The next hop is taken from Q.com overlay's 
routing table so there is no need for explicit entry for C-HIT. Perhaps 
it would be clearer to talk about "application on node A using overlay 
Q.com" instead of "node A". That is, when one initiates a connection 
(BeX), one tells which overlay that connection belongs to.

Once again, it could be possible for the application or node to try to 
contact another node in all the overlays, but this would be an 
additional optimization or a feature. If we want, e.g., legacy 
applications to be able to use just the socket API for initiating 
connections over P2P overlays, one would need to configure to which 
overlay(s) this kind of messages should be sent to.

> service offered by a HIP BONE.  Maybe this point could be clarified in

OK, I agree that it would make sense to clarify this.

> overlays are not so relevant.

OK.

> Probably not in the media-stream, RELOAD use case.

Right, the HIP DATA packets are not really suitable for media but should 
be used only/mainly for the signaling. Although I can think of some use 
cases where even some sort of "media" (say, IM if there are no media 
relays and firewalls prevent direct connectivity) could go via an 
overlay, so I would not make this a MUST NOT, but rather a NOT RECOMMENDED.

> applications that may really want the IP addresses.

OK. In that sense the design we have in mind should be able to expose 
enough details for the peer protocols.

> OK, I will wait to see that.

The next version should contain that, but at least currently it's just a 
general version (can have any length) of the OVERLAY_ID in the RELOAD 
instance spec.

Cheers,
Ari

---

From: Ari Keranen <[email-masked]>
Date: Wed, 29 Jul 2009 14:29:35 +0300

[email-masked] wrote:
>    That means every HIP Host must be a p2p peer, and the deployment 
> model is same  as the P2P applications such as skype? In such a 
> scenario,only HIP hosts can communicate each other, so what about the 
> interworking solution between HIP and non-HIP host?

Every HIP host that is part of the overlay (i.e., routing messages and 
storing data there) would be a peer. Interworking with non-HIP hosts has 
not been in the scope of HIP-BONE so far.

> described in draft-melen-hip-proxy, the generic interworking solution 
> can be provided to any hip and non-hip hosts.

That's an interesting idea. What kind of interworking did you have in mind?

Cheers,
Ari

>  > > working on a similar draft at some point) but now we tend to 
> thinkthat this
>  > > That is, whether we can use RELOAD peer IDs directly or if we 
> needsome type
>  > > connections can be formed between nodes in an overlay, the 
> overlaywill most

---

From: Tobias Heer <[email-masked]>
Date: Wed, 29 Jul 2009 14:36:37 +0200

Hi Gonzalo.

Comments inline:
Am 20.07.2009 um 12:33 schrieb Gonzalo Camarillo:

> We would like to ask the WG
I think it makes sense - yes.

> above as the WG item associated to the milestone for the definition.

Provided the issues that Tom pointed out can be resolved, I support  
this decision.

> http://tools.ietf.org/internet-drafts/draft-nikander-hip- 

I am fine with this, too.

> the WG if we should remove that milestone from our charter.

I agree.

BR,

Tobias

--  

Dipl.-Inform. Tobias Heer, Ph.D. Student
Distributed Systems Group
RWTH Aachen University, Germany
tel: +49 241 80 207 76
web: http://ds.cs.rwth-aachen.de/members/heer

---

From: Miika Komu <[email-masked]>
Date: Thu, 30 Jul 2009 12:17:42 +0300

Gonzalo Camarillo wrote:

Hi,

> above as the WG item associated to the milestone for the definition.

+1

> http://tools.ietf.org/internet-drafts/draft-camarillo-hip-via-00.txt

+1

> the WG if we should remove that milestone from our charter.

Fine by me.

---

From: Varjonen Samu <[email-masked]>
Date: Thu, 30 Jul 2009 12:18:54 +0200

+1

+1

+1

---

From: Miika Komu <[email-masked]>
Date: Thu, 30 Jul 2009 14:15:29 +0300

Miika Komu wrote:

Hi,

sorry, I missed one. +1 for hiccups too.

---

From: Jan Melen <[email-masked]>
Date: Thu, 30 Jul 2009 14:21:45 +0300

Hi,

+1

> also the ongoing discussion on the related thread.

+1 and the concerns raised before IETF 75 are addressed in the -03 draft 
and some new that came up during IETF 75 will be addressed in -04

+1

> While there is no activity, it seems reasonable to remove it now.

Ok!

   Jan

---

From: Varjonen Samu <[email-masked]>
Date: Thu, 30 Jul 2009 14:02:05 +0200

> sorry, I missed one. +1 for hiccups too.

So did I :) +1