[Ace] Re: Iotdir telechat review of draft-ietf-ace-wg-coap-eap-11

Dan Garcia Carrillo <garciadan@uniovi.es> Tue, 12 November 2024 13:34 UTC

Return-Path: <garciadan@uniovi.es>
X-Original-To: ace@ietfa.amsl.com
Delivered-To: ace@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A047C15108C; Tue, 12 Nov 2024 05:34:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=unioviedo.onmicrosoft.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y3G5F9oBcSq8; Tue, 12 Nov 2024 05:34:53 -0800 (PST)
Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2132.outbound.protection.outlook.com [40.107.21.132]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 962BFC151087; Tue, 12 Nov 2024 05:34:47 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=eiPlemYihdTflUWD9wwy9UklUKBYDrgV2tJGfCQx4ZRliS0jKGm+nm1ocJCs2u8YqW/VYdSZF2eBLXphoRzswT8vD0XWS4mAEO8lvMMjNudcAV1XYXx5knTSzdAbyAGuZ/uX3y2l1zF0DwVB6gXXk+IVujK0mZVyrqyKYqu70C74aEi1cENbogXTKMW5fOVz4BZvyawPyXmNRj/KV+/6IL5P6LVZr/cGS8Xl8pW8jiWol89UCd0GOeoCGS2vrlm0zsuzXg9KHmdX2WLuhH2qc+Y38gAM+6+FHST8l/ggI7jSb7/bUGFcvtzwgHpCvLv4JNo8wP/7zYigxKLXOGH07Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=nZoagmhFI1RClZVm3SRfW/gyiuNGM1o2UlqdXKSQSj4=; b=bWpspDYYA578vAu/ov6gAm2aBJCG1F4pLmjySAynFaT1DXkUxhFStd9MtzJUlJ7kpSYmf59vVKtk2Zn0QVObqohi57z72n6iFqFgv/nxwl27uUt5arGXKaHzAbqWo7vqOCnLQGubKmLJRKICJamWwi95/2CjCi5MSkdJVkZ6wUgaiDo78xVDOzqCos0NUl4fDGrk8Ps18wzv7ANdhBfsEkz47osB/RmKTQzLJLutoAqJslb0IUMgicBqfVn4o8vtQaymmHV9C7vA6kBQBJNWZijlNE2VfKCDbmM8jm6SfYelJizK7tPXpMTIjUKXAVN69XfHcKHilNodfPY19kQUoA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=uniovi.es; dmarc=pass action=none header.from=uniovi.es; dkim=pass header.d=uniovi.es; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=unioviedo.onmicrosoft.com; s=selector2-unioviedo-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=nZoagmhFI1RClZVm3SRfW/gyiuNGM1o2UlqdXKSQSj4=; b=tOYXfQzTcEQb4x2mlGdfvcIeSEGkIIZSnYyzbaJ8+78v9kR+JsN8GCxQ14FkHD/t0LLnQibN7Llu4gHGcTkPCF9k+ueAwGB6fMP7lDatbv0Mg5YjZ0Ftt7MqaE+94acOleBw/Kwhdryt2L+nq9xUAsJ5W3+DNOaoVmlCKb4FAOk=
Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=uniovi.es;
Received: from AS4PR08MB8093.eurprd08.prod.outlook.com (2603:10a6:20b:588::18) by PAXPR08MB6350.eurprd08.prod.outlook.com (2603:10a6:102:12c::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8137.29; Tue, 12 Nov 2024 13:34:45 +0000
Received: from AS4PR08MB8093.eurprd08.prod.outlook.com ([fe80::efad:bcac:47a9:6619]) by AS4PR08MB8093.eurprd08.prod.outlook.com ([fe80::efad:bcac:47a9:6619%6]) with mapi id 15.20.8137.027; Tue, 12 Nov 2024 13:34:45 +0000
Message-ID: <3dd23b05-c5fc-4272-ad00-148303376151@uniovi.es>
Date: Tue, 12 Nov 2024 14:34:43 +0100
User-Agent: Mozilla Thunderbird
To: Eliot Lear <lear@cisco.com>, iot-directorate@ietf.org
References: <172935977050.1659683.6054585480632855805@dt-datatracker-78dc5ccf94-w8wgc>
Content-Language: en-GB
From: Dan Garcia Carrillo <garciadan@uniovi.es>
Organization: Universidad de Oviedo
In-Reply-To: <172935977050.1659683.6054585480632855805@dt-datatracker-78dc5ccf94-w8wgc>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-ClientProxiedBy: LO4P265CA0128.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:2c6::16) To AS4PR08MB8093.eurprd08.prod.outlook.com (2603:10a6:20b:588::18)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: AS4PR08MB8093:EE_|PAXPR08MB6350:EE_
X-MS-Office365-Filtering-Correlation-Id: a05f0a01-5d26-4fdd-71e5-08dd031ec52d
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|1800799024|366016;
X-Microsoft-Antispam-Message-Info: /1aoKe5+0EtJxQ+NP/4bcM8hLUNLtd9rqxj6flmtu1TBD8FU3Qb0taYEOzJJVMpystVnhuyN1mRENoTT0xa/IWOkmuYTmRtCtzzHj3fIxUSXPWlNQl85VJhiCdhNsJOtIi/C42uPI5k12jv6CXQvS3etqBf6Xs9go64rclY0XrhVkkQvYPnryMRz6A4AkJLJU3xFQYlYree/NZ/WPYi4o57FlQmRF5b2khRfIfjV5sVLvZ/dUK/Oj1KwnuFwAU47375W+Kpg2NwuOdiE/Qi2eRLDRM3QzD3XECDhuV+P2P/FtDYixCQBR1e5jSVPtjpFIxKsizwuj00jowG3hsheV2TMAfLs2Bw9u7EKAUP500TS97zWqONbiM0VfzqFqbcPAETkM3qOEUZUr5eeccjs+FdT6redMJ5FhTVVQbuFCsvhbWR80n+UNdEzuahgTRnYZqT0cXN61htnYdqvJfjze4JhDVAwrGVv7dU81utlECOG/0Uu2Jz0KkcV6yTgHxAtYvg432hZgMIeBhQ/3JEnL0EgmJSfbAEYbNzPTIwI5UZbUnjbm3OEGu9YF+jqpLBlJ1T2VrHfjX/V3ODsNdi6ReqJ3j1VEizl2ryxHvrlsrWxIm0mt3ql5meBeR82JvNBEZal8VahNPCzYA76sbNvkOfIW8J/HVnqMUI+FUnGZlUjJ9HP9Hq0EzJsRRB8Rpna/Ah26LanCt6emxGqc7wKuh2fOctWEEnVa8PxnnlqzYnpVi4hUzZeSBKjZKyV6qyVcd3vtDVbsC3s0Nm2jgnoEAcvSnNTCyKqlkbMAzvQkT4FgZ7Xiz8E8huQTXaWfwU22cp6ehTmSRuij/AZNa+wICQUa9Bc3h4UISGxMnAiNp/AWDg3rD6i6bihI8SFDOz35wtbIorqMSInvfbz9uFps4Pe0x43tiEM3XQaR0osxNrOdWymuaDLO0SkBrTV2JjJxUhtFZvHMk3UnAoA4B88zQuLBAV3nbPp5ves/qlCcTtMbjVaaAwsxJmglwK6+9orkCJYr0yDwoZYqBuLUB6psfdqIAA4McC9KmFaxCob1cqhK0Ynai6QdyAyBsH5/2NpBKrRPFRaz1tMZiYfWsQVyfG94QEOpU7i3QB2GXVumAPZyZIK4b9sAZ5qPa1A7P1+okB12Aw1fInN1AVvEUVwZ5d6vn93R6gsVG3G9qMNbnTXNhwuoY7n6ctcjWcSd6k5a6sJhU5F2Zqr1FntaNNN80uZvFPK2XrGDK2M12CAwrokdfGfKWPPsznAfEyLJkYEzQHepccslPwDbjaziUnvqsFehL5rqthIZH4Dn43LO1Q1gGGlXV5mC/ecE/o9p/CR
X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS4PR08MB8093.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016);DIR:OUT;SFP:1102;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: MRRZuvisUpMgt/5ix4m5Yhv/rxWKf+R+HaQbDfjL+W3x6/DDye5HqfR+3SRtJnP2XFsA92hIFaVGgBJZW/aHxy04n5tHfsYMljVenzp7c30zzrimA1CKUXYmdQQuNDEsBX6SaQ3WZR9d7spPXRJ2EX7ycq+zdee0sIRd4uRljHIEym66SQmgvcsOA5W8me4dC+n6GNfoU9/0c09MK9mifNIQeNkCiTWeq2qRRdkd4Uev4DXwMsDT0uzTZUUCcuwObouWPePczJRnY9NLnu8KO5vSA7p0ie7tJCNOaVOxUza+UZjWhmSFM7nHHW7yXnU8v/dkstuHki3LWESzdD5js/NuD9zlxzAsjPMa18Kwf2WJRv041+PrbuWw4j+sBLgxvpu+hvt+vo1tGGZzkfE/x1TdUD0VHyRvZDqs7N3y3zgEuXX5b3mZSwY7N/LZZuplg7jsz3p0gbyC/9tkW9NY5Y0HFzY/FwmUObWAdbTy+cDjIl5abZiDlNJzeDigucV4f1gQXAgsEWodhUbfiSuzl0FEczsNFpAhHnXKSLmUNlbG847Agryh51lccc+Zb4e2Acz1zz8Y82qTNvouMl2KKnO7+qrD1ikVAMmeUB5yyxX9+eOwPSMkBUF8wyfHl/2fxPZY8v4FEnyP7QDM3jto3dUmr3E2sxzLEQstuijm8LB6214eJxiOzyfo+F+VgI8GV9jCLLu989M5uVcgU4YvQdXqRiBtJVr9RhECObODLlNVzhbFBkfeQ3HIOg9PygF7VKGJ7OZMqX2jfqmWYkDRS2oPuDw6YPetSdFKFx6sw9evu+xJpxh280287bzg6M5Is/Yj11cttFuqdqrixQKFxmIlOQ6EVMj2HvibT+m/KC00nV8dtMQ3mp7t4rV0QPieEW82uHj/GqwZFD23TTDtBNr0j6UjdAF0jzKsyPIvONQOtOnFG7Z0B3y4m6nVV+S0BRSiMapt91dRAVb1QAlWeztXfLV2g/uED7sU1vWriUxRDGDmLAEXQjzzWoJDEkDRMclob+XHd/IpVTHfk6V79yULKB6JppQge3D2hQOEW0OVDjwEEtgLxyB5U+HQb/380LU6bt29Sx7rCxBaL3u2UHCAk2ejrmNLYQR3gb9BE7xaRYumP1U/jUoV/xRvB7Vb5ohtpsoIJ3HiOnH3tZh3iWaGx1mVWrWyUCfBKL1Ni2O2KvOQNLWB/HnKOhYe9XFL76DHX0cLw/T+faGPPv3B0ccEVaevKZGPOCJyopAywXjt7Y00zKK6U3wxWx6u6fTcJoE4GHAEiU5hbYe0Lb4yDWpiJnOPl9Xz2QBIjAt74Ci/w1nfV7u/VvtwOXuiLn9pWOXWgdeGge6q25wg9QdVHFz2RT3OCe6sbRJsBYx8QoM5vMU7zsuqtvU61q9vMqlVn3wgD/fxqN5cuMOQ9eqQWzCvvsm5Z/ldr7SVvg44yimZKgQx8phHKYQJaXlAGq/zwFS8EM13mtsYnpEwZ3XgPeviLmVMK+r+XzAiLEOQKCN2juohMQvI3Ls0/0w5bsCGy0+s6gTtYF5uFHhIX00nAJA1SsRSpJUZ3YH9XK75Z7Lh8vHR7UGs4O7ueVTZQDHC
X-OriginatorOrg: uniovi.es
X-MS-Exchange-CrossTenant-Network-Message-Id: a05f0a01-5d26-4fdd-71e5-08dd031ec52d
X-MS-Exchange-CrossTenant-AuthSource: AS4PR08MB8093.eurprd08.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Nov 2024 13:34:44.9778 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 05ea74a3-92c5-4c31-978a-925c3c799cd0
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: gVR+NhJsCARN4DrE5KNq/TjkV4chtFqbCWXu8byuFDy4s06zTMckUTlJ0LHXiGHcn1OXXYWLH5w0DVfiNe7HQQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAXPR08MB6350
X-MS-Exchange-CrossPremises-AuthSource: AS4PR08MB8093.eurprd08.prod.outlook.com
X-MS-Exchange-CrossPremises-AuthAs: Internal
X-MS-Exchange-CrossPremises-AuthMechanism: 14
X-MS-Exchange-CrossPremises-Mapi-Admin-Submission:
X-MS-Exchange-CrossPremises-MessageSource: StoreDriver
X-MS-Exchange-CrossPremises-BCC:
X-MS-Exchange-CrossPremises-OriginalClientIPAddress: 156.35.171.42
X-MS-Exchange-CrossPremises-TransportTrafficType: Email
X-MS-Exchange-CrossPremises-Antispam-ScanContext: DIR:Originating;SFV:NSPM;SKIP:0;
X-MS-Exchange-CrossPremises-SCL: 1
X-MS-Exchange-CrossPremises-Processed-By-Journaling: Journal Agent
X-OrganizationHeadersPreserved: PAXPR08MB6350.eurprd08.prod.outlook.com
Message-ID-Hash: CMJXFFZSEOKK6UC42NCIX2A5BJXQFKSS
X-Message-ID-Hash: CMJXFFZSEOKK6UC42NCIX2A5BJXQFKSS
X-MailFrom: garciadan@uniovi.es
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-ace.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: garciadan@uniovi.es, ace@ietf.org, draft-ietf-ace-wg-coap-eap.all@ietf.org, last-call@ietf.org
X-Mailman-Version: 3.3.9rc6
Precedence: list
Reply-To: garciadan@uniovi.es
Subject: [Ace] Re: Iotdir telechat review of draft-ietf-ace-wg-coap-eap-11
List-Id: "Authentication and Authorization for Constrained Environments (ace)" <ace.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/svEbX4JVCVqwTbypPnYqhqyAWBc>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ace>
List-Help: <mailto:ace-request@ietf.org?subject=help>
List-Owner: <mailto:ace-owner@ietf.org>
List-Post: <mailto:ace@ietf.org>
List-Subscribe: <mailto:ace-join@ietf.org>
List-Unsubscribe: <mailto:ace-leave@ietf.org>

