Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2?

Joe Touch <touch@isi.edu> Sat, 04 June 2011 21:40 UTC

Return-Path: <touch@isi.edu>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A10421F84DA for <sidr@ietfa.amsl.com>; Sat, 4 Jun 2011 14:40:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -98.181
X-Spam-Level:
X-Spam-Status: No, score=-98.181 tagged_above=-999 required=5 tests=[MIME_QP_LONG_LINE=1.819, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uf5xt2kt8E14 for <sidr@ietfa.amsl.com>; Sat, 4 Jun 2011 14:40:41 -0700 (PDT)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 84C8D21F84D9 for <sidr@ietf.org>; Sat, 4 Jun 2011 14:40:38 -0700 (PDT)
Received: from [10.48.163.99] (166-205-138-147.mobile.mymmode.com [166.205.138.147] (may be forged)) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id p54E2W2A016265 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 4 Jun 2011 07:02:49 -0700 (PDT)
References: <4DAF44AC.8060408@isi.edu> <E3076C4C-F27C-40A8-A033-2EBB8C39A3D2@cisco.com> <4DAF796C.7010807@isi.edu> <BANLkTi=Oc-fEKOYCRQqM97wPxSSXjrdTRw@mail.gmail.com> <409BDC5C-FE86-444A-BC0D-6DA00E7BF0F3@isi.edu> <BANLkTikLi2p7UipJ!TRSQqVOL6GkLn=j9iA@mail.gmail.com> <F0FABE61-FC1D-45ED-A21D-ED7A1228A997@isi.edu> <01eb01cc0325$6e4fd260$4001a8c0@gateway.2wire.net> <4DB592B3.3090805@isi.edu> <033e01cc05a8$0a82f160$4001a8c0@gateway.2wire.net> <4DB9A456.3060709@isi.edu> <BANLkTikg18FV5H0bOdOfWMzpTcm_B__EVQ@mail.gmail.com> <017b01cc13ff$0cb6da40$4001a8c0@gateway.2wire.net> <BANLkTink82qvhge6rRhqt5+h-2mEkKBMhA@mail.gmail.com> <m21uzwr3tw.wl%randy@psg.com> <BANLkTimPnMfE1ii=6uwAckoFY0yUU=w43g@mail.gmail.com> <BANLkTinu8pxxCj4cdJzbS3z5h=8=s+U3Gw@mail.gmail.com> <D1D8138DDF34B34B8BC68A11262D10790F6233E006@EUSAACMS0701.eamcs.ericsson.se> <Pine.WNT.4.64.1106031624560.2148@SMURPHY-LT.columbia.ads.sparta.com> <D1D8138DDF34B34B8BC68A11262D10790F6233E04A@EUSAACMS0701.eamcs.ericsson.se> <B! ANLkTi=OcqYbBReP+F+6e+mdqySEWPkq4Q@mail.gmail.com> <D1D8138DDF34B34B8BC68A11262D10790F6233E0E3@EUSAACMS0701.eamcs.ericsson.se> <BANLkTikqeHdq15P7yC1A6owtrKGBWQsKkQ@mail.gmail.com>
In-Reply-To: <BANLkTikqeHdq15P7yC1A6owtrKGBWQsKkQ@mail.gmail.com>
Mime-Version: 1.0 (iPhone Mail 8J2)
Content-Type: text/plain; charset="us-ascii"
Message-Id: <1F1804CA-BC0D-4231-B83B-1F3DAE29CDC1@isi.edu>
Content-Transfer-Encoding: quoted-printable
X-Mailer: iPhone Mail (8J2)
From: Joe Touch <touch@isi.edu>
Date: Sat, 04 Jun 2011 07:02:27 -0700
To: Christopher Morrow <morrowc.lists@gmail.com>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: "stephen.farrell@cs.tcd.ie" <stephen.farrell@cs.tcd.ie>, Sandra Murphy <Sandra.Murphy@sparta.com>, "sidr@ietf.org" <sidr@ietf.org>
Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2?
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 04 Jun 2011 21:40:42 -0000

So basically the problem is that:

- routers don't all support IPsec for the control plane

- servers don't yet implement AO

I repeat that there's a known solution that is already being used for BGP:

Use AO if available

Use MD5 in the meantime

Yes, servers will support AO, if for no other reason than they support BGP and MD5 now. 

Joe

On Jun 3, 2011, at 7:26 PM, Christopher Morrow <morrowc.lists@gmail.com> wrote:

> On Fri, Jun 3, 2011 at 10:15 PM, Uma Chunduri <uma.chunduri@ericsson.com> wrote:
>> 
>> 
>> -----Original Message-----
>> From: christopher.morrow@gmail.com [mailto:christopher.morrow@gmail.com] On Behalf Of Christopher Morrow
>> Sent: Friday, June 03, 2011 6:11 PM
>> To: Uma Chunduri
>> Cc: Sandra Murphy; stephen.farrell@cs.tcd.ie; sidr@ietf.org
>> Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2?
>> 
>> On Fri, Jun 3, 2011 at 5:28 PM, Uma Chunduri <uma.chunduri@ericsson.com> wrote:
>>> 
>>> 
>>> -----Original Message-----
>>> From: Sandra Murphy [mailto:Sandra.Murphy@sparta.com]
>>> Sent: Friday, June 03, 2011 1:43 PM
>>> To: Uma Chunduri
>>> Cc: sidr@ietf.org; Sean Turner; stephen.farrell@cs.tcd.ie
>>> Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2?
>>> 
>>> 
>>> On Fri, 3 Jun 2011, Uma Chunduri wrote:
>>> 
>>>> 
>>>> 
>>> ....
>>> 
>>>> 
>>>> True, privacy through SSH is overkill but strong AUTH is *critical*, I feel:
>>>>   - TCP-MD5 should not be considered (as it is any ways deprecated
>>>> and it's MD5)
>>>>   - TCP-AO has only slight advantage as it has less overhead than
>>>> ipsec-AH even when
>>>>     deployed with manual keys
>>>>   - but it's better if it is "MUST support authentication of nodes
>>>> with TCP-AO or ipsec-AH" because
>>> 
>>> Just to be sure:
>>> 
>>> Did you understand the part about implementations of TCP-AO and ipsec-AH not being available at present?
>>> 
>>> I.e., you recognize this forces a delay in implementation of the protocol (and accept the consequent impact on deployment of the RPKI)?
>>> 
>>> [Uma] Yes, I did. Even though operators don't like  ipsec-AH today, it
>>> is still deployed for OSPFv3 protection as that (of course now there are other drafts to mitigate complexity with reasonable trade-off).
>>> 
>> 
>> So, speaking as just another guy on the bus here... it's not about 'dont like it' it's about "THE CODE ON THE ROUTER DOES NOT DO IPSEC"
>> 
>> Keep in mind that a router is not a generic CPU + intel ethernet PCI card, and often the OS on it is optomized for a particular duty, in large iron routers it's NOT ipsec.
>> 
>>> Problem with MD5 is, it can present the *weakest* link for the whole RPKI infa.
>>> At least new infrastructure like RPKI should avoid deprecated  stuff.
>> 
>> exactly how is MD5 the weakest link here? some particular words about the threat model + ability to subvert a running session which ships a few megabytes/minute around would be in order here.
>> 
>> [Uma]
>> 
>> 1. Wang, X., H. Yu, "How to break MD5 and other hash
>>             functions", Proc. IACR Eurocrypt 2005, Denmark
> 
> depends on creating 2 items to hash I believe?  shows that if you do
> the right thing for 2 very large items you create you can get a
> collision in some instances. not picking random bits off the wire, not
> relevant, move on.
> 
>> 2. RFC 4270
> 
> talks about the above, not relevant.
> 
>> 
>> 3. long back even OSPF, ISIS etc.. moved away from MD5
> 
> fear, uncertainty, doubt.
> 
> we aren't talking about a permanent use of md5, we're talking about:
> Use something that provides authentication/assurance NOW so we can
> move forward, knowing full well we'll change to the better/required
> solution when it's available in the right places.
> 
> There's not a single AO implementation available today... it's DOA
> until there is. (frankly it's kind of a failure that there aren't
> widely deployed implementations of this... given all the time to
> invent it and all)
> 
>> 4. ...
>> 
>> For that matter SHA1 is getting deprecated http://securitymusings.com/article/1587/algorithm-and-key-length-deprecation
>> 
> 
> again, not relevant.
> 
> please find something relevant that's not just fear mongering. Or,
> alternately, find implementations of AO in the servers and routers
> that matter. (if there are AO implementations w00t! we all win, until
> then we spin)
> 
> -chris
> <regular guy socks==on>
> 
>> 
>> Getting public keys from a server with a  deprecated auth mechanism to verify RSA signature?
>> it's obscure..and not sure why it's not considered weak.
>> Well, one can still use and design systems around this if this is still seen adequate.
>> 
>> -Uma
>> 
>> 
>> 
>> 
>> -chris
>> <just a guy>
>> 
>>> -Uma
>>> 
>>> 
>>> --Sandy, speaking as wg co-chair
>>> 
>>> 
>>>>     as both support
>>>>           - strong auth algos
>>>>           - algo agility
>>>>           - can be deployed with manual and auto key management
>>>>            (auto key probably required eventually, once with lot of
>>>> connections at
>>>>             cache/global RPKI/server side and for automatic key
>>>>             changes periodically)
>>>>           - key changes for existing sessions
>>>> 
>>>>    One would get flexibility with this.
>>>>    Also Section 7 (page 16)
>>>>    "It is assumed that the router and cache have exchanged keys out of band by some reasonably secured means"
>>>>    This will be still applicable but only if TCP-AO/ipsce-AH are deployed with manual keys.
>>>> 
>>>> 2 cents,
>>>> -Uma
>>>> 
>>>> 
>>>> _______________________________________________
>>>> sidr mailing list
>>>> sidr@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/sidr
>>>> 
>>> _______________________________________________
>>> sidr mailing list
>>> sidr@ietf.org
>>> https://www.ietf.org/mailman/listinfo/sidr
>>> 
>> 
> _______________________________________________
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr