[Anima-signaling] Comments needed: issues in draft-ietf-anima-grasp-09

[Brian E Carpenter <[e-mail]>]

This is a list of issues in draft-ietf-anima-grasp-09
that need to be resolved following Last Call.

It doesn't includes points in the reviews that describe
errors, omissions or clarifications. They will of course
be fixed.

Please comment quickly. After the Last Call officially closes,
I plan to send this to the WG list. I'd like to get a -10
version out by the end of next week, otherwise we miss the
deadline.

- Normative dependency on a draft.

We use CDDL which is still far from being a published
standards track RFC (draft-greevenbosch-appsawg-cbor-cddl).
This could hold up GRASP indefinitely.

Proposed resolution: add an appendix specifying only
the subset of CDDL we need. This has already been drafted
so is quite feasible to do quickly.

- Split the document? [Charlie Perkins]

"parts of the document seem more philosophical than
prescriptive... It should be considered to break the document
into a Requirements document and a more rigorously defined
protocol solution document."

Proposed resolution: writing a separate requirements document
was essentially excluded when the WG was chartered. Unless the
WG and AD want to backtrack on that, the proposed resolution
is to *not* do this. Of course, all the specific review comments
about non-rigorous text will be actioned.

- Clarify security [Charlie Perkins]

"In some
places, ACP seems to be mandated, and in other places that is relaxed
to mean "a sufficient security mechanism".  It would be better to
identify the security requirements, and put them unmistakably in the
Security Considerations section, which deserves to have teeth."

(and various detailed comments in the text)

Of course we will deal with the detailed comments. The larger
issue is whether we should move most of the security discussion
to the Security Considerations section.

Proposed resolution: *Waiting for WG Chair and AD guidance.*

- Characterization of routing protocols [Joel Halpern]

"Section 2.2 states that routing protocols mainly consider link
up/down and that "all nodes need a consistent view of the network
topology".  the first seems an over-generalization, ... The following
sentence about information not normally used also seems to be at odds
with current practice."

Proposed resolution: Update this text accordingly.

- Text on circular dependencies [Joel Halpern]

"Bullet 1 under SN7 in section 2.2  talks about the potential for
circular dependence, and then says that this protocol will not provide
any assistance for that...  If a single negotiation causes two dependent
negotiations, this would seem to have the potential to cause a work
explosion."

Correct, this is an issue with ASA design. But distributed negotiation
algorithms and distributed consensus algorithms are a field of study
in their own right. 

Proposed resolution: We should be more explicit that this is a complex
issue that is simply not handled by the GRASP layer and that must be
considered by ASA designers.

All the following issues are from Charlie Perkins (CEP):

- Text on multiple instances in section 3.2 and 3.3 

"  An autonomic node will normally run a single instance of GRASP, used
   by multiple ASAs.  However, scenarios where multiple instances of
   GRASP run in a single node, perhaps with different security
   properties, are not excluded.  In this case, each instance MUST
   listen independently for GRASP link-local multicasts in order for
   discovery and flooding to work correctly.

CEP: Better: should specify that each instance is activated by reception	
   of a single link-local multicast."

Every instance needs to receive all GRASP multicasts, so
the original statement is correct.
	
"Even better: specify that each instance should have its own IP address,	
and all addresses belong to the same link-local multicast group."

The sender of the multicast has no prior knowledge of the separate
instances. As far as Flood and Discover goes, they are all
treated the same, so they can all listen on a single address.

"  o  It is normally expected that a single main instance of GRASP will	
      exist in an autonomic node, and that the protocol engine and each	
      ASA will run as independent asynchronous processes.  However,	
      separate GRASP instances may exist for security-related reasons	
      (Section 3.5.2).	

CEP: Why does the number of instances of GRASP matter for this document??"

Because the secure bootstrap document will rely on this feature.

Proposed resolution: No changes.

- LL multicast security

"3.5.1.  Required External Security Mechanism	
		 		
The protocol SHOULD always run within a secure Autonomic Control	
Plane (ACP) [I-D.ietf-anima-autonomic-control-plane].  The ACP is	
assumed to carry all messages securely, including link-local	
multicast if possible.	

CEP: The clauses of the preceding sentence seem contradictory."

The ACP designers have assured us that with the ACP implemented
as a VFR instance, LL multicast will be secured. But indeed this
will not apply to the insecure GRASP instances mentioned in
the following section.

Proposed resolution: No change.

- Relay interfaces

"3.5.4.4.  Discovery Relaying	
		 		
A GRASP instance with multiple link-layer interfaces (typically	
running in a router) MUST support discovery on all interfaces.  We	
refer to this as a 'relaying instance'.	

CEP: This seems to be a mistake.  Why shouldn't a device be allowed to	
have non-participating interfaces?"

Correct, a *device* could have non-participating interfaces.
So we are referring to interfaces used by the GRASP instance,
not the device as a whole.

Proposed resolution: Clarify the text (here and elsewhere)

- Discovery replies

"The relayed discovery message MUST have the same Session ID as the	
incoming discovery message and MUST be tagged with the IP address of	
its original initiator (see Section 3.8.4).  Note that this initiator	
address is only used to allow for disambiguation of the Session ID	
and is never used to address Response packets.	

CEP: But, section 3.8.5.  Discovery Response Message has:	
>   It is sent to the sender of the Discovery message via TCP at the port	
>   used to send the Discovery message (as explained in Section 3.8.4).	
Wouldn't this allow the Response to be sent to the initiator?"

The text is unclear. Relaying a discovery breaks the chain; the relay
is acting as a proxy, when I think about it. So the relayed discovery
message is sourced from an {address,port} that is specific to the
relay. It might even be a link-local address, if for some reason there
is no global unicast address in place.

Proposed resolution: Clarify the text (that will also cover
Charlie's other comments on the same subsection).

- Flood relays

"3.5.6.1.  Flooding
...
A GRASP device with multiple link-layer interfaces (typically a	
router) MUST support synchronization flooding on all interfaces.  If	
it receives a multicast Flood Synchronization message on a given	
interface, it MUST relay it by re-issuing a Flood Synchronization	
message on its other interfaces.  The relayed message MUST have the	
same Session ID as the incoming message and MUST be tagged with the	
IP address of its original initiator.
	
CEP: I am pretty sure this is a mistake."

Why, please? Running code says it works fine.

Proposed resolution: No change.

"3.8.13.  No Operation Message	
		 		
In fragmentary CDDL, a No Operation message follows the pattern:	
		 		
noop-message = [M_NOOP]	
		 		
This message MAY be sent by an implementation that for practical	
reasons needs to activate a socket.  It MUST be silently ignored by a	
recipient.	

CEP: ?? what does it mean to "activate" a socket?  Is there something about	
how long a socket may remain open but not used?"

Not that I know of. But I discovered that to find out the port number
assigned to a socket, you pretty much have to perform sendto() and
getsockname(), so the ability to send a no-op during initialisation
seemed reasonable. I could have just sent a zero, but a well-defined
message seemed better.

Proposed resolution: No change.

- Addressing realms

"3.9.5.  Locator Options
...
Note: It is assumed that all locators are in scope throughout the	
GRASP domain.  GRASP is not intended to work across disjoint	
addressing or naming realms.
	
CEP: It's hard to imagine the practical effect of making this statement."

This is where we point someone who says "NAT breaks my GRASP".

Proposed resolution: No change.

- Loop-count

"The 'loop-count' field is used for terminating negotiation as	
described in Section 3.8.7.  It is also used for terminating	
discovery as described in Section 3.5.4, and for terminating flooding	
as described in Section 3.5.6.1.
	
CEP: It would be much more intuitive to put "loop-count" in the message format."

>From the protocol designer's view, perhaps. But the application
programmer should think in terms of objectives, and the natural
place to set or read the loop count is in the objective.	

Proposed resolution: No change.

- Null objective value

"3.10.3.  General Considerations for Objective Options
...
If there is no initial value,
the bits in the value field SHOULD all be set to indicate a
meaningless value, unless this is inappropriate for the specific
negotiation objective.
	
CEP: Maybe better to require such objective descriptions to mandate a	
particular O_INVALID_VALUE, whenever needed."

Actually it seems that we should simply specify CBOR's 'null' value
('None' for Python addicts). No need to reinvent the wheel.

Proposed resolution: specify 'null'.

- Dry run flaw?

"CEP: Dry Run has a significant flaw.  Namely, it appears to be stateless,	
so that subsequent simulation steps would not be acting in the	
stateful environment that a true negotiation (or true simulation)	
would be."

Whether it's stateless is an implementation issue in the ASAs that support
it. That does indeed require discussion, but probably in another draft:
draft-carpenter-anima-asa-guidelines

Proposed resolution: add a health warning here, discuss the issue elsewhere.

(ends)