Petra, hi Thnx for comments, please see my thoughts inline :) On 7.10.10 23:16, S.P.Zeidler wrote:
Thus wrote Jan Zorz @ go6.si (jan@go6.si):
Host: - IKEv2 mandatory: why? You are aware that IKEv2 systems won't play with IKEv1 systems and that IKEv2 is not very popular at present, too? I suggest that one at least should ask for ISAKMP too, this keeps all options open what will be used.
Not sure. We could move that to optional, but can't decide. Suggestions?
On second thought, require both IKEv2 (some of its features are rather useful) and ISAKMP; thus you're very likely to be able to talk to your counterpart.
OK. So where IKEv2 is required I add ISAKMP. Which RFCs you suggest to reference? @list: do we agree on that?
To clarify:
Enterprise switch: - RA-guard: your enemy is not -unsolicited- RA, your enemy is -unauthorized- RA. As in, the laptop your sales guy brought in announcing itself as the gateway to the world, even if RA was solicited.
AFAIK RA-guard prevents RA packets being sent from ports, that are "declared" as "hosts" ports and connected hosts not authorized to send RA as such.
Now it is: - RA snooping must be used in the network to block unsolicited RA messages I think it should read: - RA filtering must be used in the network to block unauthorized RA messages
i.e. I assume you are thinking of the right thing, but using the wrong words.
Ok, changing "unsolicited" to "unauthorized"
enterprise/ISP grade switch, mandatory support: - DHCPv6 filtering (port based suppression of origination of DHCPv6 messages is ok) - Router Advertisement (RA) snooping - RA filtering to block unauthorized RA messages (port based RA origination supression ok) - Dynamic "IPv6 neighbour solicitation/advertisement" inspection (note the typo, it's RFC2461 not RFC24611) - IPv6 neighbour solicitation/advertisement filtering similar to "Dynamic ARP inspection". ... - Neighbour Unreachability Detection [NUD, RFC2461] snooping - NUD filtering - Duplicate Address Detection [DAD, RFC4429] snooping and filtering. It must be possible to restrict DAD message source addresses originating on a port. (note the typo, DUD -> DAD)
optional support: [...] - IPv6 Routing Header [RFC2460, Next Header value 43] snooping - IPv6 Routing Header filtering (port based suppression ok) - UPNP filtering (I'm assuming this is Universal Plug& Play UPnP)
'customer ports' does not have sufficient meaning. In an enterprise none of your ports is populated by a customer. We need an expression for "neither router nor DHCP server nor trunk".
Well, I would remove word "customer". Just "ports".
Also, why would you specifically try to avoid UPnP to do something useful, but allow useless messages to pass?
This part is suggested by Torbjorn, he's on the list. I suggest we change "must" to "should". Changed L2 enterprise grade list: Mandatory support: - MLDv2 snooping [RFC4541] - DHCPv6 filtering [RFC3315] DHCPv6 messages must be blocked between subscribers and the network so no false DHCPv6 servers can distribute addresses - Router Advertisement (RA) filtering [RFC2462, RFC5006] RA filtering must be used in the network to block unauthorized RA messages - Dynamic "IPv6 neighbour solicitation/advertisement" inspection [RFC2461] There must be an IPv6 neighbour solicitation/advertisement inspection as in IPv4 “Dynamic ARP inspection”. The table with MAC-address and link-local and other assigned IPv6-addresses must be dynamically created by SLAAC or DHCPv6 messages. - Neighbour Unreachability Detection [NUD, RFC2461] filtering There must be a NUD filtering function so false NUD messages cannot be sent. - Duplicate Address Detection [DAD, RFC4429] snooping and filtering. Only allowed addresses must be allowed as source IPv6-addresses in DAD messages from each port. Optional support (management) - IPv6 Basic specification [RFC2460] - IPv6 Addressing Architecture basic [RFC4291] - Default Address Selection [RFC3484(bis)] - ICMPv6 [RFC4443] - SLAAC [RFC4862] - SNMP protocol [RFC3411] - SNMP capabilities [RFC3412, RFC3413, RFC3414] - IPv6 Routing Header [RFC2460, Next Header value 43] filtering IPv6 Routing Header messages must not be allowed between subscriber ports and subscriber and uplink to prevent routing loops [See also RFC5095, Deprecation of Type 0 Routing Headers in IPv6] -UPNP filtering UPNP messages must always be blocked between customer ports. There may be a possibility to filter different Ether types to allow only 0x86dd between subscriber ports. And most probably you must also permit 0×800 and 0×806 for IPv4.
- optional IPv6 basic, SNMP How do you plan to admin that switch in a v6-only network? walk by and use a serial cable? Enterprise class equipment also really should do SNMP
We thought of putting in mandatory requirements stuff that is already imlemented, so we are not necessarily eliminating too much equipment and put some stuff in optional for vendors implementing optional requirements to get more points on tenders - encouraging them to deploy more optional requirements.
When this gets implemented we can move that to mandatory.
You expect a switch to actually support filtering on RA and -not- be able to support logging in via IPv6?! All new switches on the small side I met recently supported adding v6 addresses for management if they supported v6 at all, but I haven't had a device that supported RA filtering in my fingers yet.
Ok. Since this comment came up many times, I'm moving IPv6 on management to mandatory section.
[BGP on firewalls]
That's why it says "if requested". I agree that BGP is not best run on firewall, but some people practice that idea, mainly because of cutting-costs and for small-mid companies it might work out well ofr most of the time.
eeeewyuck. Well, it'll not be my funeral :-P
Well, this "if requested" moves the decision on customer side. I presume discussion on BGP-and-firewall-on-same-box is not the case in this document, but I suggest we make one and say "don't do that".
Skill requirements: much as a certificate does not guarantee skill, its absence doesn't guarantee the absence of skill either. Do you have any IPv6 certificates that have any meaning?
No. Not at all. That's why I took a declaration from one government tender and modified it to include also IPv6. This is self-regulation, if systems integrator is sure, that his staff is good-to-go for the job that needs to be done, they will sign that declaration.
But if someone signs your text they sign that I have at least three staff that have CERTIFICATION by a vendor on general knowledge of the IPv6 protocol, IPv6 network planning and IPv6 security.
It does not say "certification or knowledge".
It says "they need to have a certificate".
It also says that they need to know their stuff, but that is an AND, not an OR.
Good point. You suggest "certification or knowledge". How can we measure "knowledge"? We need to describe that, if we use above wording. Do we want to include "years of experience"? Cert, knowledge and experience are sometimes very different animals.
Rmember, it says "declares, under criminal and material responsibility". That's not a joke, if you sign that and have no competent people to do the job properly.
But they also have to have a piece of paper. I.e. -you- would currently be disqualified, since you don't have certification on IPv6 if I read your no correctly. Being an expert is not enough if you keep that wording.
Agree. /jan