[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: ISATAP Security (was: RE: I-D Action:draft-ietf-v6ops-rfc3330-for-ipv6-04.txt)
Fred,
Before we jump into the cesspool that is ISATAP security (or lack
thereof), I just wanted to come to closure on Marc's draft. I believe
that, in light of its wide deployment, securing ISATAP would be a
useful topic for an informational RFC. Thoughts?
Marc,
Since I try to provide solutions when I point out what I think are
problems, I suggest the following changes in section 3, Security
Considerations:
This document lists IPv6 address blocks, their associated prefixes and
guidelines associated with them. The guidelines should improve the
security of networks by the filtering of invalid routing prefixes.
Rules for filtering other special IPv6 address types, such as those
associated with RFC 4214, ISATAP, are beyond the scope of this
document.
Best Regards,
Jeffrey Dunn
Info Systems Eng., Lead
MITRE Corporation.
-----Original Message-----
From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com]
Sent: Tuesday, January 15, 2008 2:35 PM
To: Dunn, Jeffrey H.; Marc Blanchet
Cc: v6ops@ops.ietf.org
Subject: ISATAP Security (was: RE: I-D
Action:draft-ietf-v6ops-rfc3330-for-ipv6-04.txt)
Jeffrey,
I think this is getting off-topic for Marc's document, so
changing the subject. But, see below for follow-up:
> -----Original Message-----
> From: Dunn, Jeffrey H. [mailto:jdunn@mitre.org]
> Sent: Tuesday, January 15, 2008 11:12 AM
> To: Templin, Fred L; Marc Blanchet
> Cc: v6ops@ops.ietf.org; Dunn, Jeffrey H.
> Subject: RE: I-D Action:draft-ietf-v6ops-rfc3330-for-ipv6-04.txt
>
> Fred,
>
> Unless the IPv4 and/or the tunneled IPv6 datagram are using AH, you
> have no idea where the IPv4 or tunneled IPv6 datagram really came
from.
There are two possible attack vectors - a node from outside
the site injecting a tunneled packet with spoofed source address
into the site, and an intruder node that has gained access to
the site that injects packets with spoofed source addresses
from within the site. The former case is prevented by having
site border routers perform ingress filtering on the IPv4
packets that enter the site. The latter case is prevented
by "restricting access to the site" (aka ISATAP link) as
said under security considerations.
ISATAP is typically used in sites (e.g., campus LANs, home
WiFi networks, military MANETs, etc.) that use link-layer
security to restrict access to the site to only trusted nodes.
Sites that do not restrict access (e.g., a home WiFi network
that does not enable WEP) might have the vulerability you
describe. But the security implications in that case are not
limited only to ISATAP.
> The PRL helps the host identify "set of entries about potential
> routers; used to support router and prefix discovery." The ISATAP
> tunnel end point and host interfaces are, essentially, unguarded. To
> quote from RFC 4214:
The PRL is also used in source address verification during
decapsulation. It prevents a node within the site that is
not in the PRL from acting as an IPv6 router on the ISATAP
link.
> There is a possible spoofing attack in which spurious
ip-protocol-41
> packets are injected into an ISATAP link from outside. Since an
> ISATAP link spans an entire IPv4 site, restricting access to the
link
> can be achieved by restricting access to the site; i.e., by having
> site border routers implement IPv4 ingress filtering and ip-
> protocol-41 filtering.
>
> Best Regards,
Thanks - Fred
fred.l.templin@boeing.com
>
> Jeffrey Dunn
> Info Systems Eng., Lead
> MITRE Corporation.
>
> -----Original Message-----
> From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com]
> Sent: Tuesday, January 15, 2008 1:57 PM
> To: Dunn, Jeffrey H.; Marc Blanchet
> Cc: v6ops@ops.ietf.org
> Subject: RE: I-D Action:draft-ietf-v6ops-rfc3330-for-ipv6-04.txt
>
> Jeffrey,
>
> > -----Original Message-----
> > From: Dunn, Jeffrey H. [mailto:jdunn@mitre.org]
> > Sent: Tuesday, January 15, 2008 10:38 AM
> > To: Marc Blanchet
> > Cc: Templin, Fred L; v6ops@ops.ietf.org; Dunn, Jeffrey H.
> > Subject: RE: I-D Action:draft-ietf-v6ops-rfc3330-for-ipv6-04.txt
> >
> > Marc,
> >
> > You cannot; however, if the purpose of your ID is to help populate
> ACLs
> > for prefix filtering to help prevent unauthorized IPv6 access, you
> > probably should mention in the security considerations that ISATAP
> can
> > allow a tunneled IPv6 datagram to spoof any prefix.
>
> Apologies for having started this whole thing, but I'm not
> sure I get the concern about about ISATAP allowing prefix
> spoofing. ISATAP has filtering rules that keep non-PRL
> routers/hosts from using prefixes other than those assigned
> to the ISATAP link. So, the ISATAP PRL is the mitigation
> against spoofing. Do I still miss the point?
>
> Thanks - Fred
> fred.l.templin@boeing.com
>
> > Best Regards,
> >
> > Jeffrey Dunn
> > Info Systems Eng., Lead
> > MITRE Corporation.
> >
> > -----Original Message-----
> > From: Marc Blanchet [mailto:Marc.Blanchet@viagenie.ca]
> > Sent: Tuesday, January 15, 2008 1:34 PM
> > To: Dunn, Jeffrey H.
> > Cc: Templin, Fred L; v6ops@ops.ietf.org
> > Subject: Re: I-D Action:draft-ietf-v6ops-rfc3330-for-ipv6-04.txt
> >
> > I can't get it. ISATAP is an interface identifier. how one
> > can filter
> > a prefix on a BGP router, since any prefix may contain ISATAP
> > interface identifier?
> >
> > Marc.
> >
> > Le 08-01-15 à 13:31, Dunn, Jeffrey H. a écrit :
> >
> > > Marc,
> > >
> > > If the purpose is to list all PREFIXES that need to be filtered,
I
> > > suggest that you at least mention ISATAP in the Security
> > > Considerations
> > > section.
> > >
> > > Best Regards,
> > >
> > > Jeffrey Dunn
> > > Info Systems Eng., Lead
> > > MITRE Corporation.
> > >
> > > -----Original Message-----
> > > From: Marc Blanchet [mailto:Marc.Blanchet@viagenie.ca]
> > > Sent: Tuesday, January 15, 2008 1:28 PM
> > > To: Templin, Fred L
> > > Cc: Dunn, Jeffrey H.; v6ops@ops.ietf.org
> > > Subject: Re: I-D Action:draft-ietf-v6ops-rfc3330-for-ipv6-04.txt
> > >
> > > I think ISATAP are really out of scope of this document. The
> purpose
> > > of the document was not to list all possible IPv6 addresses
> > constructs
> > >
> > > but listing the prefixes that need to be looked at for operators.
> > > Again, the genesis of this draft was a concensus among providers
> and
> > > IX operators during an informal IXv6 meeting on the need of a
> > document
> > >
> > > to list all prefixes that are candidate to be filtered in some
> shape
> > > or form.
> > >
> > > Marc.
> > >
> > > Le 08-01-15 à 13:19, Templin, Fred L a écrit :
> > >
> > >> Jeffrey,
> > >>
> > >> I hadn't thought about ACLs, and there is also the question
> > >> of IPv6 privacy addresses (RFC3041) that end up looking like
> > >> ISATAP addresses. I guess I could see the rescoping if there
> > >> were concern for addresses that look like ISATAP showing up
> > >> on prefixes assigned to non-ISATAP links. Is there reason
> > >> to be concerned about this?
> > >>
> > >> Thanks - Fred
> > >> fred.l.templin@boeing.com
> > >>
> > >>
> > >>> -----Original Message-----
> > >>> From: Dunn, Jeffrey H. [mailto:jdunn@mitre.org]
> > >>> Sent: Tuesday, January 15, 2008 9:59 AM
> > >>> To: Templin, Fred L; Marc.Blanchet@viagenie.ca
> > >>> Cc: v6ops@ops.ietf.org; Dunn, Jeffrey H.
> > >>> Subject: RE: I-D
Action:draft-ietf-v6ops-rfc3330-for-ipv6-04.txt
> > >>>
> > >>> Fred,
> > >>>
> > >>> Interesting idea. The problem I have is that ISATAP
> addresses are
> > > not
> > >>> part of any address block. As a result, mentioning them
> would re-
> > >>> scope
> > >>> the document, from describing "the global and other specialized
> > IPv6
> > >>> address blocks." That is not to say it is a bad idea, since
> folks
> > >> tend
> > >>> to research like documents to populate their ACLs. Thoughts?
> > >>>
> > >>> Best Regards,
> > >>>
> > >>> Jeffrey Dunn
> > >>> Info Systems Eng., Lead
> > >>> MITRE Corporation.
> > >>> -----Original Message-----
> > >>> From: owner-v6ops@ops.ietf.org
> > [mailto:owner-v6ops@ops.ietf.org] On
> > >>> Behalf Of Templin, Fred L
> > >>> Sent: Tuesday, January 15, 2008 12:20 PM
> > >>> To: Marc.Blanchet@viagenie.ca
> > >>> Cc: v6ops@ops.ietf.org; Templin, Fred L
> > >>> Subject: FW: I-D
Action:draft-ietf-v6ops-rfc3330-for-ipv6-04.txt
> > >>>
> > >>> Marc,
> > >>>
> > >>> Just seeing this now, I think maybe you should add ISATAP
> > >>> addresses to this list (RFC4214). The address format is
> > >>> also specified under the IANA ethernet-numbers registry.
> > >>>
> > >>> The text of your draft could say that the address format
> > >>> usage is limited to ISATAP links - but, it is important
> > >>> to note the addresses as special-use.
> > >>>
> > >>> Thanks - Fred
> > >>> fred.l.templin@boeing.com
> > >>>
> > >>> -----Original Message-----
> > >>> From: Internet-Drafts@ietf.org
[mailto:Internet-Drafts@ietf.org]
> > >>> Sent: Tuesday, January 15, 2008 8:50 AM
> > >>> To: i-d-announce@ietf.org
> > >>> Cc: v6ops@ops.ietf.org
> > >>> Subject: I-D Action:draft-ietf-v6ops-rfc3330-for-ipv6-04.txt
> > >>>
> > >>> A New Internet-Draft is available from the on-line
> Internet-Drafts
> > >>> directories.
> > >>> This draft is a work item of the IPv6 Operations
> Working Group of
> > > the
> > >>> IETF.
> > >>>
> > >>>
> > >>> Title : Special-Use IPv6 Addresses
> > >>> Author(s) : M. Blanchet
> > >>> Filename :
> draft-ietf-v6ops-rfc3330-for-ipv6-04.txt
> > >>> Pages : 8
> > >>> Date : 2008-01-15
> > >>>
> > >>> This document describes the global and other specialized IPv6
> > > address
> > >>> blocks. It does not address IPv6 address space assigned to
> > > operators
> > >>> and users through the Regional Internet Registries. These
> > >>> descriptions are useful for route and IP filtering, for
> > > documentation
> > >>> and other purposes.
> > >>>
> > >>> A URL for this Internet-Draft is:
> > >>> http://www.ietf.org/internet-drafts/draft-ietf-v6ops-rfc3330-f
> > >>> or-ipv6-0
> > >>> 4
> > >>> .txt
> > >>>
> > >>> To remove yourself from the I-D Announcement list, send
> a message
> > to
> > >>> i-d-announce-request@ietf.org with the word unsubscribe in
> > >>> the body of
> > >>> the message.
> > >>> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-
> > >>> announce
> > >>> to change your subscription settings.
> > >>>
> > >>> Internet-Drafts are also available by anonymous FTP.
> > Login with the
> > >>> username "anonymous" and a password of your e-mail
> address. After
> > >>> logging in, type "cd internet-drafts" and then
> > >>> "get draft-ietf-v6ops-rfc3330-for-ipv6-04.txt".
> > >>>
> > >>> A list of Internet-Drafts directories can be found in
> > >>> http://www.ietf.org/shadow.html
> > >>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> > >>>
> > >>> Internet-Drafts can also be obtained by e-mail.
> > >>>
> > >>> Send a message to:
> > >>> mailserv@ietf.org.
> > >>> In the body type:
> > >>> "FILE
> > >>> /internet-drafts/draft-ietf-v6ops-rfc3330-for-ipv6-04.txt".
> > >>>
> > >>> NOTE: The mail server at ietf.org can return the document in
> > >>> MIME-encoded form by using the "mpack" utility.
> To use this
> > >>> feature, insert the command "ENCODING mime"
> before the "FILE"
> > >>> command. To decode the response(s), you will
> need "munpack" or
> > >>> a MIME-compliant mail reader. Different
> MIME-compliant mail
> > >>> readers
> > >>> exhibit different behavior, especially when dealing
with
> > >>> "multipart" MIME messages (i.e. documents which
> have been split
> > >>> up into multiple messages), so check your local
> documentation
> > >>> on
> > >>> how to manipulate these messages.
> > >>>
> > >>> Below is the data which will enable a MIME compliant mail
reader
> > >>> implementation to automatically retrieve the ASCII
> version of the
> > >>> Internet-Draft.
> > >>>
> > >
> > > -----
> > > IPv6 book: Migrating to IPv6, Wiley, 2006, http://www.ipv6book.ca
> > >
> >
> > -----
> > IPv6 book: Migrating to IPv6, Wiley, 2006, http://www.ipv6book.ca
> >
> >
> >
>