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

Sam Hartman <> Mon, 24 August 2009 12:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9FDB228C1B8; Mon, 24 Aug 2009 05:33:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.147
X-Spam-Status: No, score=-2.147 tagged_above=-999 required=5 tests=[AWL=-0.109, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, SARE_SUB_OBFU_Q1=0.227]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8emHChWl9q3P; Mon, 24 Aug 2009 05:33:28 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id BBD1A28C12B; Mon, 24 Aug 2009 05:33:28 -0700 (PDT)
Received: by (Postfix, from userid 8042) id 9E84864673; Mon, 24 Aug 2009 08:33:28 -0400 (EDT)
To: Jari Arkko <>
References: <> <>
From: Sam Hartman <>
Date: Mon, 24 Aug 2009 08:33:28 -0400
In-Reply-To: <> (Jari Arkko's message of "Mon\, 24 Aug 2009 13\:48\:35 +0300")
Message-ID: <>
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Cc:,, Sam Hartman <>,,
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 12:33:29 -0000

>>>>> "Jari" == Jari Arkko <> writes:

    Jari> 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
    Jari> actually a bit more complicated than what you state above.

    Jari> I have treated the document as an input from a particular
    Jari> stakeholder's perspective. I have assumed that there are
    Jari> more general protocol design and even security aspects that
    Jari> an actual solution should take into account.

    Jari> However, I do not necessarily believe that there is a single
    Jari> NEMO route optimization solution that should cater for
    Jari> everyone's needs. The group's charter was written with the
    Jari> assumption that there are different use cases and that their
    Jari> solutions might be different. For instance, federated tunnel
    Jari> servers advertising the same BGP space is likely a good
    Jari> match for the aeronautics requirements, as it can solve the
    Jari> continental dogleg routing problem. Its not clear that this
    Jari> solution solve every other application's NEMO RO problems,
    Jari> however.

I think some of this discussion took place while I was still on the
IESG.  Regardless, I was definitely aware that there would be multiple
solutions for different use cases; I was basically trying to capture
what you say above.  So, what you're thinking is definitely in
alignment with what I was thinking when I wrote my review.