Dear Eliot,

Thank you again for your review.

After your e-mail we think we can consider the following cases:
A) The node does not have an IPv6 address (non IPv6 connectivity)
B) The node does have an IPv6 address (e.g. link-local IPv6 link-local 
or IPv6 global address)

It is important to mention that if EAP over a particular link-layer 
(e.g. IEEE 802.1X) is already in place for network access, CoAP-EAP can 
be used for a secondary authentication for other services, as commented 
in C.5.2. (that would be an example of B with IPv6 global address)
In the case of A), we will need support for the transport of CoAP-EAP at 
link-layer. For example, in IEEE 802.15.4 networks, a new KMP ID can be 
defined in IEEE 802.15.9 to add such support.

In the case of B) we can assume that the device has at least a 
link-layer IPv6 address to run CoAP-EAP, be it directly with the 
Controller or through an intermediary entity such as proxy, as we 
mention in  3.6. Proxy operation in CoAP-EAP. Once the authentication is 
completed, we can assign a global IPv6 address to the device. This would 
follow a similar model as 6TiSCH Join Protocol or Zigbee IP.

Regarding the case where we intend to add support for CoAP-EAP in mesh 
networks, we would follow the same process we either have connectivity 
with the Controller, or through an intermediary entity (proxy) that is 
already authenticated and can aid in running CoAP-EAP, as discussed in 
section 8.3 and in the new text of section C.5.1

