Subject: Re: [Hipsec] WGLC: draft-ietf-hip-reload-instance-00

From: Ari Keranen <[email-masked]>
Date: Mon, 01 Mar 2010 19:08:30 +0200

Henderson, Thomas R wrote:
>> -----Original Message-----
>> From: Ari Keranen [mailto:[email-masked]]
>> Sent: Thursday, February 25, 2010 11:00 PM
>> To: Henderson, Thomas R
>> Cc: 'Gonzalo Camarillo'; HIP
>> Subject: Re: [Hipsec] WGLC: draft-ietf-hip-reload-instance-00
>>
>> Henderson, Thomas R wrote:
>>>>> When you say "In the other Peer ID mode, namely "RELOAD",..."
>>>>> which case do you mean?  Just the self-generated case?  If it is
>>>>> the centralized case, the Node IDs can't be used as HITs, and
>>>>> then the Node IDs and the HITs are not related to one another and
>>>>> need to be bound by some kind of certificate framework.  This is
>>>>> what I think section 5.6.1.1 of the base draft refers to.  Or am
>>>>> I misunderstanding something?
>>>> We mean both cases.  I'm sorry but I don't follow why couldn't the
>>>> non-ORCHID Node IDs be used as "HITs" (i.e., in the HIP header, VIA
>>>>  lists and certificates) in the centralized case?
>>>>
>>> Let's say that the enrollment server allocates the first node the
>>> Node ID of "0", the second node a Node ID of "1" etc.  Are you
>>> suggesting that these values are used as HITs?
>> Yes. Although the enrollment server would not really give IDs
>> like that
>> but rather make them cryptographically random, but the point
>> remains the
>> same: the IDs in the RELOAD mode are not (necessarily) hashes
>> of public
>> keys.
>>
>>> I raised this issue in another thread yesterday, but it seems to me
>>> that a central idea in the HIP architecture is that the HIT is the
>>> hash of the public key of a public/private key pair and
>> that the host
>>> holds the private key.  I don't believe we've talked before
>> about the
>>> possibility that the HI and HIT are not related cryptographically.
>> Yeah, we had a thread on the HIP list about this some half a year ago
>> but it died away. I admit that the HIT being a hash of a
>> public key is
>> somewhat central idea in HIP, but is it really necessary if
>> you have a
>> certificate that can provide the same binding between the
>> non-HIT-ID and
>> Host ID?
>>
>> AFAIK, you only lose the property that for someone else it's
>> really hard
>> to generate the same identity, but with an enrollment server
>> that would
>> not be a problem thanks to the certificates. Without an enrollment
>> server one could fake the ID in the RELOAD mode, but then you
>> can still
>> use the ORCHID mode and real HITs or generate IDs as digests
>> (SHA-1 or
>> SHA-256) of the public key as the RELOAD draft proposes.
>>
> 
> I think we should really explore this idea more but let's do so in the more RFC4423bis context as discussed in the other thread.  I wasn't objecting to the idea per se, but just that we should not slip it into this draft if it is not really recognized as a part of HIP today.

Actually, we used to have a milestone about this in the charter, but it 
was removed last July when the WG's conclusion was that transformations 
would be context specific. So, this already is recognized as part of the 
HIP today.

> I see pros and cons to non-ORCHID HITs:
> - pro:  can be designed to be hierarchical or formatted as needed.  Can they even be IPv6 addresses?
> - con:  HITs are no longer unique.  It is really the certificate which is the unique identifier.
> It does seem more flexible and may have deployment advantages.  Does it solve the ACL problem with current HITs (that they are non-aggregatable)?  It could lead to aggregatable HITs but then the ACL will need to know the authorizing enrollment server for those HITs, and check CERTs.

These questions are good to be explored on RFC4423bis, but we don't need 
the answers to proceed with the RELOAD instance spec, so I would not 
delay the instance spec by making it depend on RFC4423bis.

Anyhow, we are not changing anything fundamental in HIP, and having this 
property we can make HIP meet the different requirements that people 
building overlays have.

Cheers,
Ari

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Mon, 1 Mar 2010 09:49:56 -0800

> >
> > I think we should really explore this idea more but let's
> do so in the more RFC4423bis context as discussed in the
> other thread.  I wasn't objecting to the idea per se, but
> just that we should not slip it into this draft if it is not
> really recognized as a part of HIP today.
>

Can you point me to a document that shows where this is recognized as part of HIP today?

