Subject: [v6ops] draft-ietf-v6ops-464xlat-optimization-02 - 5.2.6 and the rest

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Sun, 19 Jul 2020 23:54:12 +0200

> 5.2.6.
> "The existing EAMT entry for 192.0.2.1 is set as invalid".

Clarify that:
* 5. Existing connections to 192.0.2.1 remapped to 2001:db8::a:b:c:d
  MUST NOT be broken.

[Jordi] Yes, this has been solved with the stale status :

5.  The existing EAMT entry for 192.0.2.1 is set to Stale

And
5.2.13.  False detection of a dual-stack host as IPv4-only
 
   If a dual-stack host is being detected as IPv4-only, is because it is
   not responding to the CE ND messages, so by all means, should be
   considered, at the time being, as IPv4-only, and consequently EAMT
   entries will be created and traffic will be optimized for IPv4 flows.
 
   However, if this hosts suddenly become IPv6-enabled (or dual-stack),
   the relevant EAMT entries must be flagged by the CE as "Stale".  The
   host will be able to complete the connections and the entries will be
   marked as "Invalid" and deleted.
 
   Anyway, those EAMT entries, while "Valid", may not be actually used
   by the dual-stack hosts, because those hosts or applications should
   prefer IPv6, so most probably was either a temporary failure or done
   on-purpose (user, troubleshooting).  If the host is preferring IPv4
   for connecting to the CDN/cache or IPv6-enabled service, it will be
   actually using the NAT46/CLAT, including the EAMT entry and
   consequently IPv6, so this mechanism will be correcting an
   undesirable behavior.  This may be also a special case, which
   actually seems to be an incoherent host or application
   implementation.

=======

> 5.2.7.  Behavior in case of multiple A/AAAA RRs

Agreed with Jen's earlier comment that this needs more clarification.  Example algorithm:

* For each A record on the A RRset, create an EAMT entry with a randomly
  selected record from the AAAA RRset.

* Resolver should ideally randomly permute the A RRset prior to
  returning to the client

[Jordi]  If I got correctly what you mean, the goal is to ensure that several devices using the same CDN resources, get different A/AAAA pairs (EAMT entries). Also, that the same CE in different customers, is not “always” using the same A/AAAA pair, so the load is “balanced” as much as possible among the CDN resources. I couldn’t fine if this is already specified at that level in a previous document, so while I assume some random is applied in resolvers, we want to take the opportunity to ensure it. So maybe:

5.2.9.  Behavior in case of multiple A/AAAA RRs

   If multiple A/AAAA RRs are available, any of them could be

   chosen and in general, the optimization will not present any

   different result to the hosts compared with a situation where the

   optimization is not used.

   Existing DNS proxy/stub resolvers already implement mechanisms for

   DNS Load Balancing ([RFC1794]).  This don't need to be modified to

   implement the optimization, if some degree of randomness is already secured.

   To secure sufficient randomness, a possible algorithm shall ensure

   that different EAMT entries (for different hosts) are permuted

   randomly among different A/AAAA records on the A/AAAA RR set.

==========

> 5.2..10 Behavior in case of Foreign DNS

How will the mismatches that should trigger invalidations
get detected in this case?

* Breakage due to as mismatches won't be detected and result in invalidations
 if one device or app is doing lookups via this resolver but another is not.
  Constraining the EAMT entry to the IPv4 client IP could at least bound
  the damage to a single device, but not if some apps on it use different
  resolver schemes.

* I believe Google ships Chromecast to hardcode DNS lookups to 8.8.8.8
  in addition to also sometimes using the local resolver.  Some other STBs and mobile apps
  do the same.  This has significant potential for mismatches to not get
  detected and not get invalidated.

[Jordi] All this is no longer a problem: We don’t optimize if a foreign DNS is  used.

================

> 5.2.13.  Troubleshooting Implications

How do corner-cases around collisions where EAMT entries
don't get proprerly invalidated get debugged by the ISP
(and content provider!)?

This is opaque to the CDN and could result in lots of escalations from
end-users and customers.  The net result will be for content to get
switched to IPv4-only if that "fixes" the problem which might impact
users world-wide.  (Neither the CDN or their customer has any
visibility into what is going on here other than that some end users
may be reporting not being able to view dual-stacked content.)

