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

[Brian Trammell <[e-mail]>]

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:[e-mail]] 
> Sent: Thursday, April 15, 2010 10:10 AM
> To: [e-mail]
> Cc: [e-mail]; [e-mail]
> Subject: secdir review of draft-moriarty-post-inch-rid-transport-02
> 
> 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.

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
> 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.

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
> 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 ).

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.