[ipv6-wg] New draft document available: Requirements For IPv6 in ICT Equipment
- Previous message (by thread): [ipv6-wg] New draft document available: Requirements For IPv6 in ICT Equipment
- Next message (by thread): [ipv6-wg] New draft document available: Requirements For IPv6 in ICT Equipment
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
S.P.Zeidler
spz at serpens.de
Thu Oct 7 23:16:06 CEST 2010
Thus wrote Jan Zorz @ go6.si (jan at 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. 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. > > entire section: > > to snoop means "to listen secretly". You don't want to listen > > to those packets, you want to block them, selectively. That is called > > filtering. Half the section wants s/snoop/filter/ > > This was also Ole Troan's comment: > > "Would change snooping to inspection in some cases. Or use SAVI terminology" > > Looks like we need to change this somehow, but not sure where to use > "snooping", where "inspection" and where "filter" 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". Also, why would you specifically try to avoid UPnP to do something useful, but allow useless messages to pass? > > - 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. [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 > > 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. > 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. regards, spz -- spz at serpens.de (S.P.Zeidler)
- Previous message (by thread): [ipv6-wg] New draft document available: Requirements For IPv6 in ICT Equipment
- Next message (by thread): [ipv6-wg] New draft document available: Requirements For IPv6 in ICT Equipment
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ ipv6-wg Archives ]