Re: Fwd: [Nea] Re: use of a design team to develop requirements
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Fwd: [Nea] Re: use of a design team to develop requirements



Keith Moore wrote:
>>   Which is why *informative* protocols are much more robust than ones
>> that perform queries.
> 
> the word "informative" seems rather vague.

  I'm trying to come up with useful vocabulary for behaviors that aren't
currently well described.

  What I mean is that many IETF protocols involve the client sending a
list of attributes/values to a server, which thinks about the data, and
sends a response.  I've called this "informative", in that the client
informs the server of what it has, and the server informs the client of
the response.

 PPP, RADIUS, and many other protocols work like this.  There is no
explicit query in the protocol (which is currently an ongoing problem in
RADIUS).  Contrast those protocols with LDAP or SQL, where the intent is
to permit nearly arbitrary queries.

> somehow I think the concept of a remediation network really should be
> out of scope for the NEA discussion.  we understand that this is one way
> that NEA might be used, of course, but the idea that there should be a
> separate remediation network seems very shortsighted from an
> architectural perspective.  also, in some cases (zero-day exploits)
> remediation may not be immediately possible.

  Yes.  Remediation can be done as part of gaining network access
(you're at patchlevel X?  Here's patch Y...), but existing network
access protocols can't carry arbitrary amounts of data.  So some kind of
network access is required to perform remediation, but they can't be
allowed on the network until they have gone through the remediation process.

  But I do *not* think it's desirable or even useful to design NEA such
that it can carry arbitrary amounts of data for remediation.  We already
have too many network protocols that have turned into IP tunnels.

  And for zero-day exploits, shutting down the network may be cheaper
than having it destroyed by an attacker.

  Alan DeKok.
--
  http://deployingradius.com       - The web site of the book
  http://deployingradius.com/blog/ - The blog

_______________________________________________
Nea mailing list
Nea at ietf.org
https://www1.ietf.org/mailman/listinfo/nea




Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.