Subject: [OPSEC] Considering AD sponsoring draft-bi-savi-wlan-15

From: Suresh Krishnan <[email-masked]>
Date: Thu, 18 Oct 2018 22:37:58 +0000

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.

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 19 Oct 2018 09:06:50 +0900

> 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

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 19 Oct 2018 14:44:11 +0000

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 <[email-masked]> On Behalf Of Lorenzo Colitti
Sent: vendredi 19 octobre 2018 02:07
To: Suresh Krishnan <[email-masked]>
Cc: [email-masked] WG <[email-masked]>; IETF IPv6 Mailing List <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [dhcwg] Considering AD sponsoring draft-bi-savi-wlan-15

On Fri, Oct 19, 2018 at 7:38 AM Suresh Krishnan <[email-masked]<mailto:[email-masked]>> wrote:
   I am considering AD sponsoring the following draft

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

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 19 Oct 2018 08:22:46 -0700

I took a look at the draft and found some fundamental problems.  I would
suggest review by IEEE 802.11 before proceeding.

A few of the issues are noted below.

   In WLAN, a number of security
   mechanisms on link layer make MAC address a strong enough binding
   anchor, for instance, 802.11i, WAPI, WEP.

[BA] WAPI and WEP are most certainly *not* "strong enough" for 802.11
security, let alone to be considered a "strong enough" binding
mechanism.

IEEE 802.11i has long ago been obsoleted by more recent IEEE 802.11
specifications, so I'd be concerned this is also not an appropriate
reference.

If MAC address has no protection, attackers can spoof MAC address to
succeed in validation.

[BA] While this statement is true, the inverse statement (that
spoofing is prevented by protection) is not true.

WLAN security does not prevent one authenticated station from spoofing
multicast packets from another authenticated station.

   An individual procedure handles binding DHCP addresses to MAC
   addresses.  This procedure snoops the DHCP address assignment
   procedure between attached hosts and DHCP server.  DHCP snooping in
   WLAN is the same as that in wired network specified in RFC7513
<https://tools.ietf.org/html/rfc7513>
   [RFC7513 <https://tools.ietf.org/html/rfc7513>].

   An individual procedure handles binding stateless addresses to MAC
   addresses.  This procedure snoops Duplicate Address Detection
   procedure.  ND snooping in WLAN is the same as that in wired network
   specified in [RFC6620 <https://tools.ietf.org/html/rfc6620>]
[RFC6620 <https://tools.ietf.org/html/rfc6620>].

[BA] These paragraphs do not mention ARP, so either the draft does not
apply to IPv4 at all, or it cannot handle IPv4 static addresses.

   2.  A host leaves this access point.  The entries for all related MAC
       addresses in MAC-IP table MUST be cleared.

[BA] This advice, if implemented would break basic WLAN roaming
functionality which allows a station to seamlessly move its point of
attachment.

On Thu, Oct 18, 2018 at 3:39 PM Suresh Krishnan <[email-masked]> wrote:

> _______________________________________________
> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area
>

---

From: Suresh Krishnan <[email-masked]>
Date: Tue, 23 Oct 2018 02:29:04 +0000

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) <[email-masked]<mailto:[email-masked]>> wrote:

Dear all :

Cheers,

Pascal
From: ipv6 <[email-masked]<mailto:[email-masked]>> On Behalf Of Lorenzo Colitti
Sent: vendredi 19 octobre 2018 02:07
To: Suresh Krishnan <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]> WG <[email-masked]<mailto:[email-masked]>>; IETF IPv6 Mailing List <[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]>
Subject: Re: [dhcwg] Considering AD sponsoring draft-bi-savi-wlan-15

Cheers,
Lorenzo

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 23 Oct 2018 13:05:30 +0900

Isn't v6ops a natural fit for this, since it essentially documents an
operational practice that is implemented by real hardware?

On Tue, Oct 23, 2018 at 11:29 AM Suresh Krishnan <[email-masked]> wrote:

> 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) <
> [email-masked]> 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 <[email-masked]> *On Behalf Of *Lorenzo Colitti
> *Sent:* vendredi 19 octobre 2018 02:07
> *To:* Suresh Krishnan <[email-masked]>
> *Cc:* [email-masked] WG <[email-masked]>; IETF IPv6 Mailing List <
> [email-masked]>; [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> *Subject:* Re: [dhcwg] Considering AD sponsoring draft-bi-savi-wlan-15
>
>    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
>    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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg
>

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 24 Oct 2018 03:13:17 +0000

Hi Lorenzo,

> On Oct 23, 2018, at 12:05 AM, Lorenzo Colitti <[email-masked]> wrote:
> 
> 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

---

From: Fred Baker <[email-masked]>
Date: Wed, 24 Oct 2018 14:25:09 +0200

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.

> On Oct 24, 2018, at 5:13 AM, Suresh Krishnan <[email-masked]> wrote:
> 

--------------------------------------------------------------------------------
The fact that there is a highway to hell and a stairway to heaven is an interesting comment on projected traffic volume...