[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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.
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:
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,
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
>
>
>