IP over MIME
draft-eastlake-ip-mime-10

As we discussed, you should take a look at whether this draft should
be an encapsulation draft or whether it is something else and make it
all encapsulation or all debugging or whatever.  Also, as I have
discussed this draft with the IESG, other ADs believe I'm not the
right AD to be handling this--or at least other ADs should be given
right of first refusal.  I'm going to removing this draft from
consideration at this time; once you get revisions ready, I recommend
you approach the Internet ADs.  If they are not interested in
sponsoring the draft we can discuss.

[Note]: 'Back on agenda to ask people to restate discusses in terms of discuss
criteria document and to see if any discusses have been addressed.
Note that I have not decided to vote yes; if people want me to pull
the document until I do so, let me know.' added by Sam Hartman

[Ballot discuss]
I am entering a DISCUSS to keep Alex's discuss open, as I have similar
concerns. I think that I could buy this for debugging sorts of uses. However,
on the one hand I don't think that we should publish this for this purpose
unless there is some interest by someone to use it (which might be the case,
thus "discuss" in the English sense applies), but also there is some text
which implies other uses, for example, from the end of section 1:

  An unambiguous MIME encoding for IP datagrams is useful in their
  transmission for monitoring, analysis, debugging, or illustrative
  purposes.

Okay.

  In addition, IP over MIME can be used as one component in creating
  application level tunnels.

What is an application level tunnel supposed to be? Is this for getting
through firewalls (in which case what router is going to decapsulate on
the other end, and there will be security and performance implications)?

Similarly in section 2:

        While this is not usually a concern if a packet is just being
        communicated for analysis, if such transmission is used to
        establish a tunnel, the sender of a datagram may wish to advise
        the recipient of the estimated rough time dilation factor.

Again the text here suggests that this might be a "real tunnel".

I am sympathetic with Alex's implication that we might simply have gotten
the date wrong (and this might have been intended for publication in very
early April).

Alex also in his discuss questioned whether routing could occur over this
sort of application level tunnel.

In order for me to support publishing this, I think that we EITHER need
(i) All of: a statement that this is ONLY for monitoring purposes, and for
example thus routing is NEVER run over this as an application tunnel; plus
removing the "Application tunnel" text; plus a better understanding of the
motivation (which could be in email separate from the document; or (ii)
change the date to April 1st.

[Ballot discuss]
I am entering a DISCUSS to keep Alex's discuss open, as I have similar concerns. I think that I could buy this for debugging sorts of uses. However, on the one hand I don't think that we should publish this for this purpose unless there is some interest by someone to use it (which might be the case, thus "discuss" in the English sense applies), but also there is some text which implies other uses, for example, from the end of section 1:

  An unambiguous MIME encoding for IP datagrams is useful in their
  transmission for monitoring, analysis, debugging, or illustrative
  purposes.

Okay.

  In addition, IP over MIME can be used as one component in creating
  application level tunnels.

What is an application level tunnel supposed to be? Is this for getting
through firewalls (in which case what router is going to decapsulate on
the other end, and there will be security and performance implications)?

Similarly in section 2:

While this is not usually a concern if a packet is just being
        communicated for analysis, if such transmission is used to
        establish a tunnel, the sender of a datagram may wish to advise
        the recipient of the estimated rough time dilation factor.

[Note]: 'Back on agenda to ask people to restate discusses in terms of discuss
criteria document and to see if any discusses have been addressed.
Note that I have not decided to vote yes; if people want me to pull
the document until I do so, let me know.
' added by Sam Hartman

[Ballot comment]
From Gen-ART review by Mark Allman:

Nits:

  + Abstract: "standardized" -> "specified"

  + Section 1: "This document specified" -> "This document specifies" (I
    only imagine it will continue to do so!)

The larger bit I flagged is a note in section 2 that says:

        Note: Although IP and TCP are defined as timing independent
        protocols, many implementations actually have timeouts built
        in.

I think this statement is just wrong and it needs a little massaging.

  + IPv4 was defined with a TTL that is measured in seconds -- even
    though it's generally implemented as a hop count, that is not the
    way it was specified.  I think this document should at least note
    that there is something to think about here when designing tunnels
    in this way.  (I don't track this stuff closely and maybe we have
    since redefined this as a hop count, ala IPv6.  Regardless, some
    more explanation is needed, I think.)

  + TCP is not and cannot be "timing independent".  TCP relies on a
    retransmission timer for reliability (and, arguably *must* rely on
    such a timer).  It's clearly beyond the scope of this document to
    figure out what to do in this area.  But, a simple note that
    highlights the issue and that one may want to take into account the
    "dilation" parameter when calculating the RTO would seem like a
    useful addition to me.

[Note]: 'Back on agenda to ask people to restate discusses in terms of discuss
criteria document and to see if any discusses have been addressed.
Note that I have not decided to vote yes; if people want me to pull
the document until I do so, let me know.
 ' added by Sam Hartman

[Ballot discuss]
If this is intended as April 1st doc, then it should be Informatuional,
but not stds track.

In any event :-)
- the example IP address should NOT be 10.100.1.10 but out of the
  range set aside for examples!

[Ballot discuss]
If this is intended as Pril 1st doc, then it should be Informatuional,
but not stds track.

In any event :-)
- the example IP address should NOT be 10.100.1.10 but out of the
  range set aside for examples!

[Ballot comment]
I think Alex and Steve have covered the ground here, but I would like to add that I think
having a MIME type for passing IP packets around does have diagnostic use.  A document
that described such a mime type and had the other uses in "Security Considerations--To be
Avoided" would make sense to me.  Not that this would prevent IP over MIME, but that's
not really prevented now for two end points which wish to collude in this way; it would
send the right signal, though.

[Ballot discuss]
Apart from Alex's points -- which I agree with completely -- the security considerations section should mention RFC 2827.  Quite apart from other address-spoofing issues, the address= parameter opens up entirely new forms of attack.  The existing text in the description of address= does not spell out the threat model adequately; though it does note that such messages may need to be signed, it doesn't explain why.

But the real question is why this draft is being presented as a serious standard in the first place.

[Ballot discuss]
Are we shooting for April 1st already?

I must be missing the elephant called "motivation" here.

I could probably live with this as a means to send IP packet samples
around as attachments, if it was a problem.

Using this to transport live IP packets is crossing the line.

Routing over these?...

Any security issues when e-mail authentication and authorization
scheme meets the network one? Any possibility for trojans and DoS?

Transport-related problems when dealing with congestion and
retransmission of packets to "stave off" timeouts???

[Note]: 'Recent IESG seem to indicate this document is acceptable
as-is; ballot issued and added to the next agenda. We''ll
see how it goes.' added by Ned Freed

A tracker bug seems to have left this hanging in Last Call state since May 2003. I forced it to "Waiting for Writeup". - Harald -

AD review comments:

(0) SP in abstract should be IP, right?

(1) The regulation copyright and IPR boilerplate is missing and needs to be
    there.

(2) Given that you discuss IPv6 addresses there probably should be a
    reference to the base IPv6 specification in the same way there's
    one for RFC 791.

(3) Minor typo in security considerations: configures -> configured.

(4) Encoding considerations should have "on transports that do not support
    binary" at the end.

(5) The units for the dilation parameter should be called out explicitly
    in its description.