> > - con:  HITs are no longer unique.  It is really the
> certificate which is the unique identifier.
> > It does seem more flexible and may have deployment
> advantages.  Does it solve the ACL problem with current HITs
> (that they are non-aggregatable)?  It could lead to
> aggregatable HITs but then the ACL will need to know the
> authorizing enrollment server for those HITs, and check CERTs.
>

I disagree that this changes anything fundamental:  RFC5201, section 3.1:
3.1.  Host Identity Tag (HIT)

   The Host Identity Tag is a 128-bit value -- a hashed encoding of the
   Host Identifier.

I am not opposed to relaxing this in principle but I do not recall that we have agreed on how to do this.

- Tom

---

From: Ari Keranen <[email-masked]>
Date: Tue, 02 Mar 2010 10:36:54 +0200

Henderson, Thomas R wrote:
>>> I think we should really explore this idea more but let's4
>> do so in the more RFC4423bis context as discussed in the other
>> thread.  I wasn't objecting to the idea per se, but just that we
>> should not slip it into this draft if it is not really recognized
>> as a part of HIP today.
>> 
>> Actually, we used to have a milestone about this in the charter,
>> but it was removed last July when the WG's conclusion was that 
>> transformations would be context specific. So, this already is
>> recognized as part of the HIP today.
> 

The WG overlay documents, HIP BONE and RELOAD instance, have reflected 
this. Yes, they are not RFCs, but my point was that this is nothing we 
have introduced here out of the blue.

>>> I see pros and cons to non-ORCHID HITs: - pro:  can be designed
>>> to be hierarchical or formatted as
>> needed.  Can they even be IPv6 addresses?
>> advantages.  Does it solve the ACL problem with current HITs (that
>> they are non-aggregatable)?  It could lead to aggregatable HITs but
>> then the ACL will need to know the authorizing enrollment server
>> for those HITs, and check CERTs.
>> 
>> These questions are good to be explored on RFC4423bis, but we don't
>> need the answers to proceed with the RELOAD instance spec, so I
>> would not delay the instance spec by making it depend on
>> RFC4423bis.
>> 
>> Anyhow, we are not changing anything fundamental in HIP, and having
>> this property we can make HIP meet the different requirements that
>> people building overlays have.
>> 
> 
> I disagree that this changes anything fundamental:  RFC5201, section
> 3.1: 3.1.  Host Identity Tag (HIT)
> 

OK, that's true, only the "ORCHID mode" identifiers are strictly HITs in 
that sense so we could call the generic RELOAD mode IDs something else. 
Perhaps RITs?

> that we have agreed on how to do this.

When we removed the generic transformation milestone from the charter, 
the conclusion was that the transformation (or Node ID generation) would 
be done in different ways depending on the peer protocol and thus better 
defined in the instance specs. And that's what the RELOAD instance spec 
now does. Also, if the ID is generated as the RELOAD draft proposes (SHA 
of the public key; which you could use also as the the Host ID), it 
actually even fits nicely to the definition of HIT.

Cheers,
Ari

---

From: Jan Melen <[email-masked]>
Date: Wed, 3 Mar 2010 21:08:35 +0200

Hi,

Here is link to updated version:
http://users.piuha.net/jmelen/HICCUPS/draft-ietf-hip-hiccups-02.txt

On Feb 22, 2010, at 8:46 PM, Henderson, Thomas R wrote:

>> From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of Gonzalo Camarillo
>> Sent: Tuesday, January 26, 2010 7:19 AM
>> To: HIP
>> Subject: [Hipsec] WGLC: HIP-based overlays
>> 
>> Folks,
>> 
>> we would like to WGLC the set of specifications that describe how to
>> build HIP-based overlays. The documents under WGLC are the following:
>> 
>> http://tools.ietf.org/html/draft-ietf-hip-bone-04
>> http://tools.ietf.org/html/draft-ietf-hip-reload-instance-00
>> http://tools.ietf.org/html/draft-ietf-hip-hiccups-01
>> http://tools.ietf.org/html/draft-ietf-hip-via-00
>> 
>> This WGLC will end on February 23rd. Please, send your
>> comments to this
>> list.
>> 
> 
> comments on draft-ietf-hip-hiccups-01:
> 
> Overall, I think that this document mainly makes sense in the context of HIP BONE and should be folded into that specification.  However, if kept stand-alone, it would help to clarify in the introduction that this specifies a data service with the following semantics:  unordered, duplicate free (subject to receiver ACK cache size and lifetime), reliable (up to a retransmission count), authenticated, and encrypted message-based delivery service.  I would also recommend stating that APIs to higher-level protocols that might use this service are outside the scope of this specification.
> 

