Subject: [secdir] secdir review of draft-moriarty-post-inch-rid-transport-02

From: Barry Leiba <[email-masked]>
Date: Thu, 15 Apr 2010 10:09:33 -0400

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

This document is going for Informational status, not Standards Track,
and yet defines a protocol layered over HTTP, using normative
language.  I have some concern about that -- we know how much
attention is often NOT paid to the distinction between Informational
and Standards Track.  Further, HTTP seems particularly ill-suited to
transporting this protocol... this seems another in the long line of
"use HTTP for everything" cases, which BCP 56 has tried
(unsuccessfully) to stave off.  The "callbacks", in particular, are
worrisome -- the payload has to contain all the state information, the
system doing the callback has to have the correct addresses of the
system that originally contacted it, and the whole thing is vulnerable
to asymmetry problems (firewalls, NAT, multi-homing, and so on; see
http://tools.ietf.org/id/draft-iab-ip-model-evolution-01.txt and Dave
Thaler's technical plenary presentation from IETF 73,
http://www.ietf.org/proceedings/73/plenaryw.html ).

At least it's not doing it over port 80.  :-)

-- 
Barry Leiba

---

From: Brian Trammell <[email-masked]>
Date: Mon, 19 Apr 2010 14:49:16 +0200

Hi, Barry,

Many thanks for your review! My response, in brief, would be, yes, we need to remove the 2119 language, but it is unclear what we should do instead of using HTTP as a substrate. Detailed responses inline, below.

Best regards,

Brian

> -----Original Message-----
> From: Barry Leiba [mailto:[email-masked]] 
> Sent: Thursday, April 15, 2010 10:10 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: secdir review of draft-moriarty-post-inch-rid-transport-02
> 
> language.

We've had the same issue when turning standards into guidelines in IPFIX
(when RFC5473 was first submitted to the IESG, it had a lot of 2119 language
in it). We presume that stripping 2119 refs and lowercasing everything
would be an acceptable solution here as well, but we've not done that
yet.

> I have some concern about that -- we know how much
> (unsuccessfully) to stave off.

We acknowledge as such, directly in the document. However, we cannot
ignore that for the types of data we're moving around, HTTP seems to be
pretty much the only base protocol we can extend that has the
implementation support and community understanding to get into
production quickly, in a way that's easy to integrate with the security
policies surrounding public-facing information services at most
organizations likely to be members of a RID consortium. 

BEEP was supposed to do this. It didn't. Shimming something like SOAP in
here is insanely complicated for what we're doing (indeed, the old
version of the document was SOAP based, and nobody liked it, least of
all the authors), and anyway still needs a transport binding. 

We could define something over bare sockets would end up for the most
part replicating what we've done with HTTP, but make the document much
longer and obscure the fact that we've taken most of the base
interaction from HTTP, thereby making it harder to implement. Given
these considerations, we consider HTTP the worst base protocol for RID,
except for all the others that have been implemented (more than once).

> The "callbacks", in particular, are

Given the arbitrary amount of time that a RID interchange might take
(minutes, hours, even days if there's human interaction involved and the
request is considered low-priority enough at the receiving end), any
transport for RID is going to have a callback mechanism anyway, unless
we want to force people to hold TCP sessions open for long periods,
which has its own problems. In a RID infrastructure, each consortium
member is expected to have a well-known, public-facing endpoint; getting
around the asymmetry problems is therefore considered a deployment-time
consideration. I suppose this could be made clearer in the document.