draft-ietf-udlr-lltunnel-04.txt

[Emmanuel Duros <Emmanuel.Duros@UDcast.com>]

We received several comments from the IESG members about the lastest
spin of the link layer tunneling mechanism draft.

Here are the comments extracted from the original mail from Dave
Oran. We are currently working on it to update the document and to make
it clearer on some points.

Dave Oran already gave us his own thoughts that are taken into account.

-----
1. the security considerations fail to list the threat of ARP spoofing
when ARP packets are being tunneled over the back channel.

2. (comment 1)
This draft seems oriented to applications such as WebTV and similar scale
uses.  One worries that other flavor applications, e.g. highly assymetric
high-bandwidth inter-continental backbones, would find it not useful but be
faced with "you're not doing it the ietf standard
way."  Hence the addition of an applicibility statement to the draft
would be helpful.

(comment 2)
First, this document isn't as general as I would have expected it to
be. From the title, I expected it to be a way to handle generic
unidirectional links. However, the architecture seems to rule out two
nodes connected to each other by unidirectional links. (Or maybe I'm
just confused by the send/feed terminology) I.e., there are parts in
the draft that seem to require that a receiver must have a
bidirectional interface in addition to the unidirectional one:

>    A receiver has several interfaces, a receive-only interface and one
>    or more additional bidirectional communication interfaces.

It might be good to make the applicability more clear, as I don't
think this has the general applicability that one might expect from a
unidirectional link mechanism.

3. >    Tunnel Type (8 bit unsigned integer): tunneling protocol supported
by
>      the feed; receivers MUST use this form of tunnel encapsulation when
>      tunneling to the feed.
>      47 = GRE [rfc2784] (recommended)
>      Other values may be used, but their interpretation is not specified
>      here.

An IANA considerations section is needed to give guidance for future
assignment of values to this (and other?) fields.

4. > "DTCP announcement" multicast group is 224.0.1.124.

Seems like a link-local address would be more appropriate (224.0.0.x).

5. > 8.2. Encapsulation of UDL MAC level packets
>
>    An alternative is to encapsulate the MAC level packet within IP. The
>    protocol field in the IP datagram is then set to the MAC type of the
>    unidirectional link. Figure 5 presents the entire encapsulated
>    packet.
>
>            ----------------------------------------
>            |           IP delivery header         |
>            |        destination addr = FBIP       |
>            |    IP proto = MAC type of the UDL    |
>            ----------------------------------------
>            |            Payload packet            |
>            |             MAC packet               |
>            ----------------------------------------
>
>                  Figure 5: Encapsulated packet

I think this section should just be removed. We don't have enough IP
protocol values to do this in general, and I suspect any tunneling
scheme for doing link-layer above IP would require its own RFC anyway
to nail down some of the details. Why is this any better than using
GRE? Are there implementations of this in products?

6.> 10. Security Considerations
>
>    Security in a network using the link layer tunneling mechanism should
>    be relatively similar to security in a normal IPv4 network. However,
>    as the link layer tunneling mechanism uses GRE[rfc2784], it is
>    expected that GRE authentication mechanism combined with a specific
>    link layer security mechanism on the back-channel will help to
>    enhance security in a unidirectional link environment.

And what GRE authentication mechanism would that be? AFAIK, GRE has no
authentication.
------

Please, feel free to discuss.

Emmanuel
--
UDcast: Where IP and UniDirectional links meet
http://www.UDcast.com