Subject: [P2PSIP] New version of draft-bryan-p2psip-reload

From: Cullen Jennings <[email-masked]>
Date: Tue, 10 Jun 2008 11:47:08 -0700

We've just uploaded an update to the reload draft.  Until it shows up  
in the drafts directory, you can find it at

http://svn.resiprocate.org/rep/ietf-drafts/fluffy/draft-bryan-p2psip-reload-04.txt
or
http://svn.resiprocate.org/rep/ietf-drafts/fluffy/draft-bryan-p2psip-reload-04.html

reload-04 represents a total rewrite of the presentation of the  
protocol.  There were a number of goals:

- add several descriptive sections at the beginning that detail how  
the protocol works and the design choices we made (and some of the  
options we chose not to incorporate at this point)
- Simplify the presentation (and protocol) wherever possible by  
removing extraneous features from this draft.  Some of these may come  
back in future drafts, but we felt simplifying wherever possible was  
good.
- remove the bit-field diagrams from the protocol descriptions in  
favor of c-like message structure presentations.

We are very interested in comments on this draft.  We expect to have  
time for another revision in about 2 weeks.  We have tried to address  
as many of the comments and questions that have been raised as we  
can.  In some areas we have made deliberate choices to avoid adding  
features that have been requested.  Where possible we discuss the  
tradeoffs that adding additional features will require.  We think it's  
important for the working group to decide as a whole where additional  
features are worth the added complexity.

Please send your comments to the working group list - it would make it  
easier for us if people tried to keep separate issues in separate  
threads and start new threads where it appropriate. I think we would  
all like to hash out as many protocol issues as possible before we get  
to Dublin.

Cullen
Bruce
Eric
Salman
Henning

_______________________________________________
P2PSIP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/p2psip

---

From: Michael Chen <[email-masked]>
Date: Wed, 11 Jun 2008 20:34:46 -0800

Cullen et. al.,

I am glad to see RELOAD continues to refine, but here are a few things I 
spotted so far:

1. Section 6.2.2.1, the enum value for peer should be 1 instead of 2.

2. Section 6.2.1.1, ResourceId is defined as a variable opaque with an 
8-bit length byte. In section 6.2.2.1, the Destination structure is 
defined with a length field before the DestinationData variant, which 
means there are two places that store the size of NodeId and ResourceId. 

I favor having the length in Destination and remove the restriction of 
NodeId being a fixed 16 byte opaque, thus allowing the option to embed 
the full 20-byte SHA1 hash.  This also makes the Destination a simple 
type-length-value (no need to define DestinationData).

3. Section 6.2.2.2, the second paragraph's description on how to use 
ROUTE-LOG flag in response conflicts with the first paragraph (towards 
the end).  The first paragraph says if ROUTE-LOG flag is set in request, 
the response MUST send the log back AND set the ROUTE-LOG flag to 1. 
Well there is no choice for the response.

Also, giving the choice to append the reverse route-log to the responder 
is not a good idea. This choice should be specified by the requester via 
a second flag, say REVERSE-LOG, which must/should be honored by all 
intermediate nodes.

Suggestion to the Forwarding Header:

The length of Via-list and Destination-list are in the fix portion of 
the header, but the route-log length is in the 16-bit prefix of the 
log.  Why not add one more 16-bit length field called "Route Log Length" 
after the "Destination List Length" (of course remove the 16-bit length 
prefix from the route-log).  The benefits are obvious, a) easy 
calculation of the start of "Message Contents"; b) easy to tell if 
route-log exist; c) via/destination list starts at 32-bit boundary.

Thank you

--Michael

---

From: Michael Chen <[email-masked]>
Date: Thu, 12 Jun 2008 22:20:36 -0800

Cullen,

By comparing to reload-03, I realize that the notation "opaque   
name<0..2^8-1>" simply means a variable length of bytes with NO leading 
length byte, contrary to what I suggested in my last post. Then in 
Reload-04,

4. Either the "name<0..2^8-1>" notation is ambiguous about whether such 
leading length exist; or

5. If no such length byte is implied, then there are a number of places 
where the length of variable bytes/characters are missing (search all 
occurrences of "<0.."):

  RouteLogEntry.version
  RouteLogEntry.certificate
  ErrorResponse.reason_phrase
  ErrorResponse.error_info
  ConnectReqAns.ufrag
  ConnectReqAns.password
  ConnectReqAns.role
  ConnectReqAns.candidate
  TunnelReq.dialog_id
  TunnelReq.application_pdu
  ... a lot more of these ...

The first two items above also make parsing these two difficult:

  RouteLogEntry.extensions
  RouteLog (unless take my suggestion of adding "Route Log Length" to 
fix header)

Also, the size of "Signature.signature_value" must be determined using 
the size of the entire PDU, which is an awkward way to do it.

Thank you

--Michael

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 13 Jun 2008 07:06:31 -0700

At Thu, 12 Jun 2008 22:20:36 -0800,
> length byte, contrary to what I suggested in my last post. Then in 

I'm not sure why you're comparing to reload-03. The diagrams in
reload-03 were generated mechanically from a syntax like that
in reload-04, but there may have been bugs in the translator,
and there have been some changes to accomodate problems we
found. Better to read reload-04 de novo.

Anyway:

   opaque foo<0..2^8-1>;

