Subject: FW: I-D Action:draft-ietf-v6ops-rfc3330-for-ipv6-04.txt

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 15 Jan 2008 09:19:44 -0800

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
[email-masked] 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, January 15, 2008 8:50 AM
To: [email-masked]
Cc: [email-masked]
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-for-ipv6-04
.txt

To remove yourself from the I-D Announcement list, send a message to
[email-masked] 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:
	[email-masked].
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.

---

From: "Dunn, Jeffrey H." <[email-masked]>
Date: Tue, 15 Jan 2008 12:58:38 -0500

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: [email-masked] [mailto:[email-masked]] On
Behalf Of Templin, Fred L
Sent: Tuesday, January 15, 2008 12:20 PM
To: [email-masked]
Cc: [email-masked]; Templin, Fred L
Subject: FW: I-D Action:draft-ietf-v6ops-rfc3330-for-ipv6-04.txt 

Marc,

Thanks - Fred

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, January 15, 2008 8:50 AM
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-v6ops-rfc3330-for-ipv6-04.txt 

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-rfc3330-for-ipv6-0
4
.txt

Send a message to:
	[email-masked].
In the body type:
	"FILE

	up into multiple messages), so check your local documentation
on

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 15 Jan 2008 10:01:31 -0800

Hmm; I guess maybe this is just about address prefixes,
(whereas ISATAP is about interface identifiers)? If so,
then never mind...

Thanks - Fred

> From: Templin, Fred L 
> Sent: Tuesday, January 15, 2008 9:20 AM
> To: [email-masked]'
> 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.
> 
> 
> http://www.ietf.org/internet-drafts/draft-ietf-v6ops-rfc3330-f
> or-ipv6-04.txt
> 
> 	a MIME-compliant mail reader.  Different MIME-compliant 
> mail readers

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 15 Jan 2008 10:19:35 -0800

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

> From: Dunn, Jeffrey H. [mailto:[email-masked]] 
> Sent: Tuesday, January 15, 2008 9:59 AM
> To: Templin, Fred L; [email-masked]
> Cc: [email-masked]; Dunn, Jeffrey H.
> Subject: RE: I-D Action:draft-ietf-v6ops-rfc3330-for-ipv6-04.txt 
> 
> Fred,
> 
> or-ipv6-0

---

From: Marc Blanchet <[email-masked]>
Date: Tue, 15 Jan 2008 13:28:24 -0500

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.

>> implementation to automatically retrieve the ASCII version of the

-----
IPv6 book: Migrating to IPv6, Wiley, 2006, http://www.ipv6book.ca

---

From: "Dunn, Jeffrey H." <[email-masked]>
Date: Tue, 15 Jan 2008 13:31:14 -0500

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:[email-masked]] 
Sent: Tuesday, January 15, 2008 1:28 PM
To: Templin, Fred L
Cc: Dunn, Jeffrey H.; [email-masked]
Subject: Re: I-D Action:draft-ietf-v6ops-rfc3330-for-ipv6-04.txt 

Marc.

-----

---

From: Marc Blanchet <[email-masked]>
Date: Tue, 15 Jan 2008 13:34:24 -0500

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.

-----

---

From: "Dunn, Jeffrey H." <[email-masked]>
Date: Tue, 15 Jan 2008 13:37:37 -0500

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.

Best Regards,
 
Jeffrey Dunn
Info Systems Eng., Lead
MITRE Corporation.

-----Original Message-----
From: Marc Blanchet [mailto:[email-masked]] 
Sent: Tuesday, January 15, 2008 1:34 PM
To: Dunn, Jeffrey H.
Cc: Templin, Fred L; [email-masked]
Subject: Re: I-D Action:draft-ietf-v6ops-rfc3330-for-ipv6-04.txt 

Marc.

-----

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 15 Jan 2008 10:57:24 -0800

Jeffrey,

> Sent: Tuesday, January 15, 2008 10:38 AM
> To: Marc Blanchet
> Cc: Templin, Fred L; [email-masked]; Dunn, Jeffrey H.

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

---

From: "Dunn, Jeffrey H." <[email-masked]>
Date: Tue, 15 Jan 2008 14:11:52 -0500

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:[email-masked]] 
Sent: Tuesday, January 15, 2008 1:57 PM
To: Dunn, Jeffrey H.; Marc Blanchet
Cc: [email-masked]
Subject: RE: I-D Action:draft-ietf-v6ops-rfc3330-for-ipv6-04.txt 

Jeffrey,

Thanks - Fred
 
> >>> address blocks."  That is not to say it is a bad idea, since
folks
> >> tend
Internet-Drafts

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 15 Jan 2008 11:34:30 -0800

Jeffrey,

I think this is getting off-topic for Marc's document, so
changing the subject. But, see below for follow-up: 

> Sent: Tuesday, January 15, 2008 11:12 AM
> To: Templin, Fred L; Marc Blanchet

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.   

> tunnel end point and host interfaces are, essentially, unguarded.  To

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.

>    ISATAP link spans an entire IPv4 site, restricting access to the link

Thanks - 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
> > >>> This draft is a work item of the IPv6 Operations 
> Working Group of
> > > the
> > >>> IETF.
> > >>>
> > >>>
> > >>> To remove yourself from the I-D Announcement list, send 
> a message
> > to

---

From: "Dunn, Jeffrey H." <[email-masked]>
Date: Wed, 16 Jan 2008 07:56:11 -0500

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:[email-masked]] 
Sent: Tuesday, January 15, 2008 2:35 PM
To: Dunn, Jeffrey H.; Marc Blanchet
Cc: [email-masked]
Subject: ISATAP Security (was: RE: I-D
Action:draft-ietf-v6ops-rfc3330-for-ipv6-04.txt)

Jeffrey,

link

Thanks - Fred

> > >>> Subject: RE: I-D
Action:draft-ietf-v6ops-rfc3330-for-ipv6-04.txt
> > >>> Subject: FW: I-D
Action:draft-ietf-v6ops-rfc3330-for-ipv6-04.txt

---

From: Marc Blanchet <[email-masked]>
Date: Wed, 16 Jan 2008 09:55:37 -0500

> associated with RFC 4214, ISATAP, are beyond the scope of this

Jeffrey,
  I may concur with you about people that might want to filter ISATAP  
traffic.

  However, this draft  is clearly intended to address blocks and  
prefixes. This quote is the first sentence of the draft:

"This document describes the global and other specialized IPv6 address  
blocks. "

To me, it is pretty clear that interface identifiers such as ISATAP or  
privacy addresses ... are out of scope, from the very beginning of  
this draft.

I would suggest to write a draft on filtering interface identifiers  
and submit it to the wg.

Marc.

-----