Discussion:
[dhcwg] Considering AD sponsoring draft-bi-savi-wlan-15
Suresh Krishnan
2018-10-18 22:37:58 UTC
Permalink
Hi all,
I am considering AD sponsoring the following draft

https://tools.ietf.org/html/draft-bi-savi-wlan-15

that describes a source address validation solution for WLAN. If you have any concerns
either with the content of the draft, or about me AD sponsoring it please let me know before 2018/11/18.

Thanks
Suresh

NOTE: I have CCed: all the working groups that I thought could be potentially
interested in this work. If you think I have missed out some WG(s) please let
me know.
Lorenzo Colitti
2018-10-19 00:06:50 UTC
Permalink
Post by Suresh Krishnan
I am considering AD sponsoring the following draft
https://tools.ietf.org/html/draft-bi-savi-wlan-15
that describes a source address validation solution for WLAN. If you have any concerns
either with the content of the draft, or about me AD sponsoring it please
let me know before 2018/11/18.
I skimmed the draft. It looks well-written, and it addresses an important
problem which I think is probably solved in (different?) proprietary ways
on various implementations in the field today. I'm not very familiar with
the AD sponsorship process, so not sure what the has to happen from a
process perspective. But I think the document requires further review,
especially given that it's making statements about very widely-deployed
scenarios (IPv6 over wifi). Should the document be adopted by a WG such as
6man or v6ops? If not, it should definitely be reviewed by those WGs.

As a concrete example, here are some things that need to be resolved before
the document advances:

1. The proposed scheme relies on DAD packets to create mapping entries.
That means that if a DAD packet is lost (which can happen even though
802.11 employs retransmissions at L2), a station could have an IPv6 address
that doesn't work with no indication that it's not working. This is
basically a non-recoverable outage. Perhaps the document should specify
another solution instead, e.g., it could say that mapping entries could be
created when a wired station receives a solicited NA response from a
wireless station.
2. The document says that the lifetime of SLAAC addresses is the address
lifetime, but the network has no way of knowing what the address lifetime
is because it depends on which RA(s) the host has received.


Cheers,
Lorenzo
Pascal Thubert (pthubert)
2018-10-19 14:44:11 UTC
Permalink
Dear all :

I agree with Lorenzo, this scheme is at a high level what we can find in commercial products, and I have first-hand experience on that.

As an informational document, this RFC could be a useful reference to consider if we were to change the protocols in a way that would impact those existing and non-standard snooping behaviors.
Snooping has proven to be very useful, but as one may guess, it is not reliable; it may miss packets, may fail to create bindings, may point on an incorrect location as well.

So I’d say that if we publish as RFC, we should also indicate that with draft-ietf-6lo-ap-nd, we (will) have a more robust solution for devices that are willing to announce themselves.

Cheers,

Pascal
From: ipv6 <ipv6-***@ietf.org> On Behalf Of Lorenzo Colitti
Sent: vendredi 19 octobre 2018 02:07
To: Suresh Krishnan <***@kaloom.com>
Cc: ***@ietf.org WG <***@ietf.org>; IETF IPv6 Mailing List <***@ietf.org>; ***@ietf.org; ***@ietf.org; int-***@ietf.org; ***@ietf.org
Subject: Re: [dhcwg] Considering AD sponsoring draft-bi-savi-wlan-15

On Fri, Oct 19, 2018 at 7:38 AM Suresh Krishnan <***@kaloom.com<mailto:***@kaloom.com>> wrote:
I am considering AD sponsoring the following draft

https://tools.ietf.org/html/draft-bi-savi-wlan-15

that describes a source address validation solution for WLAN. If you have any concerns
either with the content of the draft, or about me AD sponsoring it please let me know before 2018/11/18.

I skimmed the draft. It looks well-written, and it addresses an important problem which I think is probably solved in (different?) proprietary ways on various implementations in the field today. I'm not very familiar with the AD sponsorship process, so not sure what the has to happen from a process perspective. But I think the document requires further review, especially given that it's making statements about very widely-deployed scenarios (IPv6 over wifi). Should the document be adopted by a WG such as 6man or v6ops? If not, it should definitely be reviewed by those WGs.

As a concrete example, here are some things that need to be resolved before the document advances:

