[ipv6-wg] New draft document available: Requirements For IPv6 in ICT Equipment

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

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