Added the semantics and that APIs are outside the scope.

>> 2. Terminology
>> 
>> 
>>   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>>   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>>   document are to be interpreted as described in RFC 2119 [RFC2119].
> 
> This section is empty; probably at the very least it should point to the normative references that define the terminology in use later in the document.
> 

Yes, added reference to RFC 5201 for terminology.

>> 3. Background on HIP
>> 
>> 
>>   The HIP protocol specification [RFC5201] defines a number of messages
>>   and parameters.  The parameters are encoded as TLVs, as shown in
>>   Section 3.1.2.  Furthermore, the HIP header carries a Next Header
>>   field, allowing other arbitrary packets to be carried within HIP
>>   packets.
> 
> Perhaps this section could go away or be refactored if this draft is merged to hip-bone.
> 
>> 4.1. Definition of the PAYLOAD_MAC Parameter
>> 
>>     Length            length in octets, excluding Type, Length, and
>>                       Padding
> 
> are there any minimum or maximum size limitations for this parameter?  Should the maximum length be tied to the maximum size that the HMAC can handle?

Do you mean that we should be more specific than what we are saying about the HMAC itself:
  Payload HMAC      HMAC computed over the data to which the Next
                     Header and Payload Data points to. The size of
                     the HMAC is the natural size of the computation
                     output depending on the used function.

> 
>> 5.1. Handling of SEQ_DATA and ACK_DATA
>> 
>> 
>>   A HIP DATA packet contains zero or one SEQ_DATA parameter.  The
>>   presence of a SEQ_DATA parameter indicates that the receiver MUST ACK
>>   the HIP DATA packet.  A HIP DATA packet that does not contain a
>>   SEQ_DATA parameter is simply an ACK of a previous HIP DATA packet and
>>   MUST NOT be ACKed.
> 
> is it legal to have a HIP DATA with zero SEQ_DATA and zero ACK_DATA?  If not, suggest to say that if SEQ_DATA is missing, ACK_DATA must be present.
> 
> Can SEQ_DATA be present with no PAYLOAD_MAC parameter?

Fixed either SEQ_DATA or ACK_DATA must be present and in case of SEQ_DATA also PAYLOAD_MAC is required.

> 
>>   packet.  A host MAY choose to hold the HIP DATA packet carrying ACK
>>   for a short period of time to allow for the possibility of
>>   piggybacking the ACK parameter, in a manner similar to TCP delayed
>>   acknowledgments.
> 
> Should the ACK_DATA format allow for multiple sequence numbers, if so, to avoid carrying a Type and Length field for each one?

Yes and now it is defined.

> 
>>   1.  The host creates a HIP DATA packet that contains a SEQ_DATA
>>       parameter.  The host is free to choose any value for the SEQ_DATA
>>       parameter in the first HIP DATA packet it sends to a destination.
> 
> This section would be clearer if you replaced "SEQ_DATA parameter" and "SEQ_DATA value" with "SEQ_DATA sequence number".

Fixed.

   Thanks for reviewing the draft
       Jan

---

From: Ari Keranen <[email-masked]>
Date: Thu, 04 Mar 2010 19:11:42 +0200

Hi Tom,

Thanks for the comments! Responses inline.

Henderson, Thomas R wrote:
> comments on draft-ietf-hip-bone-04:
> 
> (please see my other post suggesting that this draft include the via
> and hiccups drafts and that it add a better protocol overview
> section).

OK, we'll add some overview text to the next version.

>>  "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
>> this document are to be interpreted as described in RFC 2119
>> [RFC2119].
> 
> This section is empty; I think that since this is intended as a
> framework document, a good terminology section is needed.

OK. I added the following:

    Overlay network:  A network built on top of another network.  In case
       of HIP BONEs, the underlaying network is an IP network and the
       overlay can be, e.g., a peer-to-peer (P2P) network.

    Peer protocol:  A protocol used by nodes in an overlay network for
       performing, e.g., data storage and retrieval or overlay
       maintenance.  HIP is used for conveying the peer protocol messages
       between the nodes in the overlay network.

    Node ID:  A value that uniquely identifies a node in an overlay
       network.  The value is not usually human-friendly, but for example
       a hash of a public key.

    Valid locator:  A Locator (as defined in [RFC5206]; usually an IP
       address or an address and a port number) that a host is known to
       be reachable at, for example, because there is an active HIP
       association with the host.

Did you have something else specific in mind that should be added here?

>> 3. Background on HIP
>> 
> 
> I previously commented (earlier version of this draft) that it might
> be easier to refer readers to the HIP arch or base RFCs, but if you
> want to keep it here, suggest to move it to an appendix since it is
> not normative material.

