Subject: Last Call on draft-ietf-v6ops-security-overview-02.txt

From: Fred Baker <[email-masked]>
Date: Fri, 5 Aug 2005 07:08:19 +0200

With this note, I am opening a working group last call on draft-ietf- 
v6ops-security-overview-02.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.

---

From: Elwyn Davies <[email-masked]>
Date: Fri, 19 Aug 2005 16:03:49 +0100

Today is the last day of the wg last call for this document (assuming we 
actually count forwards ;-) ).

I have not seen any comments during the last call, but my own scan of 
the document has revealed a few nits and I have added an improved 
example in section 4.3.

The changes I am proposing are:

Changes:
02 -> 03
Several instances of 'unrecognized' appear to have vanished (probably 
while changing them from
unrecognised in the previous edit.
s2.1.4: s/an  /an unrecognized / (2 instances in next to last para)
s2.1.8.3: s/items  /items unrecognized /
s2.1.6: 2nd para: s/to for any future/for any future/
s2.2: last sentence s/and/ and/
s4.1: last sentence: s/in practice, not much used as a consequence/as a 
consequence, not much used in practice./
s4.3: added additional example of DHCP servers for guessable addresses - 
updated text is...

   Because the unmemorability of complete IPv6 addresses there is a
   temptation for administrators to use small integers as interface
   identifiers when manually configuring them, as might happen on point-
   to-point links or when provisioning complete addresses from a DHCPv6
   server.  Such allocations make it easy for an attacker to find active
   nodes that they can then port scan.

s4.5:s/in might/it might/

I have a new version ready to go unless there are any last minute comments.

---

From: Fred Baker <[email-masked]>
Date: Mon, 22 Aug 2005 10:47:02 +0800

I concur. Go ahead and post your update, and I'll send it to the IESG.

---

From: Tim Chown <[email-masked]>
Date: Mon, 22 Aug 2005 09:10:28 +0100

> the document has revealed a few nits and I have added an improved 

I agree it's ready.   Overall it's an excellent document.

A handful of minor comments:

One other minor nit: P.12, in 2.1.11

   o  IPv4  addresses are not universally supported across operating
      systems, and

=> 'IPv4 link-local addresses'

In 2.1.11.1

In addition to advertising 'routing services which it will not fulfill'
a node may be able to DoS by deprecating the existing good prefix.  With
router preferences (draft-ietf-ipv6-router-selection-07), an attacker may 
be able to launch a DoS attack, also with load balancing 
(draft-ietf-ipv6-host-load-sharing-04) there are similar concerns.  See
the security considerations sections of both documents.   I would also
say that in the example of IETF WLAN networks, DoS is not (probably) 
malicious, just misconfiguration with people not turning off their IPv6
configurations from other locations.   

In 4.1

I think this is a bit wishy-washy.  It's really saying that IPv6 firewall,
IDS and other security/resilience system implementations are lacking.
I think the last paragraph doesn't really fit at all.   One recommendation
should be that admins support IPv6 deployment such that they control it
rather than having (ab)users do so first.  Another could be that any
tunneled connectivity be terminated outside the site's (native) IPv6 firewall
(which may or may not be the same system as the IPv4 firewall).

In 4.4

For the security and management perspective, vendors and admins need to
assume that multiaddressing is normal in IPv6.  Being able to tokenise ACLs
and configs in general for multiple prefixes and/or addresses would be
generally useful.   I think the only way to disable privacy addresses is
to use full stateful DHCPv6 (where the client may request provacy addresses
to be allocated, but the server need not honour that).   I suspect many 
enterprise admins will wish to disable RFC3041.

In 4.7

May wish to look at or cite draft-ietf-ipv6-node-requirements-11 which
recommends base security implementation for IPv6 nodes.

In 4.8

Seems to overlap 4.1 in scope?  I'm not sure the second paragraph really
holds true now - at least separate admin experience from vendor 
experience :)

In 4.9

This is already said in 4.4?

In Appendix A:

"Hosts behind the
   6to4 router can use methods such as RFC 3041 addresses to conceal
   themselves, though."

=> Only if they are not meant to be reachable - otherwise they will have
   a static global address for receiving communications initiated inbound,
   while using 3041 for initiating communications outbound. 

