Hi, Elwyn,
Thanks for the quick response.
Feedback inline. If we agreed on a change, I deleted it in this response.
Spencer
Throughout the document - weasel-wording about "site local" appears in a
number of places. Do we have a sense whether this is still necessary? If
not, would be nice to delete; if still necessary, might be nice to
collect the guidance on site-locals into one place, to ensure that it's
consistent.
Hmm! I don't see this. Site local addresses (and the term 'site local')
are only mentioned in s4.2.5 in the context of a particular specification.
All the other instances of 'site' are talking about site boundaries and
characteristics of sites rather than site local addresses and I don't
think they can be collected up.
... must . not . review . docs . on . trans-Pacific . flights ...
Throughout the document - there are many recommendations that point out
IPv6 resistence to scanning attacks as part of the recommendation. I'm
wondering if some of these could be removed (since there is an explicit
section on resistance to scanning attacks in the document).
The main discussion occurs once in s3.2. Pointers back to s3.2 occur in
s4.2.1, s4.3.1, sA.5. This doesn't feel like 'many'.
If you guys are OK with this, I'm OK. I just kept seeing "scanning is no
problem in IPv6" repeatedly, and I'm not AS sure that this is true, as the
number of times it was asserted would make me think. (... "generalist ...
review ...")
Spencer/Editorial: The following text is really dense. Is it possible to
provide any hiearchy/abstraction, even if it's only a list of the 15 or
so
functions, without message detail, followed by the full version of the
list
appearing below? If it's possible to combine functions (for example,
grouping all of the discovery functions into one category, followed by
all
end-to-end signaling functions, followed by MIPv6 ...), that would be
better. A table would be better. Other proposals would be better.
I'll take this one under advisement. I agree it is dense (it has been
pruned once already). My feeling is that some grouping might be the best
answer. The ordering is mostly there already. Thus:
As they said about CIDR, sometimes ANY hierarchy is a good thing :-) your
direction here works for me.
3. Security Considerations
Firewalls will normally be concerned to monitor ICMPv6 to control the
Spencer/Editorial: "Firewalls will normally be used to monitor" - my
firewall seems extremely unconcerned most of the time, even when dropping
packets :-)
Maybe two nations separated by a language (again, sigh)! This is
concerned in the sense of involved (see Cambridge Online dictionary).
Merriam-Webster is subtly different: concerned = 'culpably involved' -
certainly applies to firewalls!
The irony of me attempting to edit your "English" is not lost on me...
Spencer/More-than-Editorial: Forgive my ignorance here, but are most
firewalls doing stateful deep inspection tracking for ICMP/ICMPv6 traffic
today? If not, this seems to need more discussion about why the
additional state is the right way to go.
Many firewalls can do state tracking for ICMPv6. I don't think we can say
much beyond or different from this - there is a disclaimer elsewhere that
states that we cannot require such state tracking or deep packet
inspection capbility, and without it there is nothing to be done at the
firewall.
You guys have the helm on this one. It wasn't clear to me whether you were
asking for firewalls to do something new, or for firewalls that already do
deep packet inspection to keep doing it.
4. Filtering Recommendations
This section suggests some common considerations which should be
borne in mind when designing filtering rules and then categorizes the
rules for each class. The categories are:
o Messages that must not be dropped: usually because establishment
of communications will be prevented or severely impacted.
Spencer/More-than-Editorial: why "usually"? ("Why would you pass messages
you didn't have to pass?")
Trying to cover my backside! The issue is pings. Pings must be passed if
you are doing Teredo and it is a really good idea to allow pings so that
connectivity can be checked, but they are not absolutely essential in
every case but it is going to be difficult to distinguish the two cases.
How to say this in one short sentence? Suggestions other than what I have?
"Messages that must not be dropped (because dropping may prevent or severely
impact establishing communications"?
Spencer/Editorial: "Messages that may be dropped, although they would
normally be dropped for other reasons anyway", and I think the
parenthetical
should inclide both the e.g. and the "or the protocol specification"
clause,
if I get the point being made.
No: There are two cases - this could be clarified as follows:
"Messages that may be dropped but it is not essential because they would
normally be dropped by the router/firewall for other reasons (e.g.,
because they would be using link-local addresses) or the protocol
specification would cause them to be rejected at the detsination if they
had passed through a router."
Actually there is an additional comment to make here. Firewalls
implemented as bridges may need to do different things because they don't
do routing activities. I'll add words to s4.2.3 to cover this case. This
means that they shouldn't filter connection on-link establishment
messages.
Ack.
Spencer/More-than-Editorial: I know the specification is targeted as an
Informational RFC, but this recommendation seems awefully hand-wavish
even for Informational ("you should drop them unless doing so is
over-zealous") - is there better guidance than "turn it off and see if
the phone rings"?
Ok. The point is that for almost all packets address scopes should match,
but if you apply this test to NS and NA messages, things will break.
So the node implementation has to ensure that scope match checking is not
done on these packets. This is not a firewall config or (that I have
seen) a user controllable host config issue. We could remove this
sentence or make it clearer that it is not something admins need to worry
about other than not to panic when they see this sort of packet.
If you explicitly name NS/NA as the exceptions, that would be clearer (to
the less clued).
A.2. Packet Too Big Error Message
If a network chooses to generate packets that are no larger than the
Guaranteed Minimum MTU (1280 octets) and the site's links to the
wider internet have corresponding MTUs, Packet Too Big messages
should not be expected at the firewall and could be dropped if they
arrive.
Spencer/More-than-Editorial: Having had experience with wireless links
that had a smaller MTU than the "guaranteeed minimum" in IPv4, I'm not
entirely comfortable with this guidance ("if you don't care about
communicating with people who violate the spec, drop the packets, and
hope there's no GOOD reason why someone is violating the spec"). At a
minimum, there's a balance between making the network more secure by not
passing unnecessary packets and making the path more fragile - maybe
that's guidance that would be helpful?
Fair comment, but the situation is a little different in IPv4. The
minimum is actually advisory in IPv4 - there is no hard limit, whereas
1280 is set in stone in the specs for IPv6 (OK very old specs had lower
values, but those are not in use today). I think we might get stick for
contemplating smaller packets.
I agree that striking a balance between assuming that everything meets the
spec and trying to accommodate things that don't meet the spec is a matter
of judgement. I'm good with what you guys say, in this case.
_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
