Subject: [Anima] Spencer Dawkins' No Objection on draft-ietf-anima-grasp-11: (with COMMENT)

From: Spencer Dawkins <[email-masked]>
Date: Sun, 07 May 2017 19:41:40 -0700

Spencer Dawkins has entered the following ballot position for
draft-ietf-anima-grasp-11: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-anima-grasp/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

In this text,

   T6.  The protocol must be capable of supporting multiple
simultaneous
   operations with one or more peers, especially when wait states
occur.

I understand every word, but I'm not sure what this requires the protocol
to do. Are you asking that the protocol be non-blocking? But that's a
guess.

In this text,

   A GRASP implementation will be part of the Autonomic Networking
   Infrastructure in an autonomic node, which must also provide an
   appropriate security environment.  In accordance with
   [I-D.ietf-anima-reference-model], this SHOULD be the Autonomic
   Control Plane (ACP) [I-D.ietf-anima-autonomic-control-plane].  

I wonder what happens if the security environment isn't the ACP. Is that
obvious?

In this text,

   An implementation MUST support use of TCP.
   It MAY support use of another transport protocol.  However, GRASP
   itself does not provide for error detection or retransmission.  Use
   of an unreliable transport protocol is therefore NOT RECOMMENDED.

just to educate me, is the strategy here, that (for instance) if
synchronization fails over an unreliable transport protocol, that
eventually it will be attempted again, just because the two ACAs know
they aren't synchronized?

I'm really confused by this text.

   Nevertheless, when running within a secure ACP on reliable
   infrastructure, UDP MAY be used for unicast messages not exceeding
   the minimum IPv6 path MTU; however, TCP MUST be used for longer
   messages.  In other words, IPv6 fragmentation is avoided.  If a node
   receives a UDP message but the reply is too long, it MUST open a TCP
   connection to the peer for the reply.  Note that when the network is
   under heavy load or in a fault condition, UDP might become
   unreliable.  Since this is when autonomic functions are most
   necessary, automatic fallback to TCP MUST be implemented.  The
   simplest implementation is therefore to use only TCP.

We've been having quite the discussion about how well Path MTU Discovery
works, even in IPv6. Because GRASP could be running over virtual
interfaces, I suspect there's a chance that you'll be running in a tunnel
that will give you a Path MTU that's smaller than the IPv6 minimum. But
ignoring that for now ...

IIRC, we've had poor experiences with protocols that are expected to
switch from UDP transport to TCP transport in the middle of a
request/response pair. But, setting THAT aside for now ...

This text correctly points out that UDP transport is most likely to fail
under heavy network load or in a fault condition, when autonomic
functions are most necessary. If TCP is mandatory to implement, and
implementations will need to switch from UDP to TCP at the most awkward
times, and that's been a problem area for other protocols in the past,
why not just require TCP in the first place?

I see that the UDP/TCP question was listed as an open issue before it was
closed, so I'm not balloting Discuss, because I assume I'm missing
something that people will help me understand, but I thought about it for
a while ...

Thanks for this text,

   If no discovery response is received within a reasonable timeout
   (default GRASP_DEF_TIMEOUT milliseconds, Section 3.6), the Discovery
   message MAY be repeated, with a newly generated Session ID
   (Section 3.7).  An exponential backoff SHOULD be used for subsequent
   repetitions, to limit the load during busy periods.  Frequent
   repetition might be symptomatic of a denial of service attack.

and especially for the warning about DoS attacks.

I found Appendix D and E useful. Thanks for including both of them.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 9 May 2017 15:38:34 +1200

> draft-ietf-anima-grasp-11: No Objection
...
> to do. Are you asking that the protocol be non-blocking? But that's a

The practical implication is that we need session IDs, so that overlapping
operations can be distinguished. It's a bit over-simplified to call it
non-blocking - for example discover/discovery response looks like a
blocking call with timeout in the API, but the underlying messages are
atomic.

> I wonder what happens if the security environment isn't the ACP. Is that

