Re: [secdir] secdir review of draft-ietf-v6ops-siit-dc-02

[Tobias Gondrom <[e-mail]>]

Thank you for your feedback.
answers inline.

On 07/10/15 09:55, Tore Anderson wrote:
> Hello Tobias, and thank you very much for your feedback!
>
> My comments in-line.
>
> * Tobias Gondrom <[e-mail]>
>
>> 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).
> The only standard/protocol used SIIT [RFC6145] plus its EAM extension
> [I-D.ietf-v6ops-siit-eam]. That is, if an operator has an
> implementation of RFC6145 and I-D.ietf-v6ops-siit-eam, then the
> operator can use that implementation to deploy SIIT-DC as described in
> I-D.ietf-v6ops-siit-dc.
>
> No additional protocols, algorithms, or features is used beyond those
> already specified in RFC6145 and I-D.ietf-v6ops-siit-eam are required.
> This is the reason on why I-D.ietf-v6ops-siit-dc is Informational; it
> merely describes one way to deploy the standard protocols defined
> elsewhere in the context of a specific use case.
>
>> 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.
> Ok, how about this (in section 2):
>
>     SIIT-DC Border Relay (BR)
>        A device or a logical function that performs stateless protocol
>        translation between IPv4 and IPv6. It MUST do so in accordance with
>        [RFC6145] and [I-D.ietf-v6ops-siit-eam].

WFM.
>
>> 1.2. And the security considerations section MUST be followed.
> Like so?
>
>     If a Network-Specific Prefix from the provider's own address space is
>     chosen for the translation prefix, as recommended in Section 4.4,
>     care MUST be taken [...]
WFM. Thanks.
>
>> 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.
> I disagree with this. RFC6052 makes a distinction between
> "IPv4-converted" IPv6 addresses (which occur in packets that were
> originally IPv4 packets) and "IPv4-translatable" IPv6 addresses (which
> are normal unicast addreses that happen to follow the address format
> specified in RFC6052).
>
> If I understand you correctly, what you propose here would be
> essentially mean forbidding the use of IPv4-translatable IPv6
> addresses. In my opinion, I-D.ietf-v6ops-siit-dc is not the right place
> for such an undertaking, that would require updates to RFC6052 and
> RFC6145 (and probably others).

ACK. It was a suggestion. I still think that there is a potential 
security risk coming from that, but I leave this to the WG to decide.

>
>> 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.
> I am having difficulty understanding exactly what the possibly security
> concern you have here is, and how it would need to be mitigated.
>
> Keep in mind that one can perform IPv4-to-IPv6 translation anywhere on
> the Internet. In other words, any IPv6 packet received by any node is
> possibly translated from IPv4. So if there truly is a security concern
> here, it would apply to any deployment of IPv6 (except isolated
> networks not connected to the Internet).
>
> If you'd like a demo of the above, by the way, you can visit
> http://87.238.60.1/. This traffic is routed to one of my SIIT-DC BRs
> located in Norway or Sweden, and afterwards forwarded as IPv6 to the
> site "www.whatismyipv6.com" in the USA (I have no affiliation with this
> site and it's not in my network). This means that if the
> www.whatismyipv6.com web site incorrectly "assumes [your connection is
> from] a fully V6 conformat client", and this assumption somehow causes
> a security concern, then that security concern would have much wider
> ramifications than being of interest only to operators who are
> deploying SIIT-DC and thus are likely to read I-D.ietf-v6ops-siit-dc.
> It would also apply to RFC6146, as you can use Stateful NAT64 to
> accomplish the same thing as I use SIIT-DC.
>
>> 2.2.2. the authors should expand more on architecture requirements not
>> to put two of these translators in sequence (see possibly conflicts with
> This is exactly the subject being discussed in
> I-D.ietf-v6ops-siit-dc-2xlat, which is referred to numerous times.

Noted.
>
>> 2.2.3. the authors should expand more on restrictions of putting this in
>> a mixed environment with NAT64
> To the best of my knowledge, there exist no such restrictions, beyond
> the fact that you'd need to use differing RFC6052 prefixes. This fact is
> mentioned in section 4.4.
>
>> 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".
> Could you elaborate on why? From a technical point of view, the WKP
> works just as well as any NSP, and if the operator really wants to use
> it (in spite of the stated disadvantages), I do not see that I have any
> justification for denying that outright.
>
> Note that RFC6052 also discusses the use of a WKP vs an NSP at length in
> section 3.3; while it advises the use of an NSP, it does not make it a
> MUST. I fail to see a rationale for making I-D.ietf-v6ops-siit-dc be
> more restrictive.

One of my concerns is to avoid the case where addresses from none of the 
two would be used and potential risks arising from that. I am also not 
sure why we should leave this open as a "may" instead of locking this 
down with a "MUST". However, my knowledge is not as deep as yours on 
this, so I leave this to you and your WG.

>> 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.
> Section 3 states:
>
>     Any number of BRs may exist simultaneously in the IDC's network
>     infrastructure, as long as they all configured with the same
>     Translation Prefix and an identical EAM Table.
>
> Is this somehow unclear? If so, could you propose an improved text?
>
>> 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?
> There exists only one definition of "BR" in the document:
>
>     SIIT-DC Border Relay (BR)
>        A device or a logical function that performs stateless protocol
>        translation between IPv4 and IPv6 in accordance with [RFC6145] and
>        [I-D.ietf-v6ops-siit-eam].
>
> It would appear to me, therefore, that the document already makes the
> statement you propose. That is, it is impossible for an alternate BR to
> use another translation algorithm, because if it did so, it would by
> definition no longer be a BR.
That might be the case. It might not have been clear to me during the 
review. Therefore my question. Please consider this only as a suggestion 
or question for your decision.

>> 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.
> Ack. How about this?
>
>      [..] the BRs must be located somewhere between the IPv4 Internet
>      and the application delivery stack - which includes all servers,
>      load balancers, firewalls, intrusion detection systems, and similar
>      devices that are processing traffic to a greater extent than merely
>      forwarding it.

WFM. Thank you.
>
>> 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?
> That is a question for RFC6791, which states the following:
>
> 6.  Security Considerations
>
>     This document recommends the generation of IPv4 ICMP messages from
>     IPv6 ICMP messages.  These messages would otherwise have been
>     discarded.  New considerations are not expected to result from this
>     change.  As with a number of ICMP messages, a spoofed source address
>     may result in replies arriving at hosts that did not expect them
>     using the facility of the translator.
>
>> 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.
> Ack, will change to "must".

Thank you.
>
>> 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.
> True, but on the other hand if such attack vectors exists it is
> extremely likely that these are not specific to SIIT-DC, but in SIIT
> [RFC6145] itself and in quite possibly other derivative protocols such
> as Stateful NAT64 [RFC6145], MAP-T [RFC7599], and likely others.
>
> As I mentioned earlier, please keep in mind that SIIT-DC is just
> description of how one can go about deploy SIIT [RFC6145] in a
> particular environment; it does not specify any new protocols or
> algorithms. If there are inherent security problems inherent in the
> protocols used by SIIT-DC, then the right place to deal with or
> document those problems is in the specifications of those protocols,
> not in a use-case document such as I-D.ietf-v6ops-siit-dc.
>
> Tore


Thank you for your reply and considerations.

Best regards, Tobias