1. The proposed scheme relies on DAD packets to create mapping entries. That means that if a DAD packet is lost (which can happen even though 802.11 employs retransmissions at L2), a station could have an IPv6 address that doesn't work with no indication that it's not working. This is basically a non-recoverable outage. Perhaps the document should specify another solution instead, e.g., it could say that mapping entries could be created when a wired station receives a solicited NA response from a wireless station.
2. The document says that the lifetime of SLAAC addresses is the address lifetime, but the network has no way of knowing what the address lifetime is because it depends on which RA(s) the host has received.

Cheers,
Lorenzo
Suresh Krishnan
2018-10-23 02:29:04 UTC
Permalink
Thanks Lorenzo, Pascal and Bernard for your comments. I have asked the authors to respond to your comments on the intarea mailing list. Also, Bernard suggested a 802.11 review of this draft, and I intend to pursue that as well if the draft progresses. I could not find a WG that would be a exact fit for this work, and that is why I decided to cast the net wide for potentially relevant WGs in the hope of getting reviews. I will be extremely happy if this can be hosted in a WG instead and get sufficient review there.

Regards
Suresh

On Oct 19, 2018, at 10:44 AM, Pascal Thubert (pthubert) <***@cisco.com<mailto:***@cisco.com>> wrote:

Dear all :

I agree with Lorenzo, this scheme is at a high level what we can find in commercial products, and I have first-hand experience on that.

As an informational document, this RFC could be a useful reference to consider if we were to change the protocols in a way that would impact those existing and non-standard snooping behaviors.
Snooping has proven to be very useful, but as one may guess, it is not reliable; it may miss packets, may fail to create bindings, may point on an incorrect location as well.

So I’d say that if we publish as RFC, we should also indicate that with draft-ietf-6lo-ap-nd, we (will) have a more robust solution for devices that are willing to announce themselves.

Cheers,

Pascal
From: ipv6 <ipv6-***@ietf.org<mailto:ipv6-***@ietf.org>> On Behalf Of Lorenzo Colitti
Sent: vendredi 19 octobre 2018 02:07
To: Suresh Krishnan <***@kaloom.com<mailto:***@kaloom.com>>
Cc: ***@ietf.org<mailto:***@ietf.org> WG <***@ietf.org<mailto:***@ietf.org>>; IETF IPv6 Mailing List <***@ietf.org<mailto:***@ietf.org>>; ***@ietf.org<mailto:***@ietf.org>; ***@ietf.org<mailto:***@ietf.org>; int-***@ietf.org<mailto:int-***@ietf.org>; ***@ietf.org<mailto:***@ietf.org>
Subject: Re: [dhcwg] Considering AD sponsoring draft-bi-savi-wlan-15

On Fri, Oct 19, 2018 at 7:38 AM Suresh Krishnan <***@kaloom.com<mailto:***@kaloom.com>> wrote:
I am considering AD sponsoring the following draft

https://tools.ietf.org/html/draft-bi-savi-wlan-15

that describes a source address validation solution for WLAN. If you have any concerns
either with the content of the draft, or about me AD sponsoring it please let me know before 2018/11/18.

I skimmed the draft. It looks well-written, and it addresses an important problem which I think is probably solved in (different?) proprietary ways on various implementations in the field today. I'm not very familiar with the AD sponsorship process, so not sure what the has to happen from a process perspective. But I think the document requires further review, especially given that it's making statements about very widely-deployed scenarios (IPv6 over wifi). Should the document be adopted by a WG such as 6man or v6ops? If not, it should definitely be reviewed by those WGs.

As a concrete example, here are some things that need to be resolved before the document advances:

1. The proposed scheme relies on DAD packets to create mapping entries. That means that if a DAD packet is lost (which can happen even though 802.11 employs retransmissions at L2), a station could have an IPv6 address that doesn't work with no indication that it's not working. This is basically a non-recoverable outage. Perhaps the document should specify another solution instead, e.g., it could say that mapping entries could be created when a wired station receives a solicited NA response from a wireless station.
2. The document says that the lifetime of SLAAC addresses is the address lifetime, but the network has no way of knowing what the address lifetime is because it depends on which RA(s) the host has received.