Hopefully https://tools.ietf.org/html/draft-ietf-anima-grasp-11#section-3.5.1
explains this.

> they aren't synchronized?

Actually even 'reliable' transports can fail on occasion, so I'd say
that an implementation should *always* wait and retry. UDP just makes
it all harder.

> why not just require TCP in the first place?

Personally (editor hat off) I would eliminate UDP completely except for
the multicasts, but there are others who believe that UDP has its place.
So I guess this is compromise text. I'll be interested to see if anybody
can make a UDP variant work robustly.

> I found Appendix D and E useful. Thanks for including both of them.

Thanks for the comments.

     Brian

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 9 May 2017 12:13:54 -0500

Hi, Brian,

> blocking call with timeout in the API, but the underlying messages are

Your explanation helped me understand a lot.

Could I suggest something like

OLD

T6.  The protocol must be capable of supporting multiple simultaneous
operations with one or more peers, especially when wait states occur.

New

T6.  The protocol must be capable of distinguishing multiple simultaneous
operations with one or more peers, especially when wait states occur.

(using the word "distinguishing" from your explanation that lifted my fog)

> Hopefully https://tools.ietf.org/html/draft-ietf-anima-grasp-11#

It does, but that nudges me to ask another question.

I'm looking at

3.2.  High Level Deployment Model

and

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 when it is virtualized over the ACP.  A GRASP instance MUST
   verify whether the ACP is operational.

   If there is no ACP, one of the following alternatives applies:

Are those SHOULDs saying the same thing using different words?

Assuming so ... probably the easiest change that would have clued me in,
would be to say (in 3.2) something like

3.2.  High Level Deployment Model

   If there is no ACP, the considerations described in Section 3.5.1
   apply.

as a forward pointer.

You could likely link these two thoughts together in a better way, but I
hope you see what I'm suggesting.

> that an implementation should *always* wait and retry. UDP just makes

Grrr, but please see below.

> > something that people will help me understand, but I thought about it for

Continued from "grrr" above ...

I'm muttering to myself, "This looks like the working group is choosing to
drag the same kind of weird corner cases SIP applications have when they're
written to run over both TCP and UDP into 21st century applications, except
that these applications can be misconfiguring networks at scale when they
get something wrong, rather than just keeping us from completing a VoIP
call."

Having muttered that to myself, I re-read
https://www.ietf.org/iesg/statement/discuss-criteria.html, and can't decide
whether I'm muttering about something that's closer to the Discuss criteria

"The protocol has technical flaws that will prevent it from working
properly, or the description is unclear in such a way that the reader
cannot understand it without ambiguity"

or the Discuss NON-criteria

"Disagreement with informed WG decisions that do not exhibit problems
outlined in Section 3.1 (DISCUSS Criteria). In other words, disagreement in
preferences among technically sound approaches."

Unfortunately, "this is likely to blow up badly" doesn't obviously fall
into either bucket.

So, I'll leave this as a Comment, and let the many folks who see IESG
ballot positions these days think about this, and either tell me that this
isn't a problem, or that it is. Several of them have more relevant
experience with application protocols that use multiple transports than I
do.

