Skip to main content

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

Alvaro Retana
Andrew Alston
Erik Kline
Francesca Palombini
John Scudder
Lars Eggert
Martin Duke
Murray Kucherawy
Paul Wouters
Robert Wilton
Roman Danyliw
Warren Kumari
Zaheduzzaman Sarker
Éric Vyncke

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

Discuss [Treat as non-blocking comment] (2004-02-18)
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

Discuss [Treat as non-blocking comment] (2006-05-16)
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

Discuss [Treat as non-blocking comment] (2004-02-18)
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

Yes ()

                            

(Allison Mankin; former steering group member) No Objection

No Objection ()

                            

(Bert Wijnen; former steering group member) (was Discuss) No Objection

No Objection ()

                            

(Bill Fenner; former steering group member) No Objection

No Objection ()

                            

(Brian Carpenter; former steering group member) No Objection

No Objection (2005-11-23)
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

No Objection ()

                            

(Dan Romascanu; former steering group member) No Objection

No Objection ()

                            

(David Kessens; former steering group member) No Objection

No Objection ()

                            

(Harald Alvestrand; former steering group member) No Objection

No Objection ()

                            

(Jon Peterson; former steering group member) No Objection

No Objection ()

                            

(Magnus Westerlund; former steering group member) No Objection

No Objection ()

                            

(Margaret Cullen; former steering group member) No Objection

No Objection ()

                            

(Russ Housley; former steering group member) No Objection

No Objection ()

                            

(Ted Hardie; former steering group member) No Objection

No Objection (2004-02-18)
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.