IP over MIME
draft-eastlake-ip-mime-10
Discuss
Yes
No Objection
No Record
Summary: Needs a YES. Needs 10 more YES or NO OBJECTION positions to pass.
Alvaro Retana No Record
Andrew Alston No Record
Erik Kline No Record
Francesca Palombini No Record
John Scudder No Record
Lars Eggert No Record
Martin Duke No Record
Murray Kucherawy No Record
Paul Wouters No Record
Robert Wilton No Record
Roman Danyliw No Record
Warren Kumari No Record
Zaheduzzaman Sarker No Record
Éric Vyncke No Record
(Alex Zinin; former steering group member) 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???
(Ross Callon; former steering group member) 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.
(Steven Bellovin; former steering group member) 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.
(Ned Freed; former steering group member) Yes
(Allison Mankin; former steering group member) No Objection
(Bert Wijnen; former steering group member) (was Discuss) No Objection
(Bill Fenner; former steering group member) No Objection
(Brian Carpenter; former steering group member) No Objection
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.
(Cullen Jennings; former steering group member) No Objection
(Dan Romascanu; former steering group member) No Objection
(David Kessens; former steering group member) No Objection
(Harald Alvestrand; former steering group member) No Objection
(Jon Peterson; former steering group member) No Objection
(Magnus Westerlund; former steering group member) No Objection
(Margaret Cullen; former steering group member) No Objection
(Russ Housley; former steering group member) No Objection
(Ted Hardie; former steering group member) No Objection
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.