To make this possible, as expressed in 8.3. Allowing CoAP-EAP traffic to 
perform authentication. "This link MUST authorize exclusively 
unprotected IP traffic to be sent between the EAP peer and the EAP 
authenticator (or the CoAP proxy) during the authentication with 
CoAP-EAP." . We have also added the following text to highlight the 
possibility of link-layer support for CoAP-EAP:
"
Alternatively, the link-layer MAY provide support to transport CoAP-
EAP without a IP address by using link-layer frames (e.g. by defining
    a new Key Management Protocol ID in IEEE 802.15.9 [ieee802159]).
"

For admission and removal, text in section C.5.1 incorporates now this 
discussion.
The resulting added text is the following:
"In the process of joining a network, we may find two cases: 1) the
    node does not have an IPv6 address; 2) the node does have an IPv6
    address (e.g., link-local IPv6 or IPv6 global address).

    In networks where the device is placed and no IP support is available
    until the EAP peer is authenticated, specific support for this EAP
    lower layer has to be defined to allow CoAP-EAP messages to be
    exchanged between the EAP peer and the EAP authenticator.  For
    example, in IEEE 802.15.4 networks, a new KMP ID can be defined to
    add such support in the case of IEEE 802.15.9 [ieee802159]. Where we
    can assume that the device has at least a link-layer IPv6 address.

    When the EAP peer intends to be admitted into the network, it would
    search for an entity that offers the CoAP-EAP service, be it the EAP
    authenticator directly, or through the intermediary (i.e., proxy).
    See Section 3.1.

    CoAP-EAP will run between the EAP peer and the EAP authenticator or
    through an intermediary entity such as a proxy, as happens in a mesh
    network, where the EAP authenticator could be placed to 1 or more
    hops from the EAP peer.  In the case a proxy participates in CoAP-
    EAP, it will be because it is already a trustworthy entity within the
    domain, which communicates through a secure channel with the EAP
    authenticator, as illustrated by Figure 11.

    Thus, the EAP peer follows the same process described in
    Appendix C.5.1 to perform the authentication.  As mentioned, we
    either have direct link to the EAP authenticator, or through an
    intermediary entity (proxy) that is already part of the network
    (already shares key material and communicate through a secure channel
    with the authenticator) and can aid in running CoAP-EAP.

    When CoAP-EAP is completed, and the OSCORE security association is
    established with the EAP authenticator, the EAP peer receives the
    local configuration parameters for the network (e.g. a network key)
    and can configure a global IPv6 address.  Moreover, there is no need
    of a CoAP proxy after a successful authentication.

    For removal, if the EAP authenticator decides to remove a particular
    EAP peer from the network or the peer itself intends to leave, either
    EAP peer or EAP authenticator can directly send a DELETE command to
    explicitly express that the network access state is removed, and the
    device will no longer belong to the network.  Thus, any state related
    to the EAP peer is removed in the EAP authenticator.  Forced removal
    can be done by sending new specific key material to the devices that
    still belong to the network, excluding the removed device, following
    a similar model as 6TiSCH Join Protocol [RFC9031] or Zigbee
    IP[ZigbeeIP].  The specifics on how this process is to be done, is
    out of scope of this document.

   +----------+        +----------+ +--------------+
   |    EAP   |        |   CoAP   | |      EAP     |
   |    peer  |<------>|   Proxy |<------------------------->| 
