[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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

Tim Chown wrote:

On Fri, Aug 19, 2005 at 04:03:49PM +0100, Elwyn Davies wrote:


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.



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'


Yep.

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.

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.

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.

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
tunneled connectivity be terminated outside the site's (native) IPv6 firewall
(which may or may not be the same system as the IPv4 firewall).


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.

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.

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


Again this would be a useful comment.. I'll add it.

In 4.7

May wish to look at or cite draft-ietf-ipv6-node-requirements-11 which
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
holds true now - at least separate admin experience from vendor experience :)


The admin experience is certainly still true I believe.. we could alter the software piece to emphasise lower maturity.

In 4.9

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.

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. 

I'll add a few words.

In Appendix B.2:

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.

In Appendix B.3:

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

We could mention the conflict.

Regards,
Elwyn


Cheers,