Subject: [P2PSIP] WG decisions and issues on RELOAD base draft from meeting

From: "David A. Bryan" <[email-masked]>
Date: Tue, 16 Nov 2010 14:53:42 -0500

At the meeting, the following issues were presented related to the
RELOAD base draft. As planned, I have cut and pasted the proposals
from Ekr's slides here to take the discussion to list.

Except as noted, there was no discussion on the issue in the meeting,
and unless there is list discussion, the proposals mentioned for the
open issues without discussion will be deemed as consensus (for the
TODOs noted, we assume they will be completed).

As the draft is very close to going to the editor, if you have issues,
speak up quickly!

David (as chair)

SLIDES/ISSUES WITH DISCUSSION/OPEN ISSUES RAISED FOR MAILING LIST

Direct Response Routing and ICE
• Specified in §5.3.2.4
This option can only be used if the direct-return-response-permitted
flag in the configuration for the overlay is set to TRUE. The
RESPONSE_COPY flag SHOULD be set to false while the FORWARD_CRITICAL
and DESTINATION_CRITICAL MUST be set to true. When a node that
supports this forwarding options receives a request with it, it acts
as if it had send an Attach request to the the requesting_node and it
had received the connection_information in the answer. This causes it
to form a new connection directly to that node.
• This doesn’t work with ICE because the sender of the request doesn’t
have your information
Proposed Resolution: DRR can only be used with No-ICE
***NOTE: This slide generated significant discussion in the meeting.
There were some comments that this was incomplete, and discussion of
moving this out of the base draft and into the relay/direct response
draft. ADDITIONAL DISCUSSION REQUIRED.

Join race condition I (Michael Chen)
• §9.4: – Step 7: routing table from AP → JP – Step 8: routing table
from AP → NP
• In some cases (e.g., Chord predecessors) this may cause simultaneous
connects between JP and it’s new neighbors
Proposed Resolution: Tiebreaker when multiple connections are
established between a pair of nodes. Terminate the connection
originating from the smaller Node-Id seems like a natural choice.
***NOTE: There was significant list discussion ongoing at the time
this slide was presented. Need to reach consensus on list for this
item.

Join Attach timing (Michael Chen)
• Proposal is to skip step 3 in which JP sends Attaches to its expected nodes.
• Argument for this is that the logic is simpler since no need to do
incremental probing.
• Argument against is that it then takes longer to get fully
established. Client has multiple ways to get AP’s routing table which
would allow unified logic for the neighbor set.
Proposed Resolution: Leave as-is but add discussion of the option to
get AP’s routing table rather than probe.
***NOTE: Ekr felt list discussion had overtaken the slide. Need to
discuss and resolve on list.

SLIDES/ISSUES WITH NO DISCUSSION/ISSUES RAISED IN MEETING:

Variable-length node-ids
• Enacts WG consensus
• Fixed per overlay
• Range of 16-20 bytes
• Set in configuration document

Non-TLS security modes
• Enacts WG consensus: (D)TLS for now with room for other prototocols in future
• Requirements for future link protocols in §5.6.1:
  – Endpoint authentication
  – Traffic origin authentication and integrity
  – Traffic confidentiality
• Set in configuration document

Direct Response Routing
• Permitted on a single overlay basis
• Set in configuration document

Minor Changes
• Provided a definition of AppAttachReq and AppAttachAns in §5.5.2.1
and 5.5.2.2.
• no ICE → NoICE
• Added a send_update flag to AttachReqAns to facilitate requests for
immediate updates

Minor Changes: RFC 2119 issues
• Removed MUST-level requirement for generation counter on opaque
Destination values as unenforceable [Eric Burger]
• Made setting FORWARD_CRITICAL and DESTINATION_CRITICAL MUST-level
with DirectResponseForwardingOption. (interop requirement)
• Recipients now MAY process messages with unknown non-critical
extensions (was SHOULD) [Eric Burger]
• Clarified what the MUST requirement is for processing Attach (you
can refuse and throw an error) [Eric Burger]
• Strengthened requirements on which STUN servers to use (MUST use one
from the same group) in §5.5.1.4.

Known Uncontroversial TODOs
• Add padding to PING to facilitate MTU discovery
• Rewrite/clarify leap-second text in §5.5.3.2

ICE: Nomination Level
• §5.5.1.10.2 formerly required regular nomination
  – Regular nomination is quite a bit slower than aggressive
  – There are already a lot of round-trips
• Original rationale was to ensure consistent state
  – Don’t believe this is needed: ICE naturally converges
Proposed Resolution: Leave as-is in the draft

Mandatory to Implement Signature/Hash Algorithms
• None specified
• Need some for interop
Proposed Resolution: RSA with SHA-256

Node-Ids in JOIN/LEAVE
• Currently JoinReq and LeaveReq have the joining Node-Id
struct { NodeId	joining_peer_id; opaque	overlay_specific_data<0..2^16-1>;
} JoinReq;
• This is unnecessary because the Node-Id is provided by the security block.
• Just one more thing to check
Proposed Resolution: It’s annoying but harmless, so in the interest of
compatibility leave it in but clarify that a check is required.

