Subject: [midcom] Fwd: I-D ACTION:draft-iab-unsaf-considerations-00.txt

From: Melinda Shore <[email-masked]>
Date: Thu, 17 Jan 2002 12:32:11 -0500

I'm not sure how many people saw this, or recognized that
it applies to pre-midcom.  This is a draft of a document
describing IAB issues with pre-midcom work, and some conditions
that they'd like to see met.  We're still in the process of getting
the design team together but I think everybody should probably
take a look at the document.

Thanks,

Melinda

>To: IETF-Announce: ;
>Cc: [email-masked]
>From: [email-masked]
>Reply-to: [email-masked]
>Subject: I-D ACTION:draft-iab-unsaf-considerations-00.txt
>Date: Tue, 15 Jan 2002 06:29:00 -0500
>Sender: [email-masked]
>
>A New Internet-Draft is available from the on-line Internet-Drafts directories.
>This draft is a work item of the Internet Architecture Board Working Group of the IETF.
>
>        Title           : IAB Considerations for UNilateral Self-Address Fixing 
>                          (UNSAF)
>        Author(s)       : L. Daigle
>        Filename        : draft-iab-unsaf-considerations-00.txt
>        Pages           : 5
>        Date            : 14-Jan-02
>        
>In order to alleviate the fundamental problem with current NA[P]T
>middleboxes altering the relationship between the apparent location
>and true identity of endpoints, various proposals have been made for
>'UNilateral Self-Address Fixing (UNSAF)' processes.  These are
>processes whereby some originating process attempts to determine  or
>fix the address (and port) by which it is known -- e.g., to be able
>to use address data in the protocol exchange, or to advertise a
>public address from which it will receive connections.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-iab-unsaf-considerations-00.txt
>
>To remove yourself from the IETF Announcement list, send a message to 
>ietf-announce-request with the word unsubscribe in the body of the message.
>
>Internet-Drafts are also available by anonymous FTP. Login with the username
>"anonymous" and a password of your e-mail address. After logging in,
>type "cd internet-drafts" and then
>        "get draft-iab-unsaf-considerations-00.txt".
>
>A list of Internet-Drafts directories can be found in
>http://www.ietf.org/shadow.html 
>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
>Internet-Drafts can also be obtained by e-mail.
>
>Send a message to:
>        [email-masked].
>In the body type:
>        "FILE /internet-drafts/draft-iab-unsaf-considerations-00.txt".
>        
>NOTE:   The mail server at ietf.org can return the document in
>        MIME-encoded form by using the "mpack" utility.  To use this
>        feature, insert the command "ENCODING mime" before the "FILE"
>        command.  To decode the response(s), you will need "munpack" or
>        a MIME-compliant mail reader.  Different MIME-compliant mail readers
>        exhibit different behavior, especially when dealing with
>        "multipart" MIME messages (i.e. documents which have been split
>        up into multiple messages), so check your local documentation on
>        how to manipulate these messages.
>                
>                
>Below is the data which will enable a MIME compliant mail reader
>implementation to automatically retrieve the ASCII version of the
>Internet-Draft.
>Content-Type: text/plain
>Content-ID:     <[email-masked]>
>
>ENCODING mime
>FILE /internet-drafts/draft-iab-unsaf-considerations-00.txt
>
><ftp://ftp.ietf.org/internet-drafts/draft-iab-unsaf-considerations-00.txt>

_______________________________________________
midcom mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/midcom

---

From: "Cullen Jennings" <[email-masked]>
Date: Thu, 17 Jan 2002 21:27:20 -0800

Though I agree with the overall spirit of this draft and many of the points
I have some issues with some of the assertions. Basically it is written in a
form that has a slight smell of FUD about UNSAF. I have no idea where the
best place to post this is so I have sent it to midcom - apologies in
advance if it should go elsewhere. Where else is it being discussed? I'm
sure I am going to regret sending this email, but what the heck, here are
some half baked comments to get the conversation started.

The draft asserts there is no inside and outside - while this may be true
I'm not sure it is relevant. The various UNSAF proposal I have seen have
only contemplated the case where one side of the NAT was in the public
network and could easily be rewritten to say that is assumed the NAT routes
packets between a public to private space and describe the UNSAF method
without ever using the words inside or outside. I understand that NAT can go
from private to private spaces and that UNSAF can only discover the address
relative to some point in the network. However, it seems the point of UNSAF
proposals is to discover the public address of the last NAT to touch the
packet relative to any address in the public space. Inside and outside could
be considered simply convenient terms of art to abbreviate what is meant by
public and private networks spaces. I do believe it is well defined what a
public address is.

The statement there is no way to allow "incoming" communication through
firewalls that honors the policies of the firewall does not seem true. A
firewall can be configured so that HTTTP traffic arriving at port 80 is
routed to the companies web server. Clearly this is "incoming" traffic
thought a firewall - clearly it completely under the control of the firewall
policy what happens to this traffic.

On the topic of statefullness, the UNSAF pings did not create the state,
they simply discovered it. The NAT created the state and if the NAT looses
track of the state, the communications will fail regardless of anything to
do with some UNSAF stuff going on.

I imagine the "exit strategy" of any UNSAF draft will more or less be a
boiler place sentence along the lines of "once IPv6 is widely deployed, and
then once people decide to stop using NAT, this will no longer be used." I
won't know to laugh or cry every time I read that in a draft about a "short
term" solution.

I don't mean to defend NAT or even endorse that we should spend time making
protocols work through them but I think this draft makes it sounds like
UNSAF proposal are questionable at best. If we accept NAT are here and going
to stay long enough that we need to work with them, I think there are
restricted cases where UNSAF could work.

Cullen

_______________________________________________
midcom mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/midcom

---

From: Melinda Shore <[email-masked]>
Date: Fri, 18 Jan 2002 10:08:38 -0500

At 09:27 PM 1/17/02 -0800, Cullen Jennings wrote:
>I have no idea where the
>advance if it should go elsewhere. 

I think it's useful to discuss it here, but it is an IAB document,
not a midcom document.

>then once people decide to stop using NAT, this will no longer be used." 

It would be nice to see a mention of midcom in there.  I am quite
concerned about the pre-midcom work undermining midcom, and I think
that needs to be considered.

>If we accept NAT are here and going

Part of our charge in the pre-midcom work, coming from the
IAB, is to document those restricted cases.

Melinda
Software longa, hardware brevis