Re: [secdir] secdir review of draft-ietf-mext-aero-reqs8

Jari Arkko <> Mon, 24 August 2009 10:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CCA5928C1F1; Mon, 24 Aug 2009 03:48:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.68
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ukFP0lB8Yiva; Mon, 24 Aug 2009 03:48:32 -0700 (PDT)
Received: from ( [IPv6:2001:14b8:400::130]) by (Postfix) with ESMTP id 9F34828C1EF; Mon, 24 Aug 2009 03:48:31 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 89D3C198698; Mon, 24 Aug 2009 13:48:37 +0300 (EEST)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (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 (Postfix) with ESMTP id 8BDE8198653; Mon, 24 Aug 2009 13:48:36 +0300 (EEST)
Message-ID: <>
Date: Mon, 24 Aug 2009 13:48:35 +0300
From: Jari Arkko <>
User-Agent: Thunderbird (X11/20090817)
MIME-Version: 1.0
To: Sam Hartman <>
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [secdir] secdir review of draft-ietf-mext-aero-reqs8
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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 ..."