Re: Last call on draft-ietf-v6ops-nap-01.txt

[Mark Smith <ipng@69706e6720323030352d30312d31340a.nosense.org>]

Hi Everybody,

On Fri, 5 Aug 2005 07:08:20 +0200
Fred Baker <fred@cisco.com> wrote:

> With this note, I am opening a working group last call on draft-ietf- 
> v6ops-nap-01.txt. This WGLC will close in two weeks, at close of  
> business 19 July. Please read the document and comment to the list -  
> either say that the document is ready, or say what issues you may  
> have with it.
> 
> Thanks.
> 

Some comments. Mostly editorial / readability related, nothing really
that significant I think. Got a bit long unfortunately. I was reading
and commenting at the same time.

I'm aware of and agree with the the points that were in the IETF63
presentation, so I haven't commented on them.

2.2  Simple security due to stateful filter implementation

"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."

I'm not sure that bandwidth concerns (presumably caused by the threat of
DoS style attacks) are the main reasons why people put firewalls in.
Rather, I think in most cases it would be the other way around - people
put firewalls in to control the types of traffic that can enter or leave
their network, and the reduction in unwanted traffic because of that
control is a beneficial side effect.

Possibly this text could be rephrased or expanded on, mostly only
because it appears to be making an absolute statement of what a firewall
is used for, and I don't think unwanted traffic volume reduction is
necessarily always the reason.

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

I'd think it would be better to say something along the following lines, as NAT
does provide some security, just as not as much as most people think  -

"For these reasons the actual level of security provided by NAT can be
significantly less than commonly perceived."

"The perceived security comes from the lack of pre-established or
permanent mapping state."

I suggest extending this statement -

"The perceived security comes from the lack of pre-established or
permanent mapping state, which is only guaranteed to occur when the
Network Address Port Translation (NAPT) form of NAT is used."

"... however when the
   merging networks were already using address translation it will
   create huge problems due to admistrative difficulties of the merged
   address space."

I'm a bit confused by this text. Is the "address translation" being
referred to being used towards the Internet, not the address translation
that has temporarily been put in place between the two organisations ?
I.e. the two organisations are each using 10/8, and have NAT boxes at
their Internet connections. They then want to connect together, also
using (two instances) of NAT, to make the "other" 10/8 appear to be some
other, non-local address space. Assuming that one of the 10/8s is
renumbered, and NAT between the organisation is removed, is the "address
translation" above referring to the remaining Internet NAT ?

3.3  DHCPv6 prefix delegation

At the moment, this section describes what the Prefix Delegation
function does, however I don't think it really connects it with the NAT
function it is substituting for, namely the ability to just plug a
NA(PT) box in and have access to the Internet work straight away.

I think a small amount of text exanding that description would be
helpful, similar to the first paragraphs of " 3.1  Privacy addresses
(RFC 3041)" and "3.2  Unique Local Addresses".

3.4  Untraceable IPv6 addresses

I think this section / feature might be misnamed. These addresses aren't
completely untraceable, rather, they are only traceable to to the edge
of the network assigned the /48. A better description or name might be
"Hidden Internal Topology IPv6 addresses". Or maybe not :-) "Opaque
Subnet IPv6 Addresses" ? Anyway, something that doesn't suggest that
they're completely untraceable.

I also think that the last paragraph would be better positioned as the
first in this section.

I think the statement,

"These should be globally routable IPv6 addresses which can be
   randomly and independently assigned to IPv6 devices."

could be a bit more descriptive by adding ", within the internal
topology." I think this also further makes it clear that this
untraceability property extends to the whole of the Internet.

4.2  IPv6 and Simple security

Very minor, "::/64" should probably be "(/64)" eg.

"3.  The size of the typical subnet (/64) will make a network ping"

I realise a few of the authors probably have English as their second
language, so I'm guessing this isn't intentional :

"This simple rule would create similar protection and security holes
   the typical IPv4 NAT device will offer ..."

This made me chuckle a bit when I first read it, as to a first language
English speaker, it reads like the security holes of a typical IPv4 NAT
device are something worth aiming for, as though they are good features.
Unfortunately some native English speakers who might not be aware of
NAT's limitations and may be becoming aware of them via this draft may
also read it that using IPv6 in this way is also "as bad as NAT".

I'd suggest dropping the "and security holes" :

"This simple rule would create similar protection the typical IPv4 NAT
device will offer ..."

Actually, it may be best to qualify the type of NAT being used. In this
section it is only really NAPT that is guaranteed to provide this style
of "reflexive" protection.

4.3  User/Application tracking

"IPv6 enables the collection of information about data flows."

I'm not really sure that IPv6 "enables" it, in the sense that it is a
feature of IPv6. Proper end-to-end, visible addressing does facilitate
it, although it would either require a host based reporting mechanism,
or the insertion of more than just a router  e.g. a firewall in line
with the traffic flows.

