IP over MIME
draft-eastlake-ip-mime-10
Discuss
Yes
(Ned Freed)
No Objection
(Allison Mankin)
(Bert Wijnen)
(Bill Fenner)
(Cullen Jennings)
(Dan Romascanu)
(David Kessens)
(Harald Alvestrand)
(Jon Peterson)
(Magnus Westerlund)
(Margaret Cullen)
(Russ Housley)
No Record
Deb Cooley
Erik Kline
Francesca Palombini
Gunter Van de Velde
Jim Guichard
John Scudder
Mahesh Jethanandani
Murray Kucherawy
Orie Steele
Paul Wouters
Roman Danyliw
Warren Kumari
Zaheduzzaman Sarker
Éric Vyncke
Summary: Needs a YES. Needs 10 more YES or NO OBJECTION positions to pass.
Deb Cooley
No Record
Erik Kline
No Record
Francesca Palombini
No Record
Gunter Van de Velde
No Record
Jim Guichard
No Record
John Scudder
No Record
Mahesh Jethanandani
No Record
Murray Kucherawy
No Record
Orie Steele
No Record
Paul Wouters
No Record
Roman Danyliw
No Record
Warren Kumari
No Record
Zaheduzzaman Sarker
No Record
Éric Vyncke
No Record
Alex Zinin Former IESG member
Discuss
Discuss
[Treat as non-blocking comment]
(2004-02-18)
Unknown
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 IESG member
Discuss
Discuss
[Treat as non-blocking comment]
(2006-05-16)
Unknown
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 IESG member
Discuss
Discuss
[Treat as non-blocking comment]
(2004-02-18)
Unknown
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 IESG member
Yes
Yes
()
Unknown
Allison Mankin Former IESG member
No Objection
No Objection
()
Unknown
Bert Wijnen Former IESG member
(was Discuss)
No Objection
No Objection
()
Unknown
Bill Fenner Former IESG member
No Objection
No Objection
()
Unknown
Brian Carpenter Former IESG member
No Objection
No Objection
(2005-11-23)
Unknown
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 IESG member
No Objection
No Objection
()
Unknown
Dan Romascanu Former IESG member
No Objection
No Objection
()
Unknown
David Kessens Former IESG member
No Objection
No Objection
()
Unknown
Harald Alvestrand Former IESG member
No Objection
No Objection
()
Unknown
Jon Peterson Former IESG member
No Objection
No Objection
()
Unknown
Magnus Westerlund Former IESG member
No Objection
No Objection
()
Unknown
Margaret Cullen Former IESG member
No Objection
No Objection
()
Unknown
Russ Housley Former IESG member
No Objection
No Objection
()
Unknown
Ted Hardie Former IESG member
No Objection
No Objection
(2004-02-18)
Unknown
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.