Subject: [v6ops] draft-ietf-v6ops-slaac-renum-04 - 802.1x relevance

From: Vasilenko Eduard <[email-masked]>
Date: Mon, 26 Oct 2020 10:03:26 +0000

Hi Fernando,
Sorry. I have spotted it just now.
It does not make sense to mention 802.1x as the reason for renumbering problem.
802.1x operates strictly on L2. Switch port is blocked for any other traffic at that time.
If authentication would fail then port could be put into "guest" VLAN.
But important point to mention that 802.1x supplicant has finished its job - it could not activate authentication again. It needs same event like link up/down or admin push. Enterprises do not manage clients in such a dynamic way.
The decision to move host from "guest" to some other VLAN is not related to 802.1x, not at all. It could be probably configuration push to switch (NetConf?).
If such bad practice would happen then it would break connectivity for IPv4 too - DHCP would not have any information that VLAN has been changes.
Hence, it does not matter what mechanism has been used initially to put host into "guest" VLAN. It could be something other than 802.1x.
It is important that some automation tool could break IP connectivity shifting hosts between VLANs.
It is not possible to develop the resolution on IPv4, but it is possible to invent additional protection on IPv6.
The reason is still valid - precautions make sense to have. But it has nothing to do with 802.1x. It is general VLAN shuffling.
Eduard
> -----Original Message-----
> From: v6ops [mailto:[email-masked]] On Behalf Of IETF Secretariat
> Sent: 22 октября 2020 г. 17:29
> To: [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]; Owen DeLong
> <[email-masked]>
> Subject: [v6ops] Datatracker State Update Notice: <draft-ietf-v6ops-slaac-
> renum-04.txt>
> 
> IESG state changed:
> 
> New State: IESG Evaluation::Revised I-D Needed
> 
> (The previous state was IESG Evaluation)
> 
> 
> Datatracker URL: https://datatracker.ietf.org/doc/draft-ietf-v6ops-slaac-
> renum/
> 
> 
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Richard Patterson <[email-masked]>
Date: Tue, 27 Oct 2020 12:48:27 +0000

Hi Eduard,

We're not pointing out any interoperation with 802.1x specifically, we were
just using it as an example that may trigger a renumbering event without
the physical port flapping, which I believe is valid.

A switch-port the host is connected to may be moved to another
      subnet (VLAN) as a result of manual switch-port reconfiguration or
      802.1x re-authentication.

I think the statement above is clear that 802.1x is simply an example of
when a host may be shifted between VLANs and a renumbering event may occur,
if you believe the wording isn't clear enough, would you be able to suggest
how we may improve it please?

-Rich

On Mon, 26 Oct 2020 at 10:04, Vasilenko Eduard <[email-masked]>
wrote:

> But important point to mention that 802.1x supplicant has finished its job
> - it could not activate authentication again. It needs same event like link
> up/down or admin push. Enterprises do not manage clients in such a dynamic
> way.
> The decision to move host from "guest" to some other VLAN is not related
> to 802.1x, not at all. It could be probably configuration push to switch
> (NetConf?).
> If such bad practice would happen then it would break connectivity for
> IPv4 too - DHCP would not have any information that VLAN has been changes.
> Hence, it does not matter what mechanism has been used initially to put
> host into "guest" VLAN. It could be something other than 802.1x.
> The reason is still valid - precautions make sense to have. But it has
> nothing to do with 802.1x. It is general VLAN shuffling.
> Eduard
> > Datatracker URL:
> https://datatracker.ietf.org/doc/draft-ietf-v6ops-slaac-
> > renum/
> >
> >

---

From: Vasilenko Eduard <[email-masked]>
Date: Tue, 27 Oct 2020 13:05:32 +0000

Hi Richard,
I believe that it is misleading.
Because 802.1x itself is not capable to move between VLANs after address accepted. 802.1x could move between VLANs before address accepted – it is not relevant here.
Something else should push between VLANs to break IP connectivity. It could not be 802.1x. It is better not to mention 802.1x. It is not important what was the mechanism that initially connected host to 1st VLAN.
It could be no any special mechanism at all. Or it could be “MAC-authentication”. It does not matter.

It is important what could be the mechanism that moved between VLANs. I do assume some sort of configuration change by CLI of Netconf.
But it is not 802.1x anyway.
Eduard
From: Richard Patterson [mailto:[email-masked]]
Sent: 27 октября 2020 г. 15:48
To: Vasilenko Eduard <[email-masked]>
Cc: IPv6 Operations <[email-masked]>
Subject: Re: [v6ops] draft-ietf-v6ops-slaac-renum-04 - 802.1x relevance

Hi Eduard,

