Re: [secdir] secdir review of draft-ietf-mext-aero-reqs8
Jari Arkko <jari.arkko@piuha.net> Mon, 24 August 2009 10:48 UTC
Return-Path: <jari.arkko@piuha.net>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCA5928C1F1; Mon, 24 Aug 2009 03:48:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.68
X-Spam-Level:
X-Spam-Status: No, score=-2.68 tagged_above=-999 required=5 tests=[AWL=-0.308, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ukFP0lB8Yiva; Mon, 24 Aug 2009 03:48:32 -0700 (PDT)
Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 9F34828C1EF; Mon, 24 Aug 2009 03:48:31 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 89D3C198698; Mon, 24 Aug 2009 13:48:37 +0300 (EEST)
X-Virus-Scanned: amavisd-new at piuha.net
Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XJhJaMzWl6xW; Mon, 24 Aug 2009 13:48:37 +0300 (EEST)
Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 8BDE8198653; Mon, 24 Aug 2009 13:48:36 +0300 (EEST)
Message-ID: <4A927003.7050004@piuha.net>
Date: Mon, 24 Aug 2009 13:48:35 +0300
From: Jari Arkko <jari.arkko@piuha.net>
User-Agent: Thunderbird 2.0.0.23 (X11/20090817)
MIME-Version: 1.0
To: Sam Hartman <hartmans-ietf@mit.edu>
References: <tsl8whdqw9y.fsf@mit.edu>
In-Reply-To: <tsl8whdqw9y.fsf@mit.edu>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: draft-ietf-mext-aero-reqs@tools.ietf.org, mext-chairs@tools.ietf.org, iesg@ietf.org, secdir@ietf.org
Subject: Re: [secdir] secdir review of draft-ietf-mext-aero-reqs8
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Aug 2009 10:48:32 -0000
Thanks for your review, Sam. A few responses below: > However it is important to make sure that everyone involved > understands meeting these requirements alone without more general > security requirements would not produce an acceptable solution. If > the intent of this draft is to state all the requirements that mext > needs to consider in developing a solution that meets IETF standards > and that meets the needs of the air/space community, then it falls > significantly short. I don't think that is the intent though; I think > this is simply intended to be one stakeholder's input. Presumably, > even if we are only targeting deployment in air/space enviroments, we > will look at more general security and management requirements > necessary to make the technology deployable on the internet. If we're > all on the same page on that point, then this draft is fine. > You raise a valid point and I think we have it under control. But its actually a bit more complicated than what you state above. I have treated the document as an input from a particular stakeholder's perspective. I have assumed that there are more general protocol design and even security aspects that an actual solution should take into account. However, I do not necessarily believe that there is a single NEMO route optimization solution that should cater for everyone's needs. The group's charter was written with the assumption that there are different use cases and that their solutions might be different. For instance, federated tunnel servers advertising the same BGP space is likely a good match for the aeronautics requirements, as it can solve the continental dogleg routing problem. Its not clear that this solution solve every other application's NEMO RO problems, however. So, if and when we actually design a solution, I'd like that solution to be generally usable and be able to run on the Internet as well as in a closed ATC network. But the solution will probably still be limited to a particular type of movements, and be able to address only some of the needs for NEMO RO. Note that the group is probably not unanimous in these beliefs; at least in the past we've seen arguments favoring the construction of a solution that can handle everything. I just don't personally believe this is achievable. > I think the stated requirements seem reasonable. However, I'm not > actually sure that a solution exists as an extension to current basic > nemo. In particular, requirements about minimizing or avoiding custom > software may rule out nemo. However, perhaps I'm missing something. > The document obviously prefers solutions where as small number of components as possible is touched. However, I do not remember a statement that says no software is allowed (but maybe I missed it). In fact, you would assume that for any sort of route optimization, you have to touch at least your router. The document says: "The MRs and MNNs onboard a spacecraft are highly-customized computing platforms, and adding custom code or complex configurations in order to obtain NEMO RO capabilities is feasible, ... Since for ATS, the MRs and MNNs are under regulatory control and are actively tested and maintained, it is not completely unreasonable to assume that special patches or software be running on these devices to enable NEMO RO. In fact, since these devices are accessed by skilled technicians and professionals, it may tolerable be if some special configuration is required for NEMO RO. Of course simplicity in setup and configuration is highly preferable, however, and the desirable feature labeled "Des1" below in this document prefers solutions with lower configuration state and overhead. To minimize costs of ownership and operations, it is also highly desirable for only widely-available off-the-shelf operating systems or network stacks to be required, but not a full requirement. ... it is desirable that a NEMO RO solution be as simple to configure as possible ..." Jari
- [secdir] secdir review of draft-ietf-mext-aero-re… Sam Hartman
- Re: [secdir] secdir review of draft-ietf-mext-aer… Sam Hartman
- Re: [secdir] secdir review of draft-ietf-mext-aer… Davis, Terry L
- Re: [secdir] secdir review of draft-ietf-mext-aer… Jari Arkko
- Re: [secdir] secdir review of draft-ietf-mext-aer… Sam Hartman
- Re: [secdir] secdir review of draft-ietf-mext-aer… Davis, Terry L
- Re: [secdir] secdir review of draft-ietf-mext-aer… Stephen Kent
- Re: [secdir] secdir review of draft-ietf-mext-aer… Davis, Terry L