authenticator|
   +----------+  CoAP  +----------+          CoAP +--------------+
                                          OSCORE/DTLS
                                   <--(Security Association)-->

                 Figure 11: CoAP-EAP through CoAP proxy

    Given that EAP is also used for network access authentication, we can
    adapt this service to other technologies.  For instance, to provide
    network access control to very constrained technologies (e.g., LoRa
    network).  Authors in [lo-coap-eap] provide a study of a minimal
    version of CoAP-EAP for LPWAN networks with interesting results.  In
    this specific case, we could leverage the compression by SCHC for
    CoAP [RFC8824]."

Best regards.

El 19/10/24 a las 19:42, Eliot Lear via Datatracker escribió:
> Reviewer: Eliot Lear
> Review result: Ready with Issues
>
> This is a follow-up to my earlier IoT directorate review.  In that review I
> raised four issues:
>
> 1. Proper illustration of EMSK key derivation (this is somewhat optional)
> 2. Terminology alignment
> 3. MTU issues
> 4. A difference between how EAP is used (e.g., without IP connectivity) and
> this work.
>
> All four points have (mostly) been addressed, although I have comments on the
> last one.  There is a key deployment aspect missing that I would suggest the WG
> consider:
>
> When dealing with EAP at the 802.1X layer, since the device doesn't have an IP
> address, in effect from the application point of view, and even at certain
> kernel layers, the interface is down.  That means that no address has been
> assigned, and from the network edge standpoint, no IEEE 802.1q VLANs assigned
> either.
>
> One complication that remains is this: if the network enables access based on
> VLAN assignments, then the L3 address may need to change.  Upper layers in the
> client need to be prepared for that, and address plans may need to take it into
> account.  I suggest that some operational cautions be added to address these
> points.
>
> In addition, and without going into a whole lot of detail, if this method is
> being made use of by a mesh network for permitting access, it must be clear how
> both admission and removal are handled; or an applicability statement should be
> added that until someone does that work, this document should not be
> recommended for such networks.
>
>
>
-- 
Dan García Carrillo

---------------------
Departamento de Informática, Área de Telemática, Universidad de Oviedo
2.7.8 - Escuela Politécnica de Ingeniería, 33204, Campus de Viesques, Gijón
Tel.: +34 985182654 (Ext. 2654) | email: garciadan@uniovi.es