I think it's good to have this early in the document since it provides 
the needed background for P2P (and other non-HIP) people about HIP. If 
it were in the appendix, or just references, likely it would be never 
actually read and there would be plenty of misconceptions about the rest 
of the document.

>> 4. The HIP BONE Framework
>> 
>> 
>> An overlay typically requires three types of operations:
>> 
>> o  overlay maintenance. o  data storage and retrieval. o
>> connection management.
> 
> Not all overlays (e.g. pure routing overlays) require data storage
> and retrieval.  Suggest to say that "Many overlays typically
> require..."

Makes sense; fixed this.

>> 4.1. Peer ID Assignment and Bootstrap
>> 
>> Nodes in an overlay are primarily identified by their Peer IDs.
> 
> This terminology "Peer ID" seems very RELOAD-centric.  How about the
> more general "Node ID", or talk about the distinction between peers
> and clients, such as in RELOAD?

Good point. Changed all the occurrences of Peer ID into Node ID.

>> If the overlay network or peer protocol has more specific 
>> requirements for the Peer ID value that prevent using HITs derived 
>> from public keys, each host will need a certificate (e.g., in their
>>  HIP base exchanges) provided by the enrollment server to prove
>> that they are authorized to use a particular identifier in the
>> overlay.
> 
> Note:  this is what I thought was missing in the instance
> specification.

This will be clarified in the RELOAD instance spec.

>> Bootstrap issues such as how to locate an enrollment or a bootstrap
>>  server belong to the peer protocol.
> 
> This seems to be a placeholder sentence for future text.  At the very
> least, this framework draft should deal with the bootstrap issue of
> how to forward I1s along the HIP BONE when a node first joins the
> overlay.

I think this is really an instance specific issue and there's not much 
one can say in the architecture document.

>> Note that the border between HIP BONE instance specification and a 
>> peer protocol specifications is blurry.
> 
> I agree with this observation; the current drafts are basically
> written from the standpoint of RELOAD and details about e.g.
> interaction between HIP and topology plugin are fuzzy.  However, it
> seems to me that to be useful as a general purpose framework for
> arbitrary peer protocols, crisper APIs would need to be specified.

I think that how, e.g., the topology plugin and HIP daemon actually 
interact are implementation details, and as discussed in the instance 
spec thread, I think these documents are not the right place for 
defining APIs or implementation details.

>> 5. Advantages of Using HIP BONE
>> 
>> Using HIP BONE, as opposed to a peer protocol, to perform
>> connection management in an overlay has a set of advantages.  HIP
>> BONE can be used by any peer protocol.  This keeps each peer
>> protocol from defining primitives needed for connection management
>> (e.g., primitives to establish connections and to tunnel messages
>> through the overlay) and NAT traversal.  Having this functionality
>> at a lower layer allows multiple upper-layer protocols to take
>> advantage of it.
> 
> This section probably could be moved to an introduction, explaining
> why we are going through all of the trouble to support these
> overlays.

Makes sense. I moved this to be part of the intro section.

>> 7.  Architectural Considerations
> 
> Note, Section 7 is probably more important as a first section, not
> the last in the draft.

I'll see what we can do with this.

>> Architecturally, routing tables are located between the peer
>> protocol and HIP, as shown in Figure 7.
> 
> This is important architectural discussion.  I had a few questions
> here:
> 
> 1) can a HIP packet from one overlay consult the routing table built
> in another overlay?

I'd say that, by default, no. HIP BONE packets are overlay network 
specific (identified with the OVERLAY_ID), so they should not cross 
overlay borders. However, I think we shouldn't forbid that either if 
someone want to specify something for this.

> 2) if HIP receives a locally originated packet with no OVERLAY_ID,
> and it has one or more peer protocols running, how does it decide
> where to route the packet?  I assume that all locally originated
> packets will somehow have their overlay identifier specified, but it
> would be helpful to state this somewhere.  For example, if it were
> RELOAD, RELOAD may have special APIs allowing it to identify the
> overlay ID that all locally originated packets from the RELOAD
> instance should use.  In addition, if HIP on that node was providing
> traditional HIP services to legacy applications, such (legacy
> applications) outbound packets would use rendezvous/relay servers as
> usual.

This is mostly an API issue, but one could configure his HIP 
implementation so that if there is no locator for a HIT, it is 
automatically sent to a certain overlay. Actually, we could define a 
"rendezvous usage" using RELOAD for this in the RELOAD instance spec.

Cheers,
Ari