Specifying Counter Values for NODE-MULTIPLE §6.3.4:
In the NODE-MULTIPLE policy, a given value MUST be written (or
overwritten) if and only if the request is signed with a key
associated with a certificate containing a Node-ID such that H(Node-ID
|| i) is equal to the Resource-ID for some small integer value of i.
When this policy is in use, the maximum value of i MUST be specified
in the kind definition.
• i is not carried on the wire anywhere
• Maximum value is specified in the configuration document
• Possible approaches – Verifier iterates through i values (not that
slow but annoying) – Add syntax to carry i (kind of a gross special
case)
Proposed Resolution: Verifier iterates (with regrets)

Pings while Joining (§9.4)
• Current procedure requires sending Pings to populate the table (step 2)
• These are unnecessary since Attach automatically discovers the right node
Proposed Resolution: Remove Pings as proposed on-list by BBL (Nov 1)

---

From: Michael Chen <[email-masked]>
Date: Thu, 18 Nov 2010 15:21:16 -0800

Bruce and Eric,

I am submitting some proposed changes to the base-12 draft based on
the Attach Race Condition discussion as follows (leading "-" is
deletion, "+" is addition):

5.4.2.3. Update
    ...
    the state change.  In general, peers send Update messages to all
    their adjacencies whenever they detect a topology shift.
+
+  When a peer receives an Attach request with the send_update flag
+  set to "true" (see 5.5.1.1), it MUST send an Update message back
+  to the sender of the Attach request after the completion of the
+  corresponding ICE check and TLS connection. Note that the sender
+  of a such Attach request may not have joint the overlay yet.

5.5.1.2. Response Definition
-
-  If a peer receives an Attach request, it MUST process the request and
-  SHOULD generate its own response with a AttachReqAns.  A peer which
-  is overloaded or detects some other kind of error may of course
-  generate an error instead of an AttachReqAns.  It should then begin
-  ICE checks.  When a peer receives an Attach response, it SHOULD parse
-  the response and begin its own ICE checks.
+
+  If a peer receives an Attach request, it MUST determine how to process
+  the request as follows:
+
+  o  If it has not initiated an Attach request to the originating peer
+     of this Attach request, it MUST process this request and SHOULD
+     generate its own response with an AttachReqAns. It should then
+     begin ICE check.
+
+  o  If it has already sent an Attach request to and received the
+     response from the originating peer of this Attach request, and
+     as a as a result, an ICE check and TLS connection is in progress,
+     then it SHOULD generate an error instead of an AttachReqAns.
+     [[I suggest adding a new error number for this condition.]]
+
+  o  If it has already sent an Attach request to but not yet received
+     the response from the originating peer of this Attach request,
+     it SHOULD apply the tie-breaker heuristic to determine how to
+     handle this Attach request and the incomplete Attach request it
+     has sent out.
+
+     The tie-breaker heuristic is to compare the Node-IDs of both
+     peers as unsigned integers, and
+
+     *  If the peer's own Node-ID is smaller, it MUST cancel its
+        own incomplete Attach request. It MUST then process this
+        Attach request, generate an AttachReqAns response, and
+        proceed with the corresponding ICE check.
+
+     *  If the peer's own Node-ID is larger, it MUST generate an
+        error to this Attach request, then proceed to wait for
+        and complete the Attach and the corresponding ICE check
+        it has originated.
+
+  o  If the peer is overloaded or detects some other kind of error, it
+     may generate an error instead of an AttachReqAns.
+
+  When a peer receives an Attach response, it SHOULD parse
+  the response and begin its own ICE checks.

Feel free to change and discuss further.

Thanks

--Michael

On 11/16/2010 11:53 AM, David A. Bryan wrote:
> SLIDES/ISSUES WITH DISCUSSION/OPEN ISSUES RAISED FOR MAILING LIS
...
> this slide was presented. Need to reach consensus on list for this
...
> ______________________________________________
> P2PSIP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/p2psip

---

From: Michael Chen <[email-masked]>
Date: Thu, 18 Nov 2010 15:30:39 -0800

Hi,

I am still against keeping the Node-IDs in the JOIN/LEAVE message.
We are breaking compatibility with the PING message in base-12 draft.
Why not do the right thing and remove these two fields.  It will only
take about 10 minutes for a programmer to do this in any existing
implementations.

Thanks

--Michael

...
...
> _______________________________________________
> P2PSIP mailing list
> [email-masked]

---

From: Roni Even <[email-masked]>
Date: Sun, 21 Nov 2010 10:04:32 +0200

> draft. ADDITIONAL DISCUSSION REQUIRED.

I see the problem and think that we should take this section out from RELOAD and continue with the individual relay draft (draft-jiang-p2psip-relay-04) for the use case where the node is not behind NAT or a relay can be used.
In this case we will need to verify that RELOAD allows such extensions and that there are no issues with supporting it due to some routing assumptions.

Roni Even

---

From: "David A. Bryan" <[email-masked]>
Date: Tue, 30 Nov 2010 11:03:36 -0500

I also think the current text is too limiting. The best approach is to
make it clear in the draft that other routing techniques are allowed
and supported, leave in the flags but remove the very skeletal direct
response routing from this draft and we instead do that in the
relay/direct response draft.

David (as individual)