means variable length *with* a leading length with a length byte.
This is explained in S 6.2.1.1:

   A ResourceId, shown below, represents a single resource-id.

              typedef opaque       ResourceId<0..2^8-1>;

   Like a NodeId, a resource-id is an opaque string of bytes, but unlike
   Node-IDs, resource-ids are variable length, up to 255 bytes (2048
   bits) in length.  On the wire, each ResourceId is preceded by a
   single length byte (allowing lengths up to 255).  Thus, the 3-byte
   value "Foo" would be encoded as:  03 46 4f 4f.

> 4. Either the "name<0..2^8-1>" notation is ambiguous about whether such 

It's not ambiguous. It always exists.

-Ekr

---

From: Michael Chen <[email-masked]>
Date: Mon, 16 Jun 2008 21:18:27 -0800

Eric,

Thanks for the clarification, and in which case issues mentioned in my 
first post to this thread should be considered. Although the Web archive 
view of that post shows it being broken up by extra email headers.  
Would someone please look into that?

Thank you

--Michael

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 17 Jun 2008 07:50:26 -0700

> 1. Section 6.2.2.1, the enum value for peer should be 1 instead of 2.

Thanks - fixed

> means there are two places that store the size of NodeId and  

Yes, I see what you are saying about this - perhaps we should change  
it. We need that anyways for it to be extensible to new types. I guess  
we could argue we did not need extensibility here but some people did  
want this to be an protocol extension point and I don't see much harm  
in that but I realize this is somewhat separate from your second point.

> type-length-value (no need to define DestinationData).

In discussing this with people, they often say that they would like  
the NodeID to be the same size of the 20-byte hash but I really don't  
understand the logic of that. We need the NodeID to be large enough  
that we don't run out of NodeID but 2^128 seems more than enough for  
nodes in a single overlay. Is there something I am missing here?

> a second flag, say REVERSE-LOG, which must/should be honored by all

good point, thanks for catching this, and I like your proposal - I'll  
see what my co-authors and others think and we can figure out how to  
change this.

> route-log exist; c) via/destination list starts at 32-bit boundary.

works for me - I'll see if we get any more thoughts on this ...

---

From: Michael Chen <[email-masked]>
Date: Wed, 18 Jun 2008 07:34:24 -0800

Cullen,

Having the same NodeId size on the wire as in computing memory makes 
programming much easier. Also, defining NodeID the same way as 
ResourceId makes this draft consistent, extensible, and again easy to 
implement:

    typedef  opaque  NodeId<0..2^8-1>
    typedef  opaque  ResourceId<0..2^8-1>

I know that having a variable NodeId may be confusing with the topology 
notation "chord-128-2-16+", but the draft could say that 
"chord-128-2-16+" means peers must guarantee the most significant 128 
bits of the SHA1 hash, or simply use the "chord-sha1-2-16+" notation.

Thanks

--Michael

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 18 Jun 2008 07:56:44 -0700

At Wed, 18 Jun 2008 07:34:24 -0800,
Michael Chen wrote:
> programming much easier.

Without addressing the generic question of whether NodeIds should be
variable length, I don't really think the appropriate size of NodeId
is that related to the size of the hash function you happen to be
using to convert Resource names to Resource-Ids.  Obviously, the size
of the hash function ought to be large enough to fill the entire
Resource/Node-Id space, but, the converse is not true. Moreover, the
cryptographic security requirements that dictate the current set of
hash function sizes aren't really the same as what we need here. If
you're using, say, SHA-256, it's trivial to have it emit a 128-bit
value simply by truncating. If you like, you can think of this as a
new hash function called "SHA-256-truncated-to-128".

-Ekr

---

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 18 Jun 2008 16:51:49 -0500

Eric,

Thanks for your post. I meant to ask you this question specifically, earlier 
today, and then got distracted.

Spencer

---

From: Bruce Davie <[email-masked]>
Date: Wed, 18 Jun 2008 18:05:30 -0400

Eric,
  Can you say why this statement is true:

> the
> hash function sizes aren't really the same as what we need here

Are you saying that collision resistance doesn't have to be that  
strong for NodeIDs?

Furthermore, by fixing the NodeID length at 128 bits, are you making  
a statement that there will never be a need for greater collision  
resistance?

Bruce Davie

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 18 Jun 2008 17:19:25 -0700

At Wed, 18 Jun 2008 18:05:30 -0400,
> a statement that there will never be a need for greater collision  

There are some separate issues here:
Node-Ids:
NodeIds aren't generated using the hash function, except in the
(basically unsafe) self-signed certificate mode. In the central
enrollment server mode, the enrollment server can easily ensure
uniqueness by simply keeping a table of all the ids it has issued.
Even if it didn't do that, getting a collision would presumably
require an impractical (order 2^64) queries to the enrollment server,
which you would think it would notice.

Even in the self-signed mode, it's not clear that collision
resistance is the relevant property, since a collision would
presumably let you generate multiple certificates for yourself
with the same NodeId. It's not clear that's useful, and 
since we base the NodeId on the public key anyway, and
there's no prohibition on using the same key for two certs.
So, even in this case, I think the relevant issue here is
preimage resistance, which, as you know, scales as 2^N rather
than 2^{N/2}.

Resource-Ids:
By contrast, resource-ids are generate by hash functions. 
However, again it's not clear that it's a useful attack
to generate two resource names that hash to the same
resource id, since that just creates a collision on your
own data. What you want again is a preimage so you can
attack someone else's data.

So, it may be the case that there's a collision attack, but
it's not clear to me what it is.

-Ekr

---

From: Bruce Davie <[email-masked]>
Date: Thu, 19 Jun 2008 08:26:57 -0400

Eric,
  A very helpful and clear answer, thanks.

Bruce