Last Call Review of draft-ietf-v6ops-siit-dc-02
review-ietf-v6ops-siit-dc-02-secdir-lc-gondrom-2015-09-24-00
| Request | Review of | draft-ietf-v6ops-siit-dc |
|---|---|---|
| Requested revision | No specific revision (document currently at 03) | |
| Type | Last Call Review | |
| Team | Security Area Directorate (secdir) | |
| Deadline | 2015-09-22 | |
| Requested | 2015-09-10 | |
| Authors | Tore Anderson | |
| Draft last updated | 2015-09-24 | |
| Completed reviews |
Genart Last Call review of -02
by
Christer Holmberg
(diff)
Secdir Last Call review of -02 by Tobias Gondrom (diff) Opsdir Last Call review of -02 by Qin Wu (diff) |
|
| Assignment | Reviewer | Tobias Gondrom |
| State | Completed | |
| Review |
review-ietf-v6ops-siit-dc-02-secdir-lc-gondrom-2015-09-24
|
|
| Reviewed revision | 02 (document currently at 03) | |
| Result | Has Issues | |
| Completed | 2015-09-24 |
review-ietf-v6ops-siit-dc-02-secdir-lc-gondrom-2015-09-24-00
I
have reviewed this document as part of the security
directorate's ongoing effort to review all IETF documents being
processed by the IESG. These comments were written primarily
for the benefit of the security area directors. Document
editors and WG chairs should treat these comments just like any
other last call comments.
The draft aims for informational status and describes a
deployment model for traffic from legacy IPv4-only clients (on
the Internet) is translated to IPv6 upon reaching the data
centre.
The document appears mostly ok for publication with a series of
comments.
One main question:
Technically
this document looks
to me more like
standards and not informational as I think we need to
enforce consistent behaviour and restrictions to ensure
overall consistency. IMO we need to spell this out more
explicitly. This is a repeating element, I encountered in
this review across multiple sections of the document (see
explanations below).
COMMENTS:
0.
starting with a
personal comment:
in general it is nice to move again a
step closer to a V6, even though these series of baby transition
steps are quite small. Whether we need this in addition to other
existing 64 protocols, I leave to the V6ops WG who has much
better insight into this one than me.
1. This document has two strong requirements, that should be
expressed in 2119 language.
1.1. the SIIT algorithm MUST be used.
1.2. And the security considerations section MUST be followed.
2. Section 7 Security Considerations:
2.1. The listed concern is correct. The listed mitigation step
may work, I would suggest to also add a sentence when you do
choose this distinct translation prefix, you also must configure
your FW/GW at the edge to enforce the integrity of that naming
scheme (e.g. by dropping packets from that prefix if not coming
from a IPv4) to make sure there is no ambiguity or spoofing. We
must avoid a blend of translated and untranslated addresses in
the same prefix if you use the prefix as a marker.
2.2. I am not sure you covered all the security concerns in this
section.
2.2.1. e.g. we might want to expand more on the risk that the DC
does by design not see that we translate this down to V4 at the
edge and thereby loose some of the capabilities of V6 beyond the
edge. Therefore the DC may assume a fully V6 conformant client,
which is not the case. This may lead to the need of further
filtering or protection mechanisms at the edge.
2.2.2. the authors should expand more on architecture
requirements not to put two of these translators in sequence
(see possibly conflicts with 2.2.3. the authors should expand
more on restrictions of putting this in a mixed environment with
NAT64
3. section "4.4. Choice of Translation Prefix"
- states: "Either a Network-Specific Prefix (NSP) from the
provider's own IPv6 address space or the IANA-allocated
Well-Known Prefix 64:ff9b::/96 (WKP) may be used."
I think this needs to be a MUST instead of the "may". Also I do
not like the ambiguity of prefixes here. We need to make it
clear that this translastion MUST be consistent across all edges
to the DC.
4. section 4.5. routing considerations:
- do we need to specify that all alternate BRs must use the same
algorithm and all MUST be able to support SIIT-DC?
5. section 4.6:
we say "This should be understood to include all servers,"
I am not sure this is only a "should". From a lingual
perspective it might be meaning that it "it should be understood
that it requires..." but as the word "required" is not used, it
is a bit unclear to me, whether that is also understood by the
author/WG for this protocol.
6. section 4.8.:
we use "To facilitate reliable delivery of such ICMPv6 errors n
SIIT-DC operator SHOULD implement the recommendations in
[RFC6791] in the BRs." Is there a security consideration on the
impact what happens if RFC6791 is not followed and ICMPv6 errors
are dropped? What would be the security implications of loosing
not transmitting these messages?
7. section 4.9. "MTU and Fragmentation":
it is good that we spell out the series of key differences
between IPv4 and IPv6 relating to packet sizes and fragmentation
that one needs to consider when deploying SIIT-DC. I am not sure
a "should" is sufficient here. Furthermore, it would be good to
consider whether we need to specify and mandate the specific
behaviour when encountering these limitations to avoid
inconsistent behaviour from the BR if these parameters are
encountered and this might be exploited as an attack vector.
Thank you and best regards.
Tobias