Cheers,
Lorenzo
Lorenzo Colitti
2018-10-23 04:05:30 UTC
Permalink
Isn't v6ops a natural fit for this, since it essentially documents an
operational practice that is implemented by real hardware?
Post by Suresh Krishnan
Thanks Lorenzo, Pascal and Bernard for your comments. I have asked the
authors to respond to your comments on the intarea mailing list. Also,
Bernard suggested a 802.11 review of this draft, and I intend to pursue
that as well if the draft progresses. I could not find a WG that would be a
exact fit for this work, and that is why I decided to cast the net wide for
potentially relevant WGs in the hope of getting reviews. I will be
extremely happy if this can be hosted in a WG instead and get sufficient
review there.
Regards
Suresh
On Oct 19, 2018, at 10:44 AM, Pascal Thubert (pthubert) <
I agree with Lorenzo, this scheme is at a high level what we can find in
commercial products, and I have first-hand experience on that.
As an informational document, this RFC could be a useful reference to
consider if we were to change the protocols in a way that would impact
those existing and non-standard snooping behaviors.
Snooping has proven to be very useful, but as one may guess, it is not
reliable; it may miss packets, may fail to create bindings, may point on an
incorrect location as well.
So I’d say that if we publish as RFC, we should also indicate that with
draft-ietf-6lo-ap-nd, we (will) have a more robust solution for devices
that are willing to announce themselves.
Cheers,
Pascal
*Sent:* vendredi 19 octobre 2018 02:07
*Subject:* Re: [dhcwg] Considering AD sponsoring draft-bi-savi-wlan-15
I am considering AD sponsoring the following draft
https://tools.ietf.org/html/draft-bi-savi-wlan-15
that describes a source address validation solution for WLAN. If you have any concerns
either with the content of the draft, or about me AD sponsoring it please
let me know before 2018/11/18.
I skimmed the draft. It looks well-written, and it addresses an important
problem which I think is probably solved in (different?) proprietary ways
on various implementations in the field today. I'm not very familiar with
the AD sponsorship process, so not sure what the has to happen from a
process perspective. But I think the document requires further review,
especially given that it's making statements about very widely-deployed
scenarios (IPv6 over wifi). Should the document be adopted by a WG such as
6man or v6ops? If not, it should definitely be reviewed by those WGs.
As a concrete example, here are some things that need to be resolved
1. The proposed scheme relies on DAD packets to create mapping
entries. That means that if a DAD packet is lost (which can happen even
though 802.11 employs retransmissions at L2), a station could have an IPv6
address that doesn't work with no indication that it's not working. This is
basically a non-recoverable outage. Perhaps the document should specify
another solution instead, e.g., it could say that mapping entries could be
created when a wired station receives a solicited NA response from a
wireless station.
2. The document says that the lifetime of SLAAC addresses is the
address lifetime, but the network has no way of knowing what the address
lifetime is because it depends on which RA(s) the host has received.
Cheers,
Lorenzo
_______________________________________________
dhcwg mailing list
https://www.ietf.org/mailman/listinfo/dhcwg
Suresh Krishnan
2018-10-24 03:13:17 UTC
Permalink
Hi Lorenzo,
Isn't v6ops a natural fit for this, since it essentially documents an operational practice that is implemented by real hardware?
I did think of it, but the draft is also expected to work with IPv4 and that made me reconsider (In fact one of my solicited reviews for the previous version of this draft was from Fred Baker). Fred/Ron, do you think this draft can fit in v6ops? If so, I will send the authors your way.

Thanks
Suresh
Fred Baker
2018-10-24 12:25:09 UTC
Permalink
Well, it's not crazy to bring it to v6ops. I sent the authors to int-area IIRC, but we could look at it in the IETF 104 timeframe and in email in between time. It won't make the agenda for 103 - we're full up.
Post by Suresh Krishnan
I did think of it, but the draft is also expected to work with IPv4 and that made me reconsider (In fact one of my solicited reviews for the previous version of this draft was from Fred Baker). Fred/Ron, do you think this draft can fit in v6ops? If so, I will send the authors your way.
--------------------------------------------------------------------------------
The fact that there is a highway to hell and a stairway to heaven is an interesting comment on projected traffic volume...
Loading...