[Jordi] If the troubleshooting is done with dual-stack host, no issues. If it is an IPv4-only host, the optimization can be fully disabled, or specific entries can be disabled. Is not that solving the problem? This is the text I’ve right now:

5.2.15.  Troubleshooting Implications
 
   When there is a need to troubleshoot IPv4 from the CE LANs, it may
   happen that there is an EAMT entry forcing the flow to a given
   destination(s) to use IPv6, which will distort the results, unless
   the host being used is dual-stack (which is the most common
   situation).
 
   This can be avoided, using a CLI/GUI or provisioning procedure, to
   either completely disable the optimization during the
   troubleshooting, or create specific static EAMT entries, using the
   Valid/Stale/Invalid and Auto/Static flags, as described in
   Section 5.2.5.
 
   Consequently, the CE MUST allow both, disabling the optimization and
   the setup of manual/static EAMT entries.

============
General for 5.2.x:

* Should this doc use more normative language in places where warranted?
  (There are a bunch of MUST NOT sharp edges.)
  Especially in 5.2.4.

* Clarify that EAMT table updates MUST be made before A record
  is returned to the client (especially invalidations!).  Otherwise there
  is a potential race condition..

* What happens if the FQDNs mismatch but the A and AAAA RRsets are identical?
This is going to be very common as many CDNs use lots of names
 with a smaller number of IPv4 addresses.
  What if the A and AAAA RRsets overlap but aren't identical?
  (Perhaps the EAMT entry MUST be marked invalid if the FQDNs mismatch
  and the EAMT entry does not have both its A *and* AAAA values
  in the returned RRsets.  ie, all EAMT entries must be valid
  within the mismatching FQDN.)
  (May still be corner cases here I'm forgetting?)

[Jordi] I think all this has been already resolved.

* We have a recommended maximum cap/threshold on the TTL?
  (even if it's something like 8 hours...)  Otherwise bad entries
  might stick around too long.

[Jordi] This is an open question. I don’t know if it makes sense to invalidate the stale entries if the connections don’t die … and if so, I guess your 8 hours come from your CDN view of operational details (changes in FQDNs/A/AAAA), or it is just random?

==========

Additional security considerations:

(The first of these is minor --- the others seem like they make this too dangerous to deploy.
It may be worth having a Security AD do some focused review in this context.)

* Filling EAMT table with very long TTL records.  (ie, triggering a client to
  do DNS lookups that create lots of long-lived associations)

[Jordi] Yep,  same point as the 8 hours. Should we set some limits for the EAMT entries, despite the TTLs?

* There is an serious risk exposure to hijacking traffic by inserting bogus binding
  (ie, return target's A record and malicious actor's AAAA record).
  In most cases these records should get marked as Invalid,
  but the corner cases here are fragile (eg, with foreign DNS or
  clients caching past the TTL mixed in here.
  An example attack here is that a client has an A record
  for "www.example.com" pointing to 192.0.2.1 cached past
  its TTL so the EAMT record is gone.  An attacker convinces
  another user in the same home network to do a DNS lookup
  that has an A record of 192.0.2..1 (which the attacker doesn't own)
  but a AAAA record for 2001:db8:eeee::eeee (which is attacker-controlled).
  Even if 192.0.2.1 is IPv4-only, if the EAMT entry has expired or never
  existed then the attacker can redirect all traffic to it to an IPv6 address
  of their choice.  No DNS spoofing is needed here at all, just making
  a "claim" that the A/AAAA are associated (which has no authentication).
  This is potentially worse as I'd hypothesize that IPv4-only STB
  clients are much less likely to use HTTPS/TLS..

[Jordi] I think that having a per-host EAMT entries resolves this.

* This previous risk is particularly problematic for hijacking traffic from
  users/devices/clients using Foreign DNS since they won't create
  EAMT entries but will be exposed to clients getting tricked into creating them.
  (This cCould be especially problematic for users using DoH for privacy
  on one device, but then another device in their home allows
  them to be hjijacked.  At some point Firefox preferred IPv4 in some
  cases when using DoH so this may be a real exposure
  / vulnerability risk.)

[Jordi] Not anymnore, because we don’t reuse EAMT entries from one host to another.

Sorry again for not sending these earlier --- I think a bunch of these
concerns were raised in my previous feedback and while this version
has made significant improvements, I'm still very concerned that it will
be very risky from an operational fragility and security perspective.

     Erik

[Jordi] Not at all, very happy for so much detailed review. Sometimes a last-call, even if failed, is good to get all this!

**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

---

From: Vasilenko Eduard <[email-masked]>
Date: Mon, 20 Jul 2020 08:15:41 +0000

Hi all,
Hi Jordi,

My comment about 8h TTL:
I insist to make it much longer. I have the theory below why it should be definitely more than 24h, probably even longer (1 week?).

I am a subscriber (at different times) of Megafon, MTS, and Tele2 Russia. Last one would drop any call after 30min, previous two would drop after 1h. Looks like they do not want stale connection too (especially paid).
It is very distracting when you are on conference call.

It is perfectly possible that we would see only one DNS request before media stream would start.
I could imagine interactive media stream longer than 8h. I could not imagine interactive longer then 24h – people need to sleep.

Whatever timer you would introduce – I am sure that would be cases when legitimate connection would be dropped. 24h would be probably safe time against interactive stream interruption.
But some video camera (surveillance) may be interrupted even after 1 week timer.
And if original application does not have a logic to reestablish connection (it is assumed manual or different application should push) – then any timer is a disaster.
Imagine a subscriber that needs to reestablish manually his video surveillance connection every week – what he would think about us?

We have trade off here: drop some legitimate long sessions or refresh timer after switching every packet against this EAM entry.
Who has experience with CPE development: is it really expensive for CPE to refresh TTL after any packet switched?
Then timer in 24h would be safe. (is we are sure that connection is really stale)

  for "www.example.com<http://www.example.com>" pointing to 192.0.2.1 cached past

[Eduard] I believe that this draft (that simulate normal hosts) could not resolve this problem in principle.
If somebody are capable to program 3rd party FQDN to fake AAAA record (of his), then the whole internet would be affected.
This fake record would be used by normal IPv6-only and Dual-Stack hosts.
It is definitely not a problem for this draft.
And DNS standards have a lot of tools against this.

Eduard
From: v6ops [mailto:[email-masked]] On Behalf Of JORDI PALET MARTINEZ
Sent: 20 июля 2020 г. 0:54
To: V6 Ops List <[email-masked]>
Subject: [v6ops] draft-ietf-v6ops-464xlat-optimization-02 - 5.2.6 and the rest

> "The existing EAMT entry for 192.0.2.1 is set as invalid".

Clarify that:
* 5. Existing connections to 192.0.2..1 remapped to 2001:db8::a:b:c:d
  MUST NOT be broken.
[Jordi] Yes, this has been solved with the stale status :
5.  The existing EAMT entry for 192.0.2.1 is set to Stale
And

   implementation.

=======

==========

================

   situation).

   Section 5.2.5.

============
General for 5.2.x:

==========

  for "www.example.com<http://www.example.com>" pointing to 192.0.2.1 cached past

     Erik

---

From: Jen Linkova <[email-masked]>
Date: Mon, 20 Jul 2020 20:32:14 +1000

On Mon, Jul 20, 2020 at 7:54 AM JORDI PALET MARTINEZ
<jordi.palet=[email-masked]> wrote:
> [Jordi] If the troubleshooting is done with dual-stack host, no issues. If it is an IPv4-only host, the optimization can be fully disabled, or specific entries can be disabled. Is not that solving the problem?

To disable the optimisation you need to know it exists, right? If the
optimisation is enabled by default the operator might not be even
aware of it, especially if the CPE is not provided by the ISP.
In addition to that the issue might be rather intermittent and happen
for some IPv4 addresses only. It's not like 'nothing works', it would
be more like 'sometime my TV can not run this app or that app just
stops working until I reboot it'.

If we assume that the operator has an ability to turn the optimisation
on/off it would be much safer to keep it turned off (shall I worry
about this next time I buy a new CPE?) and let the operator make the
decision, as before this feature can be useful the operator needs to:
- educate the support team;
- test the feature on the CPEs they provide
- update the recommended feature lists for 'bring your own CPE'
etc.
And then the operator can go and enable this feature.
If we assume they do not have control to enable it how can we assume
they would be able to disable it for troubleshooting?

> [Jordi] I think that having a per-host EAMT entries resolves this.

I believe that per-host EAMT entries do reduce the impact by limiting
it to a single host. However for that host the attack is rather easy
to execute still.

-- 
SY, Jen Linkova aka Furry

---

From: Jen Linkova <[email-masked]>
Date: Mon, 20 Jul 2020 20:43:53 +1000

> If somebody are capable to program 3rd party FQDN to fake AAAA record (of his), then the whole internet would be affected.

The attack does not require to fake AAAA RR for someone's else FQDN.
The attacker owns the FQDN and can put whatever they want there,
including the victim server IPv4 address.
Let's say I own furry.example.com. I tricked your IPv4-only TV to ask
for A RR for that name. I returned you an IPv4 address of
www.youtube.com as A and - when the smart CPE asks for AAAA, IPv6
address of my own server. Now your smart TV would be sending traffic
to my server instead of Youtube.
I totally agree that binding the EAMT entry to the source IPv4 address
limits the impact for a single device and makes the attack harder to
implement (you need to trick the
same device into resolving my evil FQDN, which is not as easy as
tricking my laptop into it).

> And DNS standards have a lot of tools against this.

I'm not sure there is anything in DNS preventing me from putting the
IPv4 address of www.huawei.com into the zone file for a domain name I
own.

---

From: Philip Homburg <[email-masked]>
Date: Mon, 20 Jul 2020 13:03:40 +0200

>to my server instead of Youtube.

I don't see how that attack would work.

Suppose the IPv4 address for youtube is 192.0.2.1. Now an attacker returns
this address for furry.example.com along with 2001:DB8::1.

Later the host tries to connect to youtube. Again the A query returns 
192.0.2.1. Now the CPE detects that it has two domain names for this IPv4
address and removes the EAMT entry.

Obviously, this would go wrong if youtube would use address literals instead
of domain names.

---

From: Vasilenko Eduard <[email-masked]>
Date: Mon, 20 Jul 2020 11:38:49 +0000

I do agree to Jen that any transition to "extended CLAT" should have rollback possibility. XLAT by itself has such capability.
If everything is hard-coded into CPE - then how to do it? We need to push somehow the single bit: "Yes/No".

Let's look how XLAT activated:
RFC 8585 (CPE) is telling to us (3.2.1.  464XLAT): 
464XLAT-4:  The IPv6 Transition CE Router MUST implement [RFC7050] ("Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis") in order to discover the provider-side translator (PLAT) translation IPv4 and IPv6 prefix(es)/suffix(es).
464XLAT-6:  If the network provides several choices for the discovery/learning of the NAT64 prefix, the priority to use one or the other MUST follow this order: 1) [RFC7225] and 2) [RFC7050].
XLAT RFC 6877: " Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis" (it is RFC 7050)
i.e. everything is referring to some other RFCs.

I propose to do the same for CLAT-NG in this draft (as it was for CLAT 1.0): activation should be discussed in different place, NG functionality of CLAT should be disabled by default, if CLAT would receive just NSP/WKP - it is not the reason yet to create EAMT.

Ed/
-----Original Message-----
From: v6ops [mailto:[email-masked]] On Behalf Of Jen Linkova
Sent: 20 июля 2020 г. 13:32
To: JORDI PALET MARTINEZ <jordi.palet=[email-masked]>
Cc: V6 Ops List <[email-masked]>
Subject: Re: [v6ops] draft-ietf-v6ops-464xlat-optimization-02 - 5.2.6 and the rest

On Mon, Jul 20, 2020 at 7:54 AM JORDI PALET MARTINEZ <jordi.palet=[email-masked]> wrote:
>> How do corner-cases around collisions where EAMT entries don't get 
>> proprerly invalidated get debugged by the ISP (and content 
>> provider!)?
>

To disable the optimisation you need to know it exists, right? If the optimisation is enabled by default the operator might not be even aware of it, especially if the CPE is not provided by the ISP.
In addition to that the issue might be rather intermittent and happen for some IPv4 addresses only. It's not like 'nothing works', it would be more like 'sometime my TV can not run this app or that app just stops working until I reboot it'.

If we assume that the operator has an ability to turn the optimisation on/off it would be much safer to keep it turned off (shall I worry about this next time I buy a new CPE?) and let the operator make the decision, as before this feature can be useful the operator needs to:
- educate the support team;
- test the feature on the CPEs they provide
- update the recommended feature lists for 'bring your own CPE'
etc.
And then the operator can go and enable this feature.
If we assume they do not have control to enable it how can we assume they would be able to disable it for troubleshooting?

>>   of their choice.  No DNS spoofing is needed here at all, just 
>> making  a "claim" that the A/AAAA are associated (which has no authentication).

I believe that per-host EAMT entries do reduce the impact by limiting it to a single host. However for that host the attack is rather easy to execute still.

_______________________________________________
v6ops mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v6ops

---

From: Vasilenko Eduard <[email-masked]>
Date: Mon, 20 Jul 2020 12:13:07 +0000

Hi Jen,

How smartTV would start to ask furry.example.com in 1st place?
It could ask netflix.com and some other limited number of FQDN. Do you believe anybody from these respected companies would be doing what you have described below?
If user is going somewhere (FQDN) - it is already some level of trust, because even 1st web page could have many security problems.

By the way, before successfully redirecting IPv6 traffic to itself (by below presented methodology),
Such web site (furry.example.com) would already redirect many normal IPv4 users to Youtube. People would start to complain - somebody could notice.
And the evidence would stick in cache on many DNS servers. It is very traceable to attacker.

What could be the reason to ask anything on FQDN furry.example.com, if one would never see this website (youtube would be substituted).
But if attacker would manage to put this bookmark in users favorites ...

I do not have strict opinion what to do about it.
It is definitely new attack vector introduce by this draft, but not very dangerous ...
Anyway, but IETF rules - it should be at least documented in mandatory Security section. Many people should decide.

Eduard
-----Original Message-----
From: Jen Linkova [mailto:[email-masked]] 
Sent: 20 июля 2020 г. 13:44
To: Vasilenko Eduard <[email-masked]>
Cc: JORDI PALET MARTINEZ <jordi.palet=[email-masked]>; V6 Ops List <[email-masked]>
Subject: Re: [v6ops] draft-ietf-v6ops-464xlat-optimization-02 - 5.2.6 and the rest

The attack does not require to fake AAAA RR for someone's else FQDN.
The attacker owns the FQDN and can put whatever they want there, including the victim server IPv4 address.
Let's say I own furry.example.com. I tricked your IPv4-only TV to ask for A RR for that name. I returned you an IPv4 address of www.youtube.com as A and - when the smart CPE asks for AAAA, IPv6 address of my own server. Now your smart TV would be sending traffic to my server instead of Youtube.
I totally agree that binding the EAMT entry to the source IPv4 address limits the impact for a single device and makes the attack harder to implement (you need to trick the same device into resolving my evil FQDN, which is not as easy as tricking my laptop into it).

I'm not sure there is anything in DNS preventing me from putting the
IPv4 address of www.huawei.com into the zone file for a domain name I own.

---

From: Jen Linkova <[email-masked]>
Date: Mon, 20 Jul 2020 23:41:09 +1000

> If user is going somewhere (FQDN) - it is already some level of trust, because even 1st web page could have many security problems.

Smart TVs do have browsers. I use the browser on my TV to watch online
translations. Maybe I shouldn't.
Browsers are used to open web-pages. Webpages could contain links and ads..

> Such web site (furry.example.com) would already redirect many normal IPv4 users to Youtube. People would start to complain - somebody could notice.

Except I do not need them to *open* the webpage. I only need them to
resolve the name in the URL.
Think about smth like Ads-based measurements Geoff Huston runs at APNIC.
Or a browser with speculative pre-connections enabled.

> And the evidence would stick in cache on many DNS servers. It is very traceable to attacker.

I really doubt anyone would trace it. The ISP support would probably
ask the user to 'reboot the CPE' first.

> What could be the reason to ask anything on FQDN furry.example.com, if one would never see this website (youtube would be substituted).

For the same reason my laptop's just asked 'what's the A RR for
0du-results-u52855d7e-c13-a9533-s1595251604-i74ff1172-0.ap.dotnxdomain.net.'

> Anyway, but IETF rules - it should be at least documented in mandatory Security section. Many people should decide.

Yes, that's the point: this needs to be discussed in the Security
Considerations and I'm not convinced that per-host EAMT mitigates the
issue completely.

---

From: Vasilenko Eduard <[email-masked]>
Date: Mon, 20 Jul 2020 15:27:00 +0000

Hi Jen,

Thanks that you have pushed this attack vector so far.

I believe that I have possibility now to explain that it is not relevant.

Not because it is wrong. But because current solution would not live to the point to test this vulnerability. It has much bigger functional problem that would prevent it to survive.

Let's look to use case when one private IPv4 host would contact same small hosting where many FQDNs are attached to single IPv4, but different IPv6 – and it is normal/permanent situation for this hosting provider. It is corner case, but not extremely unusual.

Then 2 EAM records should be created:

<Private IPv4 (source client), FQDN1, IPv4 (destination server), IPv6_a (destination server)>

<Private IPv4 (the same source client), FQDN2, IPv4 (the same destination server), IPv6_b (different destination server)>

It is fine for DNS process, but look to the problem for PFE now: PFE would receive IP packet with <Private IPv4 (source client), IPv4 (destination server)>.

What EAM record should be used for forwarding?!? Especially if it is 1st packet for the new flow - even full per-flow stateful machine would not help here.

Hence, I have to state again (previous time I did it for Philip's challenge of partially migrated IPv6 host):

we have to keep states for collisions of <Private IPv4 (source client), IPv4 (destination server)> pairs with flag "Disabled" forever. This traffic should go to PLAT.

But in this case with much bigger consequences: we should drop user session that was supposed to flow against 1st EAM record (it was unique before collision). Because we could not be sure anymore that we would switch traffic to proper destination.

After CPE reload we would probably drop user session again – CPE needs to learn disabled combinations by DNS requests. If User has contacted this combination of FQDNs one time – high probability that he would do it again.

It is again "we would keep states for not to use it". I believe it would be not too many states in normal situation, but attacker could organize DDoS for Carrier CPEs. EAMT table should be limited and after the limit - traffic should go only to PLAT. Vendors should decide by themselves how many EAMT entries they agree to support – it would be dependent on memory and CPU.

Jin, if you would substitute FQDN1 by "furry.example.com" and FQDN2 by "youtube.com" - you would get exactly your security concern. Just created intentionally – I have presented above natural case.

I need to tell that for security problem to happen it was mandatory that second resolution (youtube.com) should be 1st, then furry.example.com for hijack,

Because in opposite order proper FQDN just override fake one – it was the previous (wrong) assumption how it should operate.

But it would not happen anyway, because PFE would not be capable to sort out such collision in principle. Override is not an option here.

Eduard

-----Original Message-----
From: Jen Linkova [mailto:[email-masked]]
Sent: 20 июля 2020 г. 16:41
To: Vasilenko Eduard <[email-masked]>
Cc: JORDI PALET MARTINEZ <jordi.palet=[email-masked]>; V6 Ops List <[email-masked]>
Subject: Re: [v6ops] draft-ietf-v6ops-464xlat-optimization-02 - 5.2.6 and the rest

> If user is going somewhere (FQDN) - it is already some level of trust, because even 1st web page could have many security problems.

Smart TVs do have browsers. I use the browser on my TV to watch online translations. Maybe I shouldn't.

> By the way, before successfully redirecting IPv6 traffic to itself (by

> below presented methodology), Such web site (furry.example.com) would already redirect many normal IPv4 users to Youtube. People would start to complain - somebody could notice.

Except I do not need them to *open* the webpage. I only need them to resolve the name in the URL.

> And the evidence would stick in cache on many DNS servers. It is very traceable to attacker.

I really doubt anyone would trace it. The ISP support would probably ask the user to 'reboot the CPE' first.

> What could be the reason to ask anything on FQDN furry.example.com, if one would never see this website (youtube would be substituted).

For the same reason my laptop's just asked 'what's the A RR for 0du-results-u52855d7e-c13-a9533-s1595251604-i74ff1172-0.ap.dotnxdomain.net.'

> Anyway, but IETF rules - it should be at least documented in mandatory Security section. Many people should decide.

Yes, that's the point: this needs to be discussed in the Security Considerations and I'm not convinced that per-host EAMT mitigates the issue completely.

> To: Vasilenko Eduard <[email-masked]<mailto:[email-masked]>>

> Cc: JORDI PALET MARTINEZ

> <jordi.palet=[email-masked]<mailto:jordi.palet=[email-masked]>>; V6 Ops List

> <[email-masked]<mailto:[email-masked]>>

> Subject: Re: [v6ops] draft-ietf-v6ops-464xlat-optimization-02 - 5.2.6

> and the rest

> On Mon, Jul 20, 2020 at 6:16 PM Vasilenko Eduard <[email-masked]<mailto:[email-masked]>> wrote:

> >>   that has an A record of 192.0.2..1 (which the attacker doesn't

> >> own) but a AAAA record for 2001:db8:eeee::eeee (which is attacker-controlled).

> Let's say I own furry.example.com. I tricked your IPv4-only TV to ask for A RR for that name. I returned you an IPv4 address of www.youtube.com<http://www.youtube.com> as A and - when the smart CPE asks for AAAA, IPv6 address of my own server. Now your smart TV would be sending traffic to my server instead of Youtube.

> IPv4 address of www.huawei.com<http://www.huawei.com> into the zone file for a domain name I own.

--

---

From: Philip Homburg <[email-masked]>
Date: Mon, 20 Jul 2020 18:18:27 +0200

>    Hence, I have to state again (previous time I did it for Philip's
>    challenge of partially migrated IPv6 host):
> 
>    we have to keep states for collisions of <Private IPv4 (source
>    client), IPv4 (destination server)> pairs with flag "Disabled"
>    forever. This traffic should go to PLAT.
> 
>    But in this case with much bigger consequences: we should drop
>    user session that was supposed to flow against 1st EAM record
>    (it was unique before collision). Because we could not be sure
>    anymore that we would switch traffic to proper destination.

I can see a problem here. If a host as a long term connection to
a.example.com, and then after a while connects to b.example.com which has
the same IPv4 address as a.example.com, but a different IPv6 address,
then there doesn't seem to be any alternative but to drop the connection to
a.example.com

---

From: Jen Linkova <[email-masked]>
Date: Tue, 21 Jul 2020 08:34:05 +1000

I believe we are now saying the same thing more or less. The proposed
mechanism seems to have an issue if the same IPv4 address can be
mapped to multiple IPv6 addresses. It could be either a legitimate
case or an attack  - there is no way to tell actually, but it does not
matter.

---

From: Vasilenko Eduard <[email-masked]>
Date: Tue, 21 Jul 2020 11:12:37 +0000

Hi all,
Potentially, it is possible to keep states for TCP/UDP ports too, then current sessions could be finished. Only new 5-tuples would be forwarded to PLAT.
But it is so much a complexity! Really stateful up to every flow.

How much is the probability to see this problem in the real life? I believe that probability is low. Because big OTTs would not share many FQDNs on one IPv4 address.
Even less probability that they would do both: share IPv4 and use many IPv6s for these FQDNs.
Whatever strategy OTTs would choose for one FQDN does not matter - it could be any relationship between <any number of IPv4>:<any number of IPv6> - we would fetch only 1 choice from all possible combinations for one particular DNS resolution.

Hence, I propose to drop. It should be documented in the draft.

Eduard
-----Original Message-----
From: v6ops [mailto:[email-masked]] On Behalf Of Jen Linkova
Sent: 21 июля 2020 г. 1:34
To: Philip Homburg <[email-masked]>
Cc: V6 Ops List <[email-masked]>
Subject: Re: [v6ops] draft-ietf-v6ops-464xlat-optimization-02 - 5.2.6 and the rest

I believe we are now saying the same thing more or less. The proposed mechanism seems to have an issue if the same IPv4 address can be mapped to multiple IPv6 addresses. It could be either a legitimate case or an attack  - there is no way to tell actually, but it does not matter.

On Tue, Jul 21, 2020 at 2:19 AM Philip Homburg <[email-masked]> wrote:
> a.example.com, and then after a while connects to b.example.com which 
> has the same IPv4 address as a.example.com, but a different IPv6 
> address, then there doesn't seem to be any alternative but to drop the 
> connection to a.example.com
>
>

---

From: Philip Homburg <[email-masked]>
Date: Tue, 21 Jul 2020 15:14:38 +0200

> Hi all, Potentially, it
> is possible to keep states for TCP/UDP ports too, then current
> sessions could be finished. Only new 5-tuples would be forwarded
> to PLAT.  But it is so much a complexity! Really stateful up to
> every flow.

That solves this issue. EAMT can be use to establish forwarding/translation
state, so deleting an EAMT would not affect existing flows.

I think it is better to first document a working solution and then abandon 
it if it proves to be too complex or fragile.