I'd suggest slighly refocusing this section to state that assigning and
making visible (ie. not NATting them) unique IPv6 end-node addresses can
facilitate User/Application tracking, but also make it clear that an
additional device or service needs to be added to do that as it is not
an inherent feature of IPv6.

While I understand the purpose of this section regarding matching a
possible use of NAT, it reads a bit too pro-privacy intrusion to me,
although that may be a personal value judgment rather than something
that needs to be changed in the RFC. It also may be worth adding that
Privacy Addresses and IPsec, which _are_ standard features of IPv6, may
limit or prevent the ability to perform User / Application tracking, at
least by network located devices. (hmm, these days it seems, I keep
coming across examples of where things are best done at the ends or on
the hosts, this being another one.)

4.4  Privacy and topology hiding using IPv6

Along the lines of using Mobile IPv6, another possibly simpler solution,
assuming the administrator is willing to wear the administrative
overhead, would be to have hosts act as end-points to statically
configured IPv6 in IPv6 or GRE tunnels. I'm not sure how widely
implemented Mobile IPv6 is, I know that most IPv6 capable OSes would
support this manually configured tunnel method today.

4.5  Independent control of addressing in a private network

Sort of minor :

" ... and may shrink/grow these
   as their network user base/etc changes.  In v6, it's all /64."

conflicts a bit with 

"3.  The size of the typical subnet ::/64 will make a network ping" 

in "4.2  IPv6 and Simple security"

I say "sort of" minor because I think it is necessary to either have the
RFC take the position that all IPv6 subnets will be /64s (making the
first quote above correct), or take the position that most subnets, but
not all, will be /64s. 

I'm also a bit conscious of this point as I recently saw some IPv6
addressing discussion on the nanog mailing list. I read that somebody
was considering allocating out something like /124s to their residential
customers, because they couldn't see a need for a customer to connect
more than 16 devices to their home LAN. The point that person has missed
is that the /64 is a /64 not because it needs to be, rather, it is
convenient for it to be, similar to 802.1 MAC addresses being 48 bits in
size for convenience rather than necessity. 

This "give customers _only_ what (I think) they need" mentality is
certainly quite understandable for IPv4. It obviously mostly isn't in
IPv6. It's possibly out of scope for this RFC, although I think it could
be argued that IPv6 Network Architecture Protection could include
ensuring that features such as privacy addresses, or easy renumbering of
the network without having to renumber subnets is a architectual
property of IPv6 that should be preserved, by avoiding naive address
allocation methods. Possibly specifying some rules or strong guidelines
regarding what prefix lengths are appropriate would be useful, assuming
that "all subnets are /64s" isn't the position taken.

4.6   Global address pool conservation

I've just got to this section which discusses the global address
space size. Possibly a bit of the above text, specifically regarding a
/64 being sized mostly for convenience rather than necessity, could be useful
to add to this section.

5.2  Small private networks

5.3  Single user connection

In 5.2 seems to suggest a single /64 might be satisfactory for a single
device in the last paragraph, and I think in 5.3 it implies it. I can
imagine a scenario where, specifically in the case of 5.3, a person has
a blue tooth capable phone, that could also act as an IPv6 router for
other blue tooth devices capable such as a PDA, allowing the PDA to have
a "proper" IPv6 connection to the mobile phone network. Technically
they're a single user, yet they need more than a single /64. In this
case the mobile phone would need to be allocated at least a /63, and
therefore, for convenience reasons, a /48 assignment to the phone would
probably be better. I think it could be worth describing this or a
similar scenario as to why a /48 is a useful prefix length for even a
single user. (Technically the blue tooth phone could possible act as a
bridge for the PDA, although the PDA and the phone may also have ULAs,
so the phone is likely to have IPv6 forwarding / processing /
firewalling capabilities anyway. It may be better and more secure to
have the blue tooth phone act as a IPv6 router.)

5.4  ISP/Carrier customer networks

Minor :

"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."

"section 5.1" rather than "chaper 5.1" ?

"Using these local scope   addresses would also prevent
<insert>them</insert> from being accessed from the^H^H^H an external  
network."

"These will typically be assigned with prefix lengths terminating on
nibble boundaries to be consistent with the DNS PTR records."

Is this suggesting non-/48 or /64 assignments to end-users, as /48s and /64s fall on
octet rather than nibble boundaries ?

This section also mentions 3GPP and multi-subnet scenarios, which I
commented on above. I'd think that if this multi-subnet scenario can
exist in a 3GPP scenario, it could also exist in others that we haven't
thought of (e.g. Wimax maybe ?), so I'd still think some discussion of a
"single user, multi-device" scenario could be useful in section 5.3,
even if it didn't use a mobile phone / PDA situation as an example,
because it is covered in this section.

That's it I think. Sorry for the length. Thanks for reading this far,
very much appreciated. Namaste.

HTH,
Mark.