Subject: I-D ACTION:draft-ietf-v6ops-nap-01.txt

From: [email-masked]
Date: Wed, 15 Jun 2005 16:13:27 -0400

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		: IPv6 Network Architecture Protection
	Author(s)	: G. Van de Velde, et al.
	Filename	: draft-ietf-v6ops-nap-01.txt
	Pages		: 31
	Date		: 2005-6-15
	
Although there are many perceived benefits to Network Address
   Translation (NAT), its primary benefit of "amplifying" available
   address space is not needed in IPv6.  In addition to NAT's many
   serious disadvantages, there is a perception that other benefits
   exist, such as a variety of management and security attributes that
   could be useful for an Internet Protocol site.  IPv6 does not support
   NAT by design and this document shows how Network Architecture
   Protection (NAP) using IPv6 can provide the same or more benefits
   without the need for NAT.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-nap-01.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-nap-01.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-nap-01.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: Fred Baker <[email-masked]>
Date: Wed, 15 Jun 2005 13:32:38 -0700

Gunter tells me that this draft was almost ready for submission when I  
issued the last call on the previous version. oops. Let's restart the  
last call today, reviewing this draft, and ending two weeks from today.

On Jun 15, 2005, at 1:13 PM, [email-masked] wrote:

> ----------------------------------------------------------------------- 
> --
> CONTENT ABOVE THIS LINE IS *NOT* FROM CISCO INFORMATION TECHNOLOGY
> ----------------------------------------------------------------------- 
> --
> In order to maintain computing infrastructure integrity, Cisco Systems
> Enterprise Messaging Services and InfoSec teams have set a mail policy
> disallowing executable attachments in email.
>
> This message contained an executable attachment type that is prohibited
> by this policy. The attachment has been removed from this message and
> copied to quarantine by our systems. It will be held in quarantine for
> seven days in the event that the content needs to be retrieved.
>
> Please be aware many viruses attempt to look like legitimate email or
> notifications from anti-virus systems. We will clearly mark a  
> seperation
> between our notifications and the original email as follows:
>
>   "CONTENT ABOVE THIS LINE IS *NOT* FROM CISCO INFORMATION TECHNOLOGY"
>
> For further reference information about viruses and email antivirus
> efforts within Cisco, please visit:
>
> http://wwwin.cisco.com/it/ems/services/antiviral
>
> If your concern isn't addressed by the information in this notification
> or the above web page, you may open a support request:
>
> http://wwwin.cisco.com/support/
>
> Select "Messaging", "Email-Related", "Mail Routing"
>
> Please include in the text of your case the following information:
>
> * Full headers of the message. Documentation on displaying the full
> headers is available at this URL:
>
> http://wwwin.cisco.com/support/library/faqs/solution002471.html
>
> * This unique quarantine identifier: j5FKITc4010679
>
> If the matter is urgent, you may follow up by calling one of the below
> referenced numbers. Please make every effort to provide the above
> requested information via the support web tool prior to calling as it
> will greatly aid the resolution of your issue.
>
> Americas:
> 1 408 526 8888
>
> Asiapac
> +61 2 8446 8888
>
> EMEA
> +31 20 485 4888
>
> Japan
> +81 3 5549 6888
>
> US (Toll Free)
> 1| 800| 888| 8187| (ext.68888)
>
> Thank you for your cooperation,
>
> Enterprise Messaging Services
> Cisco Systems, Inc
>
> --OtherAccess--

---

From: "Soininen Jonne (Nokia-NET/Helsinki)" <[email-masked]>
Date: Thu, 16 Jun 2005 10:38:46 +0300

Hi,

I would still do my three comments that I did previously:

"1) Section 2.2: I'm not native English speaker. So, my understanding of
some words might be completely wrong. However, I think the phrase "evil
outside influences" makes me think about something in horror stories
(e.g. Dracula). Would word "malicious" be more appropriate?

2) Section 2.6: The section nicely explains the situation with the IPv4
address space. However, I have recently met misunderstanding of the size
of the private address space. There seems to be a belief out there that
private address space is limitless. 
Would it be appropriate to add some words to address this issue as well?
(E.g. "Even the use of private (RFC1918) IPv4 address space has its
practical limits. Especially, in large network environments the private
address space can be exhausted resulting to difficult or even impossible
operational problems") I'm not sure, though, if it is appropriate in
this particular section.

3) Section 4.4: Usage of Mobile IP is proposed for topology hiding.
However, wouldn't any kind of tunneling do the trick? Is there a reason
that it really must be Mobile IP?"

