Re: [sidr] draft-ietf-sidr-bgpsec-protocol-13's security guarantees

"Sriram, Kotikalapudi" <> Fri, 28 August 2015 21:45 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 411C21B3082 for <>; Fri, 28 Aug 2015 14:45:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HF6KpPydmEvM for <>; Fri, 28 Aug 2015 14:45:19 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 024D21B307F for <>; Fri, 28 Aug 2015 14:45:18 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Fri, 28 Aug 2015 21:45:18 +0000
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Fri, 28 Aug 2015 21:45:17 +0000
Received: from ([]) by ([]) with mapi id 15.01.0256.013; Fri, 28 Aug 2015 21:45:17 +0000
From: "Sriram, Kotikalapudi" <>
To: Rob Austein <>, "" <>
Thread-Topic: [sidr] draft-ietf-sidr-bgpsec-protocol-13's security guarantees
Thread-Index: AQHQ4EXjUWOu4xHMLkqEedR7+Q4tdZ4f9sSQgAAsoQCAAcX5oA==
Date: Fri, 28 Aug 2015 21:45:17 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
authentication-results: spf=none (sender IP is );; dkim=none (message not signed) header.d=none;; dmarc=none action=none;
x-originating-ip: []
x-microsoft-exchange-diagnostics: 1; CY1PR09MB0793; 5:q9JDsO2OQl2cvoEJJd6LrFjO8pHlA28BKdPDMIAHL0L7BBN4tNboTgZ1wV+D68pDxHql2psiY+iykrW5fPDuVYqSM93f40v+SAlzTHFAq/sg8te9oYD/vUOa6A1cRsK1fF+On0P12UfKfx9hrnkPig==; 24:iV0AI/rlchwogm1bLuRkWlws+8TjA3vt1cfRaxAdt+7/PN4HFvF0vy/dF217gQRv8BrTWIAe0wYOpgT33c6Zs1C16mET/eiOgkisKWVBC0g=; 20:7mY95b4HylVf0MMFvMRdhlSeSFtpJihzu40S7jQFH+Tjv2t9JebfcxVg+2HAiFDXkCSpCyJOi9zUvcT1c8s9eA==
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0793; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0890;
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(8121501046)(3002001); SRVR:CY1PR09MB0793; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0793;
x-forefront-prvs: 0682FC00E8
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(189002)(107886002)(102836002)(97736004)(50986999)(62966003)(2501003)(76176999)(5001770100001)(77156002)(2900100001)(5002640100001)(15975445007)(74316001)(5001960100002)(189998001)(19580395003)(2950100001)(101416001)(92566002)(54356999)(87936001)(4001540100001)(106116001)(5001830100001)(5001860100001)(81156007)(2656002)(64706001)(46102003)(68736005)(122556002)(10400500002)(66066001)(77096005)(5007970100001)(86362001)(106356001)(40100003)(230783001)(5004730100002)(99286002)(76576001)(5003600100002)(33656002)(105586002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0793;; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None ( does not designate permitted sender hosts)
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Aug 2015 21:45:17.0375 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0793
X-Microsoft-Exchange-Diagnostics: 1; CY1PR09MB0890; 2:iFpG45ClZynZFZBUDEp0mDMmKxKka2drwC1U7kS3tkqvDq8IeBCiXKcEbGAH8MlTh0l24X8wh8XxZHAMmvemKNtsQ0tUA3gCpMFc+qGvT/Cc2vXhLDhONGjIRlDgFeWsz2b99osPs20gLRvPq9s9UOf+7UZpJNleld1Pyu7ts5w=; 3:AOYMzbWoQRlw+9cCHsGiHQJ+H8zN/9cpk2uKnyZ2GwoteIdNRIVr8Jz1tSBqMhQ44wFhtL0HzmnBcBSK2yooolME5sX1aAALmWwXTmIhVpomCgsKPUPXyExXKhBA5uoBchM4VNyaV0MSw4yiVu/VKg==; 25:5ZEM59kP8A+J4Rl6UHHOaUoPTNQfsCRIIJDMH1YQf7DuEhIbuggmhHf6PhUUy+XCCm7kudF9bmBm5CRIAFzC9sFzlp2AJIdcpYEZEyzRdD6Z/0kp4dLIt6nkLDn+5EM3Pf+lBihhSlNVTR8rgQpB7cFHvM0AnUy8FMGxda1/3SIu6zNEpe6CM+CAy/4F8PqL2FxDfi4UPMA2OGykAyLGuVCRIhgMMpf326zU8N6BQkF1Pwsdjf+Q2t33pXsYANMh+KGQL81OvMVSdsJH+h99xQ==; 23:xSnOuKigiDnqtsLExq6FM3UnFTw1lBo43ZjrMMDXNHWr/QOQsgeHBOiMqdSJcIH0lKhQ7WzS19kj3kHT5cjOz4A0cIM6XsaiOlnDpYekajULyA1q6grZQ3LDqhVBU52sVoQzSBlUw/lXVsCGkFMXX1T7sI4Uu524Ydk6w9Kg5YXcXtO/o5OwfZc7iS+Hheae
Archived-At: <>
Subject: Re: [sidr] draft-ietf-sidr-bgpsec-protocol-13's security guarantees
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Secure Interdomain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 28 Aug 2015 21:45:21 -0000

>If I understand your scenario correctly, as far as folks further along
>the path are concerned, this is a replay attack by D.  That D is doing
>this to cover up something bad that A is doing to B and C is almost
>irrelevant, as is the specific nature of whatever bad thing A is doing
>to B and C.
>So, yeah, OK, it's a form of collusion, but it's not one that relies
>on a weakness in the signature semantics, it's one that relies on lack
>of protection against replay attacks, something the WG discussed and
>rejected.  Can't speak for anybody else, but I'm not particularly
>interested in exhuming the replay horse at this late date.

It appears you agree that the two-update collusion scenario that 
I described is feasible. It is basically another mechanism by which the 
colluders seem to achieve the same effect as in David's collusion scenario.
(I think so, but I'm open to being proven wrong about that.) 
The latter, it appears, can be mitigated by signing 'all of the preceding 
signed data', but not the former (two-update collusion). 
Both scenarios or threats rely on intermediate ASes not verifying. 
So both of these scenarios are mitigated by requiring intermediate 
ASes to verify. This is the observation I would like to make.

Since you made contrary comments, let me point out respectfully 
that replay attack mitigation is in the requirements (RFC 7353):
4.3  Replay of BGP UPDATE messages need not be completely prevented,
        but a BGPsec design SHOULD provide a mechanism to control the
        window of exposure to replay attacks.

And there is an active SIDR WG draft dealing with replay attack mitigation: 

However, a solution for the specific collusion threat we are discussing 
does not benefit at all from replay attack mitigation techniques.
All that D is doing (in my example) is to hold the first update for 15 or 30 seconds.
The bgpsec-rollover draft proposes router key rollovers, 
but (thank goodness) not on that small/tiny (seconds) time scale!