Alternatively, perhaps providing a DNS-style "TrunCation" indicator (as in
https://www.ietf.org/rfc/rfc1035.txt) and letting applications retry using
TCP would be useful.

But, do the right thing, whether I think it's the right thing or not, of
course.

> > I found Appendix D and E useful. Thanks for including both of them.

It's always a pleasure :-)

Spencer

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 10 May 2017 14:49:28 +1200

Spencer,
On 10/05/2017 05:13, Spencer Dawkins at IETF wrote:

<snip> The bits where we can simply do what you suggest </snip>

>>>    simplest implementation is therefore to use only TCP.

Editor hat off.

I agree. I think it's very naive to think that for this application,
intended to be used internally within an enterprise network, in
a NAT-free and proxy-free addressing realm, UDP has any value.
In fact, it's just a nuisance, since the programmer has to do a lot
of the work that TCP does. The performance gain, even if it's real,
is unimportant - autonomic traffic will be a tiny fraction of total
traffic. There will be no gain in footprint, since autonomic nodes
will carry full TCP stacks anyway. [If we wanted to put GRASP in
constrained nodes, we'd probably be talking about GRASP-over-COAP
anyway.] So here's what I would do:

OLD
   All other GRASP messages are unicast and could in principle run over
   any transport protocol.  An implementation MUST support use of TCP.
   It MAY support use of another transport protocol.  However, GRASP
   itself does not provide for error detection or retransmission.  Use
   of an unreliable transport protocol is therefore NOT RECOMMENDED.

NEW
   All other GRASP messages are unicast and could in principle run over
   any transport protocol.  An implementation MUST support use of TCP.
   It MAY support use of another transport protocol, but the details
   are out of scope for this specification. However, GRASP itself does
   not provide for error detection or retransmission.  Use of an
   unreliable transport protocol is therefore NOT RECOMMENDED.
END NEW

That doesn't slam the door, but it removes what I now feel is
a very misleading paragraph. Of course, anybody is at liberty to
draft a full description of GRASP-over-UDP as a separate 
document.

Again, that was personal opinion. I won't edit that part of
the draft without community input.

    Brian

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 10 May 2017 07:34:25 -0500

Hi, Brian,

> the draft without community input.

Thanks, and I agree with not making changes unless there's community
agreement.

I do suspect that if UDP is not at least NOT RECOMMENDED, some developers
may not use TCP at all. A quick Google search turned up e-mail from 2015
asking "if we REALLY have to support TCP in our (micro-)DNS server", and
TCP to accommodate response TrunCation has been a requirement for DNS since
at least RFC 1035 in 1987.

But I don't know the future, of course. :D

Spencer

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 16 May 2017 08:30:12 +1200

Hi Anima WG (only),

We need to resolve this issue quickly, to get a new draft out in the next
few days, before the IESG meeting next week.

So, since I haven't seen any opinions on the issue below, I propose to
delete the UDP paragraph as suggested below. Note that this does not
prevent us adding a UDP mode later, but it removes the confusion that we
have in the text today.

If you don't agree please send alternative text in the next 24 hours.

(Also see: https://www.ietf.org/mail-archive/web/ops-dir/current/msg02653.html )

Regards
   Brian

---

From: William Atwood <[email-masked]>
Date: Mon, 15 May 2017 17:05:40 -0400

I strongly agree with the proposed change.

  Bill Atwood

On 15/05/2017 4:30 PM, Brian E Carpenter wrote:
> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima
> 

-- 

Dr. J.W. Atwood, Eng.             tel:   +1 (514) 848-2424 x3046
Distinguished Professor Emeritus  fax:   +1 (514) 848-2830
Department of Computer Science
   and Software Engineering
Concordia University EV 3.185     email:[email-masked]
1455 de Maisonneuve Blvd. West    http://users.encs.concordia.ca/~bill
Montreal, Quebec Canada H3G 1M8

---

From: Michael Richardson <[email-masked]>
Date: Wed, 17 May 2017 14:04:53 -0400

> prevent us adding a UDP mode later, but it removes the confusion that we

So, we will (initially) support UDP for multicasted Link-Layer M_FLOOD and
M_DISCOVER, but that's all.  Everything else will be TCP.

(In my opinion, inside the point to point mesh ACP, one might as well keep a
single TCP connection up for every M_DISCOVER and M_FLOOD, as UDP has no
advantage there)

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 18 May 2017 08:58:29 +1200

> M_DISCOVER, but that's all.  Everything else will be TCP.

Until we write a profile for GRASP-over-UDP or GRASP-over-DECnet or whatever
we want. The GRASP protocol model doesn't really care.

> single TCP connection up for every M_DISCOVER and M_FLOOD, as UDP has no

As long as it behaves like a multicast, it really doesn't matter how the
ACP chooses to implement it. For a stand-alone specification of GRASP,
I don't see how else to specify it, though.

    Brian