Anyways, despite my nit comments I still think the document is ready for
the IESG.

Cheers,

Jonne.

-- 
Jonne Soininen
Nokia

Tel: +358 40 527 46 34
E-mail: [email-masked]

---

From: Pekka Savola <[email-masked]>
Date: Fri, 17 Jun 2005 11:48:25 +0300 (EEST)

On Wed, 15 Jun 2005, Fred Baker wrote:
> Gunter tells me that this draft was almost ready for submission when I issued 
> the last call on the previous version. oops. Let's restart the last call 
> today, reviewing this draft, and ending two weeks from today.

As Jonne was mentioning (and I've stated this in the past, but not as 
clearly as he did), I think the MIPv6 tunnels for topology hiding 
should be rephrased slightly to make it just an example of a tunneling 
mechanism for topology hiding.  As he said, any tunneling is just 
fine.  At the moment, something different is possibly easier to 
provide; in the future, if MIPv6 provisioning methods improve, maybe 
it gets more popular (and easier).

I think the doc is in a pretty good shape, and after a quick update, 
ready to go forward.

As a procedural point, it might be courteous to ask for external 
review from NAT communities (e.g., behave WG chairs, [dare I say this] 
Keith Moore, maybe some others) to make sure the technical content of 
the document is OK, because this won't be IETF last called.

substantial
-----------

    When IPv6 NAP is utilized in these three domains then for the first
    category it will be possible to use the same solutions as described
    in chapter 5.1.  The second domain of the ISP/carrier is the
    Operations network.  This environment tends to be a closed
    environment, and consequently intra- communication can be done based
    on ULA addresses.  This would give a stable configuration with
    respect to a local IPv6 address plan.  Using these local scope
    addresses would also prevent from being accessed from the external
    network.

==> For ISP/carrier grade, they already have very stable addresses, so they
don't need ULAs for PI purposes.  I also think the ISP/carriers should be
qualified enough to set up proper filtering, so "prevent from being
accessed" doesn't seem like a winning argument either.

So, I'd remove the case for ULA for ISP/carrier backbones completely.

...

6.  IPv6 gap analysis