We're not pointing out any interoperation with 802.1x specifically, we were just using it as an example that may trigger a renumbering event without the physical port flapping, which I believe is valid.

I think the statement above is clear that 802.1x is simply an example of when a host may be shifted between VLANs and a renumbering event may occur, if you believe the wording isn't clear enough, would you be able to suggest how we may improve it please?

-Rich

On Mon, 26 Oct 2020 at 10:04, Vasilenko Eduard <[email-masked]<mailto:[email-masked]>> wrote:
Hi Fernando,
> From: v6ops [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of IETF Secretariat
> To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>;
> [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Owen DeLong
> <[email-masked]<mailto:[email-masked]>>
> [email-masked]<mailto:[email-masked]>

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

---

From: Richard Patterson <[email-masked]>
Date: Tue, 27 Oct 2020 14:08:12 +0000

So do you believe the rest of the paragraph that provides the example, is
wrong?

In particular, there has been evidence
      that some 802.1x supplicants do not reset network settings after
      successful 802.1x authentication.  So if a host had failed 802.1x
      authentication for some reason, was placed in a "quarantine" VLAN
      and then got successfully authenticated later on, it might end up
      having IPv6 addresses from both old ("quarantine") and new VLANs.

On Tue, 27 Oct 2020 at 13:05, Vasilenko Eduard <[email-masked]>
wrote:

> Because 802.1x itself is not capable to move between VLANs after address
> accepted. 802.1x could move between VLANs before address accepted – it is
> not relevant here.
>
> Something else should push between VLANs to break IP connectivity. It
> could not be 802.1x. It is better not to mention 802.1x. It is not
> important what was the mechanism that initially connected host to 1st
> VLAN.
>
> It could be no any special mechanism at all. Or it could be
> “MAC-authentication”. It does not matter.
>
>
>
> It is important what could be the mechanism that moved between VLANs. I do
> assume some sort of configuration change by CLI of Netconf.
>
> *From:* Richard Patterson [mailto:[email-masked]]
> *Sent:* 27 октября 2020 г. 15:48
> *To:* Vasilenko Eduard <[email-masked]>
> *Cc:* IPv6 Operations <[email-masked]>
> *Subject:* Re: [v6ops] draft-ietf-v6ops-slaac-renum-04 - 802.1x relevance
>
>
>
> Hi Eduard,
>
>
>
> We're not pointing out any interoperation with 802.1x specifically, we
> were just using it as an example that may trigger a renumbering event
> without the physical port flapping, which I believe is valid.
>
>
>
> On Mon, 26 Oct 2020 at 10:04, Vasilenko Eduard <
> [email-masked]> wrote:
>
> Hi Fernando,

---

From: Ted Lemon <[email-masked]>
Date: Tue, 27 Oct 2020 10:28:07 -0400

On Oct 27, 2020, at 09:06, Vasilenko Eduard <[email-masked]> wrote:
> Because 802.1x itself is not capable to move between VLANs after address accepted.

802.1x is individually implemented on a variety of different operating systems. A categorical statement like this doesn’t make sense. On which operating systems do you know your statement to be true? You haven’t said. 

Also, 802.1x is a layer 2 protocol and knows nothing of layer three unless the attack on a particular device OSS programmed with a heuristic for how to behave once layer 3 is up. 

Can you explain why you are so certain you are right about this rather than restating  it as fact with no justification?

---

From: Vasilenko Eduard <[email-masked]>
Date: Tue, 27 Oct 2020 17:14:16 +0000

Hi Ted,
I have investigated 3 vendors. 802.1x is to finish the patchcord connection on L2. L3 could happen only after this. If any vendor would implement it differently - it would be interesting to hear.
But why we have reverted this question? I believe that proves should be from the one who has put 802.1x as the reason into the document.
It was not me.
Eduard
> From: Ted Lemon [mailto:[email-masked]]
> Sent: 27 октября 2020 г. 17:28
> Cc: Richard Patterson <[email-masked]>; IPv6 Operations
> <[email-masked]>
> accepted.
> 802.1x is individually implemented on a variety of different operating systems. A
> categorical statement like this doesn’t make sense. On which operating systems
> do you know your statement to be true? You haven’t said.
> 
> Also, 802.1x is a layer 2 protocol and knows nothing of layer three unless the
> attack on a particular device OSS programmed with a heuristic for how to
> behave once layer 3 is up.
> 
> Can you explain why you are so certain you are right about this rather than
> restating  it as fact with no justification?

---

From: Ted Lemon <[email-masked]>
Date: Tue, 27 Oct 2020 13:23:05 -0400

> But why we have reverted this question? I believe that proves should be from the one who has put 802.1x as the reason into the document.

The problem with your theory is that you haven’t actually understood the point you are contradicting.  The situation that was described is as follows:

1. host attempts to connect to 802.1x, is unable to authenticate, is connected to quarantine vlan
2. host acquires l3 info for quarantine vlan
3. user acquires authentication information for 802.1x through the quarantine process
4. user authenticates to 802.1x
5. host is now connected to internal vlan, and is no longer connected to quarantine vlan
6. host layer 3 does not see a link state transition, and does not invalidate state acquired on quarantine vlan
7. communication is unreliable because quarantine vlan addresses are not valid, but are considered valid candidates for use.

Does this make the situation clearer?

---

From: Vasilenko Eduard <[email-masked]>
Date: Tue, 27 Oct 2020 17:29:40 +0000

Yes.
This “and then got successfully authenticated later on” mislead that it is somehow related to the previous sentence about 802.1x.
It is not.
It could happen by other mechanism, not by 802.1x.

In general, it does not make sense to mention 802.1x in this document, because it is not related.
It is better to replace it by:

“The host could be connected initially to VLAN with IPv6 prefix, then later host may be moved to another VLAN with different IPv6 prefix (human mistake, bad system design, L2 topology change). It might end up having IPv6 addresses from both old and new VLANs. Sourcing traffic from the old prefix could lead to the traffic drop by RPF in upstream direction, downstream traffic may be not forwarded to proper link. ”

Eduard
Sent: 27 октября 2020 г. 17:08

So do you believe the rest of the paragraph that provides the example, is wrong?

On Tue, 27 Oct 2020 at 13:05, Vasilenko Eduard <[email-masked]<mailto:[email-masked]>> wrote:
Hi Richard,

It is important what could be the mechanism that moved between VLANs. I do assume some sort of configuration change by CLI of Netconf.
But it is not 802.1x anyway.
Eduard
From: Richard Patterson [mailto:[email-masked]<mailto:[email-masked]>]
Sent: 27 октября 2020 г. 15:48
To: Vasilenko Eduard <[email-masked]<mailto:[email-masked]>>
Cc: IPv6 Operations <[email-masked]<mailto:[email-masked]>>
Subject: Re: [v6ops] draft-ietf-v6ops-slaac-renum-04 - 802.1x relevance

Hi Eduard,

-Rich

---

From: Ted Lemon <[email-masked]>
Date: Tue, 27 Oct 2020 13:32:07 -0400

> It could happen by other mechanism, not by 802.1x.

Can you explain why you think it would not be possible to authenticate with 802.1x after registering in quarantine?

---

From: Vasilenko Eduard <[email-masked]>
Date: Tue, 27 Oct 2020 17:42:22 +0000

If host would receive proper credentials for 802.1x authentication,
Then change in 802.1x configuration would re-initialize the link at L2.
IP addresses would cleared automatically.

Do you have any name of the vendor (and product) that did it differently?

Ed/
From: Ted Lemon [mailto:[email-masked]]
Sent: 27 октября 2020 г. 20:23
To: Vasilenko Eduard <[email-masked]>
Cc: Richard Patterson <[email-masked]>; IPv6 Operations <[email-masked]>
Subject: Re: [v6ops] draft-ietf-v6ops-slaac-renum-04 - 802.1x relevance

On Oct 27, 2020, at 1:14 PM, Vasilenko Eduard <[email-masked]<mailto:[email-masked]>> wrote:
I have investigated 3 vendors. 802.1x is to finish the patchcord connection on L2. L3 could happen only after this. If any vendor would implement it differently - it would be interesting to hear.
But why we have reverted this question? I believe that proves should be from the one who has put 802.1x as the reason into the document.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 27 Oct 2020 13:49:08 -0400

> IP addresses would cleared automatically.

The example used in this case was for a host where the implementation does not “clear IP addresses automatically.” Do you know for a fact that there are no such operating systems? If so, can you explain how you know?

---

From: Ole Troan <[email-masked]>
Date: Tue, 27 Oct 2020 19:08:27 +0100

Ted,

I think you reverse the burden of proof here. 
Is the use case made up that the authenticator behaves this way? Based on buggy implementation or based on specification?

Ole

> On 27 Oct 2020, at 18:50, Ted Lemon <[email-masked]> wrote:
>

---

From: Ted Lemon <[email-masked]>
Date: Tue, 27 Oct 2020 14:11:54 -0400

> Is the use case made up that the authenticator behaves this way? Based on buggy implementation or based on specification?

I don’t know—I’m not the author of the document. I’m just seeing a lot of unsubstantiated assertions from Eduard, and would wish that if he’s going to make assertions that something is impossible, he tell us why we should believe his assertions. Otherwise it just seems argumentative.

---

From: Ole Troan <[email-masked]>
Date: Tue, 27 Oct 2020 20:02:58 +0100

The use of terms like “unsubstantiated assertions” isn’t so helpful for the discourse. The 802.1x specification is available  to you too.

Cheers 
Ole

> On 27 Oct 2020, at 19:12, Ted Lemon <[email-masked]> wrote:
>

---

From: Vasilenko Eduard <[email-masked]>
Date: Tue, 27 Oct 2020 19:19:59 +0000

Chapter 6.3.4 Interoperability and connectivity
Changes in the nature of the Controlled Port.’s connectivity (from one of unauthenticated, unsecured, or
secured, to another) and changes in secured connectivity (changes in the CA), are accompanied by
controlPortEnabled transitions, and are seen by clients of the Controlled Port as interruptions in
connectivity. These interruptions (signaled by changes in MAC_Operational for the port) should be used to
restart client protocol state machines that take exceptional or accelerated action when connectivity is first
available. For example, a network access point that provides unauthenticated connectivity to a host can
provide that host access to a different IP subnet once it has been authenticated, and it is appropriate to
reinitialize DHCP so the host can obtain a fresh IP address.

Hence, if any vendor would not “signaled by changes in MAC_Operational for the port” – it would be 802.1x-2010 violation.

Ed/
From: Ted Lemon [mailto:[email-masked]]
Sent: 27 октября 2020 г. 21:12
To: Ole Troan <[email-masked]>
Cc: Vasilenko Eduard <[email-masked]>; IPv6 Operations <[email-masked]>
Subject: Re: [v6ops] draft-ietf-v6ops-slaac-renum-04 - 802.1x relevance

On Oct 27, 2020, at 2:08 PM, Ole Troan <[email-masked]<mailto:[email-masked]>> wrote:
I think you reverse the burden of proof here.
Is the use case made up that the authenticator behaves this way? Based on buggy implementation or based on specification?

---

From: Ted Lemon <[email-masked]>
Date: Tue, 27 Oct 2020 15:29:17 -0400

> The use of terms like “unsubstantiated assertions” isn’t so helpful for the discourse. The 802.1x specification is available  to you too.

We haven’t all read every specification. If Eduard believes that the specification says that this is impossible, why can he not just say that, and point to where it says that? What is so hard about that?

This isn’t a game. Wasting each others’ time by making assertions that have to be laboriously checked by anyone following the conversation is extremely unhelpful. Clearly Eduard feels that it is important for Fernando not to say that 802.1x implements behave the way Fernando says they do. He wants that text removed. Is it not unreasonable for us to expect him to explain why in enough detail that we aren’t left to either take him at his word or go try to reconstruct his reasoning on our own?

---

From: Ted Lemon <[email-masked]>
Date: Tue, 27 Oct 2020 15:32:34 -0400

> Hence, if any vendor would not “signaled by changes in MAC_Operational for the port” – it would be 802.1x-2010 violation.

Thanks. I will note that you have not actually contradicted what Fernando said: that there are implementations that do not behave as the spec says they should.

---

From: Vasilenko Eduard <[email-masked]>
Date: Tue, 27 Oct 2020 19:35:22 +0000

Ted,
I did check it already – 802.1x specification clearly prohibits such behavior. See different message.

I have started this thread with:
Sorry. I have spotted it just now.

I do assume that Fernando has put this text for the reason.
I am just asking for this reason.
It is clearly now that specification prohibits this.
Then who was the vendor/product that violated 802.1x?
Just say the name…

Eduard
Sent: 27 октября 2020 г. 22:29

On Oct 27, 2020, at 3:02 PM, Ole Troan <[email-masked]<mailto:[email-masked]>> wrote:
The use of terms like “unsubstantiated assertions” isn’t so helpful for the discourse. The 802.1x specification is available  to you too.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 27 Oct 2020 15:46:36 -0400

> Then who was the vendor/product that violated 802.1x?

That’s a fair question, but e.g. if I were to say something like that, I would be prohibited by my employee agreement from saying who. As a general rule in the IETF we don’t call corporations out directly for mistakes like this because doing so puts our employers and the IETF at risk of lawsuit. I know this because I used to make demands of the sort you are making, and had it explained to me rather vigorously by a then-AD.

Another reason not to answer this in an RFC or on a public mailing list is that the vendor might fix their implementation, but the assertion would forever remain on the record, and might continue to be believed. So it’s not a good practice.

A better question for Fernando would be “do you know of specific current implementations which get this wrong?” Without asking him to say which specific implementations. If he says “no, I don’t know of any, I’m just theorizing,” then you are right to ask him to take out the text. If he says “yes,” then it would be more collegial to take him at his word then to insist that he take it out if he can’t make specific accusations. Why would someone lie about this?