A Framework for Transmission of IP Datagrams over MPEG-2 Networks
draft-ietf-ipdvb-arch-04

[Ballot discuss]
In section 8, 5th paragraph, the text says:
  >
  > A related role for subnetwork security is to protect users against
  > traffic analysis, i.e., identifying the communicating parties (by IP
  > or MAC address) and determining their communication patterns, even
  > when their actual contents are protected by strong end-to-end
  > security mechanisms (this is important for networks such as
  > broadcast/radio, where eaves-dropping is easy).
  >
  I agree that the link layer is the only place in the protocol stack
  to protect against traffic analysis.  However, most link layer
  security protocols do not provide this service.  For example, the
  encryption provided by IEEE 802.11i does not cover the MAC addresses.
  I do not know about the MPE encryption capabilities.  Does MPE
  protect layer 2 address information?

  In section 8.1, 2nd paragraph, the text says:
  >
  > MPE supports optional link encryption using a pair of bits within
  > the MPE protocol header to indicate the use of encryption.  To
  > support optional link level encryption, it is recommended that a new
  > encapsulation also supports optional encryption of the SNDU payload.
  > Furthermore, it may be desirable to encrypt/authenticate some/all of
  > the SNDU headers. However, the specification must provide
  > appropriate code points to allow such encryption to be implemented
  > at the link layer.
  >
  I take the first sentence as tutorial.  The rest confuses me.  I
  think it is saying that MPE encryption is not supported by this
  specification, and making some recommendations to future authors
  that might want to write a specification to support it.

Date: Mon, 27 Dec 2004 00:12:56 -0800 (PST)
From: Bernard Aboba
To: margaret@thingmagic.com
cc: Jari Arkko , farid.adrangi@intel.com
Subject: EAP WG Review of draft-adrangi-eap-network-discovery-07.txt
X-Originating-IP: 67.182.139.247
X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information)
X-MHO-User: aboba
X-Spam: [F=0.0016566822; B=0.500(0); HS=0.500(-5800); S=0.010; MH=0.500(2004122603); R=0.141(s935/n5693)]

At this point, the EAP WG has completed its review of
draft-adrangi-eap-network-discovery-07.txt.

The document describes a mechanism by which "Identity Selection hints" may
be communicated to an EAP peer, helping it to select an appropriate
Network Access Identifier (NAI).  This mechanism is useful not only for
wireless LAN roaming (the target application) but also in other
applications such as wired network authentication where link layer
identity hints may not be available.

The document has gone through two "pseudo-WG last calls" during which a
number of issues were brought up and subsequently resolved.  The document
was also reviewed by IEEE 802.11u.  A summary of the issues that were
raised and resolved (including Issues 256, 271, 280 and 281) can be found
on the EAP Issues List:
http://www.drizzle.com/~aboba/EAP/eapissues.html

Both EAP WG chairs (Jari and myself) have read the document, and approve
of its publication.  Discussion on the document was not contentious and an
appeal is not expected. However, it is worth noting that IPR has been
asserted with respect to the document:

http://www.ietf.org/ietf/IPR/telecom-italia-ipr-wlan-access.txt

In terms of existing usage, the mechanism described in this document
for communication of hints (NUL separator after the displayable message
within an EAP-Request/Identity) is described in RFC 3748, and
has been implemented in shipping products, although not for the purpose
described in the document.  The ABNF within the specification has been
reviewed for backward compatibility with existing practice.

Given that EAP WG review has been completed on the document, we recommend
that the IESG approve the document for publication as an Informational
RFC via the individual submission route.  Note that the document has a
normative dependence on RFC 2486bis (draft-ietf-radext-rfc2486bis-02.txt)
which has recently gone to IETF last call.