In Appendix B.2:

Just cite NAP here?

In Appendix B.3:

I would say here most users would *want* a static /48, so they can run
services more easily.  

Cheers,
-- 
Tim/::1

---

From: Elwyn Davies <[email-masked]>
Date: Mon, 22 Aug 2005 10:21:56 +0100

I guess I have been overtaken by events.. Tim's comments are useful and 
looks like will not take long to incorporate. I'll reply to Tim and then 
get a new version ready.

Regards,
Elwyn

Regards,
Elwyn

---

From: Elwyn Davies <[email-masked]>
Date: Mon, 22 Aug 2005 13:36:13 +0100

Thanks for the comments.

Responses in line..  If there is no pushback from the mailing list I 
will incorporate the changes and send a note of the changes asap

Regards,
Elwyn

>=> 'IPv4 link-local addresses'
Yep.

>configurations from other locations.   
As an aside, having this section as a 4th level subsection seems a bit 
peculiar... the relation with 2.1.11 is  through SEND but the topic is 
really unrelated. I propose to promote it to level 3 as 2.1.12, 
renumbering Mobile IP to 2.1.13.

I think it would be useful to add notes pointing to the additional 
problems highlighted in these drafts, especially as these are headed 
towards RFC status.  I'll draft some text and send it out shortly.

>rather than having (ab)users do so first.  
>
This section is trying to a bit more than this: advising people to try 
and avoid the 'suck it and see approach' but still to 'please actually 
go and implement IPv6' rather than succumbing to FUD.  The emphasis 
should be on doing it properly, and that there are tools to help.

The last para has been around for a while.. it has got separated from 
the v6onbydefault reference which is where it belongs.  I'll try an come 
up with a better arrangement and a firmer recommendation.

>Another could be that any
This thought is well taken... I think it belongs in 3.3

What we are emphasising is that packets should be routed (at least 
logically) as follows:

'Inside' <---> IPv6 Firewall <---> v6 in v4 tunnel endpoint <---> IPv4 
Firewall <---> Outside

A sort of extra DMZ for IPv6.

>generally useful. 
Certainly making it even clearer that multiple addresses are a fact of 
normal life, and not an occasional aberration, for IPv6 would be 
worthwhile.  A few words of advice for vendors on ease of configuration 
also.

>  I think the only way to disable privacy addresses is
Again this would be a useful comment.. I'll add it.

>recommends base security implementation for IPv6 nodes.
It would probably be worth citing this earlier on in a more general 
context (maybe as well).

>In 4.8
>
>Seems to overlap 4.1 in scope?  
>
I think the changes I suggested above reduce the (perceived) overlap.  I 
think they are separate issues.

>I'm not sure the second paragraph really
The admin experience is certainly still true I believe.. we could alter 
the software piece to emphasise lower maturity.

>This is already said in 4.4?
A different perspective I think.. the issue of fast changing addresses 
does crop up in a number of places.  I don't propose to change this.

>   while using 3041 for initiating communications outbound. 
I'll add a few words.

>Just cite NAP here?
The business model discussion doesn't appear in NAP!  That being said 
the business model discussion cannot necessarily be solved by 
addressing.. Steve Bellovin's work on determining the number of hosts 
behind a NAT can be extended to IPv6 (although the data will be scarcer 
than in IPv4 because not all packets contain an IPid) (see the FNAT 
reference).

OTOH it would be worth citing NAP for further discussion of privacy 
issues for the whole of Appendix B.

>I would say here most users would *want* a static /48, so they can run
We could mention the conflict.

Regards,
Elwyn

---

From: Tim Chown <[email-masked]>
Date: Mon, 22 Aug 2005 13:43:57 +0100

Thanks Elwyn, those comments/answers are all fine to me.

B.2 is a can of worms, and probably not one to dig too deep into in a
document like this.   I just hope for IPv6 that ISPs appreciate that a
/48 (or /56 by RFC3177-bis) is the norm, and hence a per-device fee
is inappropriate.   I would assume many dual-stack home networks would 
run IPv6 on a /56 alongside an IPv4+NAT scheme.  

Tim

-- 
Tim/::1