==> this section needs major updates.  Specifically, 'Completion of 
work on ULAs' needs to be removed or seriously reworded (the work is 
finished already).  Similarly, as the renumerbing procedure is already 
also in RFC ed-queue, section 6.4 requires a bit of new phrasing as 
well.  Further, untraceable addresses seem to be discussed in sections 
6.2, 6.3 and 6.6; the text should be made more focused.  Lastly, in 
6.3, I'd say "topology masking _may be_ required" instead of "is 
required", because whether this is needed or not is a value judgment 
(which I don't encourage myself, but can live with).

semi-editorial
--------------

2.2  Simple security due to stateful filter implementation

    A firewall doesn't fully secure a network, because many attacks come
    from inside or are at a layer higher than the firewall can protect
    against.  In the final analysis, every system has to be responsible
    for its own security, and every process running on a system has to be
    robust in the face of challenges like stack overflows etc.  What a
    firewall does is prevent a network administration from having to pay
    for bandwidth to carry unauthorized traffic, and in so doing reduce
    the probability of certain kinds of attacks across the protected
    boundary.

    A distributed security mechanism to protect the end-systems may help
    in the above situation; however, to deploy such a system is quite
    complex and may depend upon behaviour per operating system and
    release version.  As a result it will probably not be available in
    the next couple of years for end-user organizations.  End-system-only
    security mechanisms don't protect the network infrastructure from
    being misused for transit, or against DDOS attacks against individual
    systems inside, and this is the area where a NAT device is perceived
    to provide some relief.

==> these _exact_ same paragraphs appear at the start of section 2.4 
as well? I suggest removing duplicate text from 2.4 as these issues 
don't have much to do with 2.4 (privacy & topology hiding)

    3.  The size of the typical subnet ::/64 will make a network ping
        sweep and resulting port-scan virtually impossible due to the
        amount of possible combinations available.  This goes from the
        assumption that the attacker has no access to a local connection.
        If an attacker has local access then he could use ND [3] and
        ping6 to ff02::1 to detect local neighbors.  (Of course, a
        locally connected attacker has many scanning options with IPv4 as
        well.)  It is recommended for site administrators to take [17]
        into consideration to achieve the expected goal.
[...]
    Assuming the network administrator is aware of [17] the increased
    size of the IPv6 address will make topology probing much harder, and
    almost impossible for IPv6 devices.  What one does when topology
    probing is to get an idea of the available hosts inside an
    enterprise.  This mostly starts with a ping-sweep.  This is an
    automated procedure of sending Internet Control Message Protocol
    (ICMP) echo requests (also known as PINGs) to a range of IP addresses
    and recording replies.  This can enable an attacker to map the
    network.  Since the IPv6 subnets are 64 bits worth of address space,
    this means that an attacker has to send out a simply unrealistic
    number of pings to map the network, and virus/worm propagation will
    be thwarted in the process.  At full rate 40Gbps (400 times the
    typical 100Mbps LAN, and 13,000 times the typical DSL/Cable access
    link) it takes over 5000 years to scan a single 64 bit space.

==> There seemed to be some amount of text duplication about ping 
sweeping, and it seems a bit illogical to have it described at more 
length after it has already been introduced?

5.  Case Studies

    It is possible to divide the type of networks in different
    categories.  This can be done on various criteria.  The criteria used
    within this document are based on the number of components or
    connections.  [...]

==> clarify what you mean by 'connections'.  For different peoples at
different ISO layers it means completely different things.

editorial
---------

   Wide-scale deployments have shown that using NAT to attach a private
    IPv4 network to the Internet is simple and practical for the non-
    technical end user.  Frequently a simple user interface is sufficient
    for configuring both device and application access rights.

==> even more frequently, the users don't configure these boxes at all..?

Van de Velde, et al.    Expires December 3, 2005                [Page 6]
L
Internet-Draft    IPv6 Network Architecture Protection         june 2005

==> s/june/June/

For these
    reasons the sense of security provided by NAT are actually false.

==> s/are/is/

    Once a list of available devices and IP addresses has been mapped, a
    port-scan on these IP addresses can be performed.  Scanning works by
    tracking which ports do not receive unreachable errors from either
    the firewall or host.

==> s/unreachable/ICMP unreachable/ or was the wording specifically chosen
this way (to a degree also including TCP RST's and such) ?

    The random assignment has as purpose to confuse the outside world on

==> s/as/a/

4.1  Simple gateway between Internet and internal network

==> please reorganize this one long paragraph to 2-3 shorter ones.

   The ongoing subnet size maintenance may become simpler when IPv6
    technology is utilised.  If IPv4 address space is optimised one has
    periodically to look into the number of hosts on a segment and the
    subnet size allocated to the segment;

==> s/periodically to look/to look periodically/

    can be concatenated.  A single /48 alloaction provides an enterprise

==> s/alloac/alloca/

This means that the ISP will provide the
    enterprise with an IPv6 address-range (typically a one or multiple
    range(s) of '/48') from its RIR assigned IPv6 address-space.  The
    goal of this allocation mechanism is to decrease the total amount of
    entries in the internet routing table.

==> remove one word from "a one"
==> s/allocation/assignment/

    IPv6 internet, then some form of 'Untraceable' addresses may be used.

==> s/Untraceable/untraceable/

    Operations network.  This environment tends to be a closed
    environment, and consequently intra- communication can be done based
    on ULA addresses.

==> intra- [what?] communication?

---

From: Mark Smith <[email-masked]>
Date: Sat, 18 Jun 2005 01:18:42 +0930

Hi,

"6.2  Subnet topology masking

      There really is no functional gap here as a centrally assigned
   pool of addresses in combination with host routes in the IGP is an
   effective way to mask topology. "

I'm wondering if the above is actually the case. 

I think host routes are easy enough to understand from the point of view
of propagating /128s around within an IGP. 

What I'm curious about is how the end-nodes are configured and how they
operate, in particular when they are attached to a broadcast
multi-access link e.g., an ethernet. Has this operation been discussed or
described in an ID or RFC that I'm not aware of ?

For example, assuming a single IPv6 address assignment (excluding
link-local), if an end-node is attached to an ethernet, what prefix length is
configured for the address that is going to be used as a host route within the IGP ? 

I think a /128 would make sense, which means that this end-node would
then (initially) consider all IPv6 destinations to be offlink, excepting
link-local destinations. The first hop would always be to one or more of
the routers it has learned of via RAs. I'd guess that when this host
tries to send traffic to other IPv6 devices attached to the same (layer
2) link, the router would then issue an ICMP redirect, irrespective of
whether those other devices are also /128 host routed, or more
conventionally using /64 prefix lengths, so that this /128 host could
communicate directly "onlink" via layer 2 to an IPv6 "offlink" device.

Where this possibly gets interesting is for /128 end-nodes, where do
they send a link scoped multicast ? Do they send it only to the routers
they are aware of ? From an IPv6 routing point of view, I'd think that
other than the routers, all other devices would be offlink, because the
prefix length is 128 bits, so those other devices shouldn't receive a
link-scoped multicast from these /128 end-nodes. Does that mean that
these /128 hosts have to layer 2 unicast these IPv6 multicasts to the
visible routers, to ensure that the other nodes attached to the link
don't see the link-scoped multicast ?

Another option could be to assign a really short mask to the address
e.g., for a global address in the 2000::/3 address space, the interface
prefix length would be /3. The node would then consider all devices to
be onlink. For this to work, the router's attached to the link could
then perform proxy-ND for all offlink destinations. It sort of solves
the link-scope multicast issue, although it means that link-scoped
multicasts now have to be forwarded through the cloud to all links that
have /128 host routed hosts on them. I haven't read the ND Proxy draft
yet, I'll presume for the moment that this issue is considered.

All of the above is based on the scenario where a device only has a
link-local and a "host routed" address assigned to it's interface, using
either a /128 or /3 (for global) prefix length. Another couple of
scenarios come to mind which might make things a bit more complicated.
(a) These host routed devices are assigned /64s for the ULA address
space and (b) for simplicity, at the cost of doubling the number of /128
routes, the ULA addresses are also host routed. 

I'd also wonder if and how RAs can be used to supply the /128 or /3
addresses. It doesn't seem that the Prefix Information option would
support providing only 64 bits of prefix, to be combined with a 64 bit
IID, in the case of a global address, to come up with a node address,
yet have then host use a /128 or /3 prefix length on the interface to
indicate on or offlink destinations. Maybe a "prefix length to use"
option would need to be added.

ND Proxy solution might be another alternative that could be suggested
in this ID, as it effectively hides the structure of the links from
external parties.

I need to do some research into these issues, which I'll do tomorrow.
It's 1:10 here in .au, and I'll be going to bed soon. I appologise if
these issues are addressed in an RFC or ID I should have read. If it is
convenient, a URL or two would be useful if they exist.

If these issues aren't described or solved somewhere, I wonder whether
this ID should be recommending host routes as the somewhat preferred
solution to topology hiding ?

Regards,
Mark.

PS. sorry for the length, it got away from me a bit, thanks for reading this far.

---

From: Mark Smith <[email-masked]>
Date: Mon, 27 Jun 2005 18:22:17 +0930

Hi,

On Sat, 18 Jun 2005 01:18:42 +0930

> described in an ID or RFC that I'm not aware of ?

It looks like a /128 prefix length is not permitted on an interface,
according to draft-ietf-ipv6-addr-arch-v4-04.txt, which I think means
most of the issues I was concerned about described disappear.

I'm still not sure exactly how host routing would work from the
end-nodes point of view, so I'll continue to do some reading. It seems
to me that hiding the network or subnet topology by not grouping IPv6
addresses according to their common data links means that the subnet bit
portion of the address loses its significance when determining whether a
destination address is off or onlink, during Neighbour Discovery.

Thanks,
Mark.

---

From: Fred Baker <[email-masked]>
Date: Wed, 29 Jun 2005 09:07:31 +0100

> most of the issues I was concerned about described disappear.

For the record, a /32 is now permitted on an interface in IPv4. This 
permits allocation of such to a loopback interface, for example. It may 
be worthwhile to find the use cases for that and ask whether they apply 
to IPv6.

> addresses according to their common data links means that the subnet 
> bit portion of the address loses its significance when determining 
> whether a destination address is off or onlink, during Neighbour 
> Discovery.

More generally, when addresses cannot be summarized, summarization 
functions break down. Your friendly neighborhood ISP will have issues 
with this.