Re: [secdir] secdir review of draft-templin-aero-10

Sean Turner <turners@ieca.com> Wed, 25 April 2012 19:12 UTC

Return-Path: <turners@ieca.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8050C21F8940 for <secdir@ietfa.amsl.com>; Wed, 25 Apr 2012 12:12:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.97
X-Spam-Level:
X-Spam-Status: No, score=-100.97 tagged_above=-999 required=5 tests=[AWL=-1.105, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_25=0.6, J_CHICKENPOX_27=0.6, J_CHICKENPOX_28=0.6, J_CHICKENPOX_75=0.6, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vT+cjXgHFyF0 for <secdir@ietfa.amsl.com>; Wed, 25 Apr 2012 12:12:16 -0700 (PDT)
Received: from gateway03.websitewelcome.com (gateway03.websitewelcome.com [67.18.34.22]) by ietfa.amsl.com (Postfix) with ESMTP id 75B7821F8910 for <secdir@ietf.org>; Wed, 25 Apr 2012 12:12:16 -0700 (PDT)
Received: by gateway03.websitewelcome.com (Postfix, from userid 5007) id 0565144D7B273; Wed, 25 Apr 2012 14:12:16 -0500 (CDT)
Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway03.websitewelcome.com (Postfix) with ESMTP id EE7C444D7B249 for <secdir@ietf.org>; Wed, 25 Apr 2012 14:12:15 -0500 (CDT)
Received: from [96.231.123.106] (port=39810 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <turners@ieca.com>) id 1SN7dO-00070I-Ks; Wed, 25 Apr 2012 14:12:15 -0500
Message-ID: <4F984C8D.7020505@ieca.com>
Date: Wed, 25 Apr 2012 15:12:13 -0400
From: Sean Turner <turners@ieca.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: Fred Templin <fltemplin@yahoo.com>
References: <36214B77-821E-47B9-8349-A89D2800E24C@cisco.com> <1335199956.12137.YahooMailNeo@web161604.mail.bf1.yahoo.com> <94CFA5A8-1D03-4BA2-993E-073B523538D7@cisco.com> <1335291276.47915.YahooMailNeo@web161603.mail.bf1.yahoo.com> <FBAF9900-9778-421A-8563-85806E97A47C@cisco.com>
In-Reply-To: <FBAF9900-9778-421A-8563-85806E97A47C@cisco.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - gator1743.hostgator.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - ieca.com
X-BWhitelist: no
X-Source:
X-Source-Args:
X-Source-Dir:
X-Source-Sender: pool-96-231-123-106.washdc.east.verizon.net (thunderfish.local) [96.231.123.106]:39810
X-Source-Auth: sean.turner@ieca.com
X-Email-Count: 1
X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20=
Cc: "draft-templin-aero.all@tools.ietf.org" <draft-templin-aero.all@tools.ietf.org>, The IESG <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [secdir] secdir review of draft-templin-aero-10
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Wed, 25 Apr 2012 19:12:17 -0000

On 4/24/12 6:55 PM, Joe Salowey wrote:
>
> On Apr 24, 2012, at 11:14 AM, Fred Templin wrote:
>
>> Hello Joe,
>>
>> Thank you for your comments. To your question on specifying a digital
>> signing mechanism, would the concern be addressed if I were to say
>> something like: "e.g., using IPsec AH, etc." ?
>>
> [Joe] Not really.  What I'm looking for is something that specifies the mechanism and how its used.  Something like
>
> "Implementations MUST support<IPSEC AH>  as a means to authenticate the origin of the AERO messages.  AERO peers MUST support establishing an<IPSEC SA>  using<IKEv2>  with<certificates>  as specified in<external reference>.   During<SA>  establishment AERO hosts MUST be able identify AERO intermediate routers through mechanism defined in<RFCxxxx or section y.yy>.  "
>
> The stuff in the<>  should be replaced with something that makes sense.  I'm not sure that IPSEC AH or any of the other things in<>  are really appropriate in this case.  The idea here is that there is some minimum mechanism that implementations can use to secure these messages. Securing the messages involves the transform for authenticating the messages (perhaps IPSEC AH), mechanism for key management perhaps (IKV2 with certificates) and a way to establish that you are taking to the right router (perhaps be able to match a field in a certificate to a particular name or domain).   My hope is that there already is something that would fit the bill and we could just reference that specification.  Some of the SEND variants may be useful in this scenario,  but I didn't get a chance to dig into this.

Fred,

Note that every so often somebody tries to deprecate AH because very few 
folks use it.

spt

> Joe
>
>
>> Fred
>> fltemplin@acm.org
>>
>> ----- Original Message -----
>>> From: Joe Salowey<jsalowey@cisco.com>
>>> To: Fred Templin<fltemplin@yahoo.com>
>>> Cc: "secdir@ietf.org"<secdir@ietf.org>; The IESG<iesg@ietf.org>rg>; "draft-templin-aero.all@tools.ietf.org"<draft-templin-aero.all@tools.ietf.org>
>>> Sent: Tuesday, April 24, 2012 10:47 AM
>>> Subject: Re: secdir review of draft-templin-aero-10
>>>
>>> T hanks for the quick response, comments inline:
>>> On Apr 23, 2012, at 9:52 AM, Fred Templin wrote:
>>>
>>>> (Resending with comments as inline text)
>>>>
>>>> Hello Joe,
>>>>
>>>> Thank you for these comments. Please see below for my proposed
>>>> resolutions:
>>>>
>>>> Fred
>>>> fltemplin@acm.org
>>>>
>>>> From: Joe Salowey<jsalowey@cisco.com>
>>>> To: secdir@ietf.org; The IESG<iesg@ietf.org>rg>;
>>> draft-templin-aero.all@tools.ietf.org
>>>> Sent: Sunday, April 22, 2012 3:00 PM
>>>> Subject: secdir review of draft-templin-aero-10
>>>>
>>>> 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.
>>>>
>>>> I apologize for the delay in getting this review out.  Hopefully it is
>>> still useful.
>>>>
>>>> This first set of comments is primarily for the authors.
>>>>
>>>> 1. In section 4.4.4 on Data origin authentication the last paragraph states
>>> that only the 3rd of the above conditions is acceptable, do you really mean the
>>> 4th?
>>>>
>>>>>>> Begin FLT response
>>>> You are correct; this should say the 4th and can be fixed in the next
>>> version.
>>>>>>> End FLT response
>>>>
>>>
>>> [Joe] OK
>>>
>>>> 2. In section 4.4.4 there is reference to the packet including a digital
>>> signature to authenticate the origin.  What is the signature mechanism?  Is this
>>> SEND or something different? I did not see a reference to it.
>>>>
>>>>>>> Begin FLT response
>>>> The digital signature mechanism is out of scope for this document. The text
>>>> could be adjusted to say: “…, AERO nodes may be obliged to require the
>>>> use of digital signatures applied through means outside the scope of this
>>>> document.”
>>>>>>> End FLT response
>>>>
>>>
>>> [Joe] I was hoping that something would be specified for interoperability,  I
>>> think there are many cases where you would have to resort to a signing
>>> mechanism, however it may be the case that AERO may be deployed where spoofing
>>> of messages is not a concern (perhaps this should be the recommendation until a
>>> signing mechanism is specified).  The ADs can decide if this is an issue or not.
>>>
>>>> 3. The security considerations do not say much about the consequences of
>>> trusting an inappropriate intermediate router, ingress node or egress node.
>>> Clearly DOS to the ingress node is a possibility.  Data modification and
>>> disclosure can be a goal of an attacker who tries to control the routing.  Are
>>> there other issues the reader should be aware of (perhaps other DOS attacks such
>>> as amplification attacks).  Anything outside the considerations of RFC4861)?
>>>>
>>>>>>> Begin FLT response
>>>> Proposed resolution is to re-write the first paragraph of Section 6 as
>>> follows:
>>>>
>>>> “AERO link security considerations are the same as for standard IPv6
>>> Neighbor Discovery
>>>> (RFC4861) except that AERO improves on some aspects. In particular, AERO is
>>> dependent
>>>> on a trust basis between AERO edge nodes and intermediate routers, where
>>> the edge nodes
>>>> must only engage in the AERO mechanism when it is facilitated by a trusted
>>> intermediate
>>>> router.”
>>>>>>> End FLT response
>>>>
>>>
>>> [Joe] OK thanks.
>>>
>>>> 4. The security consideration section indicates that spoofing protection
>>> can be provided by links that provide link layer security mechanisms.    Link
>>> Layer security mechanisms may or may not help.  I believe more information is
>>> needed here.  L2 mechanisms may not provide adequate protection of upper layer
>>> address bindings.  In some cases L2 mechanisms do not provide source origin
>>> authentication such as multicast  traffic protected with the group  key in WiFi
>>> and group security associations in 802.1AE (MACSEC).
>>>>
>>>>>>> Begin FLT response
>>>> Proposed resolution is to re-write the second paragraph of Section 6 as
>>> follows:
>>>> “AERO links must be protected against spoofing attacks in which an attacker
>>>> on the link pretends to be a trusted neighbor.  Links that provide
>>> link-layer
>>>> securing mechanisms (e.g., WiFi networks) and links that provide physical
>>>> security (e.g., enterprise network LANs) provide only a fist-line of
>>> defense.
>>>> In some instances, therefore, additional securing assurances against
>>> on-link
>>>> spoofing attacks are required. For example, if the source can through some
>>>> means digitally sign its messages the destination can verify the signatures
>>> to
>>>> ensure data origin authentication. Exact mechanisms for digitally signing
>>> and
>>>> verifying signatures are outside the scope of this document.”
>>>>>>> End FLT response
>>>>
>>> [Joe] Thanks. (same comment on the specification of the signing mechanism as
>>> above).
>>>
>>>> This set of comments is mostly for the area directors:
>>>>
>>>> 1. I am mostly concerned about the lack of definition for the digital
>>> signature mechanism.  Perhaps this is easily rectified by a reference to an
>>> existing specification. Its not clear to me what the specification would be
>>> (perhaps SEND??)?  Is something needed in addition?
>>>> 2.  The risks of not securing the proposal are not defined in the security
>>> considerations section. I think this would be helpful, but may not be strictly
>>> necessary.  There is some mention of Link-Layer security helping in some aspects
>>> of this, but its not clear on what characteristics the lower layer security
>>> needs to provide.
>>>>
>>>> Cheers,
>>>>
>>>> Joe
>>>>
>>>
>
> _______________________________________________
> secdir mailing list
> secdir@ietf.org
> https://www.ietf.org/mailman/listinfo/secdir
> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview
>