Hi folks,
As part of the discussion in OPSEC with Stephen Kent and others, I
looked at the SIDR infrastructure as well as soBGP document.
I found easy ways to just get over all the security
infrastructure(PKI) and still being able to do all the attacks as we
can currently. Please have a look at the discussion below and let me
know your comments.
Thanks,
Vishwas
---------- Forwarded message ----------
From: Vishwas Manral <[EMAIL PROTECTED]>
Date: Wed, Feb 27, 2008 at 7:13 PM
Subject: Re: [OPSEC] pccw as17557 leak...
To: Stephen Kent <[EMAIL PROTECTED]>
Cc: Roland Dobbins <[EMAIL PROTECTED]>, opsec wg mailing list <[EMAIL
PROTECTED]>
Hi Steve,
Thanks a lot for the comments. I agree it can be a good first step but
not sure what the future holds.
I am not sure if a heavy solution like this is required which only
gives reasonable security. What about the CPU DoS attacks that can be
result when new random routes are injected into a domain.
Thanks again,
Vishwas
On Wed, Feb 27, 2008 at 7:07 PM, Stephen Kent <[EMAIL PROTECTED]> wrote:
> At 5:12 PM -0800 2/27/08, Vishwas Manral wrote:
> >Hi folks,
> >
> >I looked at the SIDR documents in brief. It can probably be used to
> >help prevent any attacks caused due to non-malicious intent.
> >
> >I found easy ways to get over the SIDR security when done with a
> >malicious intent. SIDR just tells the mapping between AFI, AF and AS
> >number which can originate the same. However the choosing of a route
> >by BGP does not depend on these fields alone. So if a malicious router
> >changed the attributes attached to an NLRI update so that it becomes
> >the chosen AS to the prefix (of course without changing the
> >originating AS field). It can still redirect all the traffic to itself
> >for the prefix and then do whatever malicious it wants to do,
> >including just drop the packet.
> >
> >In this way still achieving the attack, but this time for sure with
> >malicious intent.
> >
> >Thanks,
> >Vishwas
>
>
> Your example of how an AS can tamper with a route, without changing
> the origin AS assertion is correct. I think the SIDR WG participants
> understand that.
> The work so far i SIDR focuses on establishing an infrastructure that
> will enable more comprehensive routing security capabilities in the
> future. Both the soBGP and SBGP proposal need this sort of
> infrastructure, so it is viewed as a reasonable initial effort.
>
> I also agree with your observation that the infrastructure makes it
> potentially easier to distinguish between some forms of attacks vs.
> accidental routing errors, and that, in itself, seems valuable too.
>
> Steve
>
Internet Engineering Task Force Vishwas Manral
Internet-Draft IPInfusion Inc.
Intended status: Standards Track
Expires: August 27, 2008
February 27, 2008
Security limitations of SIDR
draft-manral-sidr-limitations-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 27, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract
SIDR architecture describes an architecture for an infrastructure to
support secure Internet routing. The foundation of the architecture
is a public key infrastructure (PKI) that represents the allocation
hierarchy of IP address space and Autonomous System Numbers;
certificates from this PKI are used to verify signed objects that
authorize autonomous systems to originate routes for specified IP
Manral Expires August 27, 2008 [Page 1]
Internet-Draft Security limitations of SIDR February 2008
address prefixes. The data objects that comprise the PKI, as well as
other signed objects necessary for secure routing, are stored and
disseminated through a distributed repository system. This document
describes limitations and other limitations to the use of the SIDR
infrastructure.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Manral Expires August 27, 2008 [Page 2]
Internet-Draft Security limitations of SIDR February 2008
1. Introduction
This document defines the limitations of the SIDR infrastructure and their
use with so-BGP and other such related security mechanisms.
2. Limitations
2.1. Problem with just verifying origin
SIDR architecture allows a mechanism to verify an AutonomouS System (AS)
has rights to originate a particular prefix.
BGP best route selection algorithm however does not only use the
originaing
AS, and NLRI prefix. It uses a lot of other attributes associated with
the
route to calculate the best route and propagate it across. If the
malicious
router does not change the origin AS for an NLRI prefix but changes
other
attributes required for best path selection. It can still make a lot of
routes be routed through it.
The malicious device can then do whatever it wants with suchc traffic
including blackholing it.
2.2 CPU utilization
As verifying certificates costs a lot of CPU cycles, this can lead to
DoS
attacks on the router.
Using rate limiting can result in delays in BGP convergence.
3. Security Considerations
This document defines the securty limitations of the SIDR PKI infrastructure
when
used with BGP.
4. IANA Considerations
This document has no actions for IANA [IANA].
5. Acknowledgements
A lot of the text in this document is borrowed from [SIDR-ARCH]. The
authors of the document are acknowledged.
Manral Expires August 27, 2008 [Page 7]
Internet-Draft Security limitations of SIDR February 2008
8. References
8.1. Normative References
[IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing
an IANA Considerations Section in RFCs", BCP 26, RFC
2434, October 1998.
[SIDR-ARCH] SIDR architecture document
8.2. Informative References
Manral Expires August 27, 2008 [Page 8]
Internet-Draft Security limitations of SIDR February 2008
Authors' Addresses
Vishwas Manral
IP Infusion Inc.,
Bamankhola,
Bansgali,
Almora,
Uttarakhand - 263601
India
Email: [EMAIL PROTECTED]
Manral Expires August 27, 2008 [Page 9]
Internet-Draft Security limitations of SIDR February 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
[EMAIL PROTECTED]
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Manral Expires August 27, 2008 [Page 10]
_______________________________________________
Sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
