Subject: (NAT) Revised NAT WG minutes - IETF 46 (Please ignore the previous posting)

From: Pyda Srisuresh <[email-masked]>
Date: Mon, 22 Nov 1999 07:00:51 -0800 (PST)

NAT WG meeting minutes - 46th IETF - Washington, DC - Nov 7, 1999
=================================================================

 Chairs: Pyda Srisuresh - [email-masked]
         Matt Holdrege  - [email-masked]
                                     
 Reported by: George Tsirtsis    - [email-masked]
              Gabriel Montenegro - [email-masked]

 Prepared by: Suresh & Matt
                                                            
___________________________________________________________________________

 Mailing list:   [email-masked]
 To subscribe:	 Send e-mail to [email-masked] with "subscribe" 
                 in the body of the message. Only messages from subscribers 
                 are posted to the list.
 To unsubscribe: Send e-mail to [email-masked] with "unsubscribe" 
                 in the body of the message. 

 Mailing list:   [email-masked] 
                 (This is nat mailing list, in daily-digest format. To receive 
                 the digest, you can subscribe as follows.) 
 To subscribe:   Send e-mail to [email-masked] with 
                 "subscribe" in the body of the message. 
 To unsubscribe: Send e-mail to [email-masked] with 
                 "unsubscribe" in the body of the message. 

 Powerpoint files used by the speakers may be found at the following URL:
                 ftp://ftp.ascend.com/pub/standards
____________________________________________________________________

In order to avoid confusion, the following indentation and format legend
should be used as a guide to interpreting the minutes.

<Presenter> - "<presentation/Discussion Topic>"
<Remarks by minutes taker or editors>
  
  Detailed Slides and/or Comments made by the presenter

     Questions from the Audience:

        [<Audience-Name> - <Question/Comment>]

                          <Response from the Presenter>

_________________________________________________________________________

Matt Holdrege -  Agenda

   Daniel Senie
      draft-ietf-nat-app-guide-02.txt

   Dan Raz
      draft-ietf-nat-snmp-alg-02.txt

   Pyda Srisuresh
      draft-ietf-nat-interface-framework-00.txt

   Mike Borella, et al
      draft-ietf-nat-rsip-framework-02.txt
      draft-ietf-nat-rsip-protocol-03.txt
      draft-ietf-nat-rsip-ipsec-00.txt

   Carmello Zaccone
      draft-zaccone-nat-rsip-gen-arch-00.txt
      draft-zaccone-nat-transo-fram-00.txt
      draft-zaccone-nat-transport-01.txt

   Matt Holdrege
      draft-ietf-nat-protocol-complications-01.txt

------------------------

Vern, Transport Area AD, said that ipr should be disclosed as early 
as possible. if you can't disclose, you MUST abstain from discussion of the
technology. you have a moral obligation to do so. no comments on what would
happen if you don't abide by this ietf policy.

------------------------

daniel senie - nat-app-guide-02.txt

Comments received from Suresh but not from anyone else. More comment are
welcome. Will get a new rev of the draft out shortly.

----------------------
dan raz - nat-snmp-alg-02

defined further problem scope, limitations and alternatives solutions,
eliminated snmp discussion

   basic: translates only ip addresses only in pdu's from station to manager
          no change in pkt length

   advanced: xlates non-standard encodings, xlations in pdu's from
          station to manager and back. results in change of pkt length.

   real need from the nw mgmt service provider industry

      Juergon: There are technical problems (sorry for not having time to 
               do this on the list). Need to discuss snmpv3 (not just v1), also
               some conclusions and mechanisms are suspect.

      answer: we're addressing industry need, and nobody is using v3 today.

      suresh: what are the issues?

      answer: main concern - we need to know what snmp alg can do and cannot do
              and impacts/consequences on snmpv1 versus v3

      matt: should discuss v3, but v1 is definitely in order.

----------------------------
suresh - nat-interface-framework-00

   framework for interfacing with nat.
   predecessor: nat api draft (bad name)

   There is renewed interest in the draft because of (a) mib spec for nat, 
   (b) requirements on how to interface with a NAT as an alg, etc.
   so revised and reworded the old draft to address these issues specifically.
   This draft should also help in identifying RSIP protocol requirements.

   Also described is how an FTP-ALG would use the interface to influence
   NAT operation. 

   FTP-ALG registration process expressed in the context of this framework
   functions exchanged between the ftp-alg and the nat gw

   working group polled for any comments.

     Elliot Lear: Is there support for moving this forward as an RFC?
     
     No comment from the audience.

     Suresh:      Anyone who doesnt want the draft move forward?
          
     No comment from the audience.

     Elliott:     The draft should move forward only if there is explicit
                  request from the work group instead of operating the 
                  other way around.

     No comment from the audience.
-----------------------------------------

mike borella - RSIP drafts

   RSIP framework draft-

   major editing and reorganization
        client and server reqs
        mtu stuff
        rsap-ip servers
        deployment scenarios
        rsip/nat cascades
        multi-homed (preliminary)
        mobile ip (preliminary)

   rsip behind rsip
   nat  behind rsip 
        e2e still broken
        nat box is rsip client
   rsip behind nat: 
        e2e broken
   
   rsip through nat
        need rsip alg in nat box
   only rsip behind rsip makes any sense, really
   but as you deploy rsip into a natted world, this is a good document

   Multihoming 
        more than 1 rsip gw per net for redundancy and failover

        This can be addressed in different ways from simple mechanisms to heavy
        weight (transaction processing type of thing) but it is not critical
        for RSIP at this stage.

   interaction with mobile ip
        how to add rsip stuff to mobile ip
        some preliminary discussion, but need to flesh it out and
        coordinate with mobile ip working group

       suresh:  it's ok to not finish everything on the first round, as long as
                you scope clearly what is being solved. Need to finish the 
                framework and basic protocol first. Work on other issues 
                in parallel.

       Matt:    you can always ask the mobile ip list for comments.

       Brian Carpenter: 
                Need to know if there are show stoppers in mobile IP 
                and any other protocol, details can be worked out later.

   Mike continue with the presentation.

   next steps - Still need to work on the following:
        rsip and mcast
        rsip/rsvp/diffserv
        registration of servers via dns servers
        locating rsip servers - particularly if you're not on the
        same subnet - Use dhcp or SLP?
        session authentication

    must scope rsip to be able to finish it (at least partially) within
    the near future

       suresh: is rsip an app specific configuration or host specific 
               on the client? There might be reasons to only use RSIP 
               for a set of applications.

       matt:   It is stack specific.

       Gab:    similar problem to mobile ip and ipsec: it's possible to
               use it selectively

       Elliot:  Much better than last draft. Still some issues with the draft:
                - How much routing is required in the client?
                  Does host need Routing info? routing tables in the client 
                  can get fairly complex. must clarify. 
                - How does it use SLP?
                - There are some security implications. what if you use ipsec 
                  for the rsip tunneling from the outside? nobody can 
                  determine who is actually speaking to whom. this is both 
                  good and bad and should be documented.
                - What if you rap RSIP in IPSEC? Some interesting trust 
                  relationships.

       Danny Raz: UDP packet size might be larger than what the spec says.
                  udp mtu of 500? where from? 

       suresh: Two points:
                - A node should be able to select when to use NAT and when 
                  to use RSIP.
                - You may have multiple RSIP instances. RSIP instance ID is
                  needed to select which RSIP instance (i.e., address pool) 
                  to use.

       Elliot lear: Two points.
                   1. rsip is a remediation. it's got overhead. Applications
                      should be able to do things other than RSIP. Need to 
                      discuss on e-mail
                   2. cascading rsip servers you used public address
                      space, this is the right thing. when you cross
                      realms the recommendation worth restating is that
                      you use public addresses.

       Brian Carpenter: on point 2 above, clear conclusion from the iab 
                        workshop is that the global address space is a 
                        requirement

                        on point 1 above: application must be aware? 
                        no, then just use ipv6. that's the whole point.

    RSIP protocol draft - 

    Streamlined. One way of doing rsip. Basic primitives to do rsip.
    Anything else should go in a separate draft (like rsipsec)

    To be done:
        overall length field in msgs
        error messages must be fleshed out

    What should be the trasport medium for RSIP? - tcp vs udp

        Matt:   If there are no objection the best thing is to have only one
                transport protocol and this is TCP. If later we realise that 
                UDP is needed for a case we can do it later.

        Mike:   I agree

        suresh: Server could support both and client should be able to choose 
                between the two since the RSIP protocol does not depend on the
                underlying transport medium.

        Mike:   In fact there might be changes in the protocol. 
                E.g some things are not needed if you do TCP.

        Eliot:  Also agrees that ONE protocol is best but RSIP seams too 
                lightweight for heavy TCP connections.

        Mike:    Other things constrain RSIP resources before TCP state 
                 becomes a problem
        Elliot:  What are the benefits of TCP?
        
        Mike:    better security, reliability
        Bernard: TCP also helps with state control since the TCP connection 
                 will drop if a client crashes.
        Gabriel: Auto-tuning can solve the large number of TCP connections 
                 problem.
        
        Matt asked for show of hands:
            The rough consensus was to use TCP-only as the transport.
            UDP may be brought in later on.

        Suresh:  Couple of other comments.
                 - After hearing Brian Carpenter's comment about applications 
                   not requiring change with RSIP, I agree with him. Now, I 
                   do believe, RSIP should be host specific - not application 
                   specific.
                 - More examples are needed during protocol specification.
                 - There seems to be an underlying assumption throughout the
                   the document that address assignment is a function of the
                   RSIP server and that address assignment and tunneling are 
                   in the same box. (Mike says yes!)
                 - Other than tunnels might also be used to traverse RSIP 
                   packets in private realm. Ex: Zaccone drafts, NAT based 
                   translation of encapsulating header.

        Mike:    Tunnel is the only mechanism we are sure will work at the 
                 moment.

    RSIP IPsec draft - 

    Just made the cut-off day. Some work is still needed here.

        Gabriel Montenegro: Need discussion on how to handle incoming SAs

        Bernard Aboba: There might be an issue with interactions with 
                       IPSEC bump-in-the-stack implementations.

----------------------------------

carmelo zacconi - RSIP transport (within private realm) framework

      Possible extensions on the RSIP framework on the transport of
      datagrams in a native way without using tunnels.

      Enable forwarding of incoming packets without tunneling  to the 
      rsip client

      How to enable these reverse paths? the other drafts
      explore specific mechanisms with their tradeoffs.
      Specific mechanisms to build the reverse path are:
      1. ospf minimized router daemon on the host
      2. multicast - create a tree
      3. rsvp - install info on a restricted set of routers

      RSIP-gen-arch - 
      
      Aim to make RSIP more reliable
      De-couple set of functions from RSIP server
      Support RSIP multihoming
      Offer policy and accounting
      Assume multiple ISPs and multiple function blocks building RSIP (Policy
      Manager, Internet Session Manager and Configuration Manager)

        Brian Carpenter: 1. The idea of not using tunnels when you can is good.
                         2. Multihoming needs to be solved but this seams like 
                            a very complex solution because it attempts to 
                            define an architecture. IETF only defines tools. 
                         3. Reliability is important but having a lot of 
                            stateful boxes is against Internet design 
                            principles and may damage the stability of the 
                            whole system.

        Gabriel Montenegro(Gab): 
                    On the transport alternatives: suggest to have 
                    routing ADs look at this, as this is not specific to rsip
                    but may apply in other areas as well, and is hightly 
                    routing specific in content.

        Eliot Lear:  Many interesting points in the draft (not agree with all).
                     Not using tunnelling is also good if you try to do things 
                     like Diffserv. The separate Policy Manager is also a good 
                     idea.

	Suresh:      The draft is interesting and may have wider applicability
                     as the draft is really about RSIP route/policy enforcement
                     on the routers in private realm.
  
        Mike Borella:  This is interesting for rsip+ but is perhaps not part
                       of rsip first release.

--------------------------------
matt holdrege - NAT protocol complications.

     Matt will issue an IETF last call after the next rev is posted.

         Tony Hain: Scott bradner currently has the pen on the IAB document.
                    Should get a new rev out in a couple of weeks (by the 
                    end of 11/99?)
--------------------------

james kempf (sun) - Using SLP for RSIP server discovery

    why not to use DHCP; but use SLP:
       - dhcp requires configuration on the server (home networks?)
       - slp requires nothing but the rsip server
       - slp uses mcast (versus bcast)
       - dhcp can't specify attributes
       - slp can find server based on attributes
       - option number space in dhcp is running out
       - slp is not a problem, define a url/template, text based
       - dhcp can't do dynamic updates
       - slp reflects availability dynamically

    Template for rsip servers
       template-type = rsip
       template-version = 0.0
       url-syntax = ;nothing_beyond: host:port
       ipsec-support = BOOLEAN
       ike-support = BOOLEAN
       tunnel-type = STRING L

       etc.. draft forthcoming
          
           suresh:       seems applicable

           Elliot lear:  how to handle multiple rsip servers?

           jim kempf:    slp has a semi-reliable mcast called mcast convergence
                         which can aid in this

           Mike borella: looked at dhcp individual submission draft that 
                         defines dhcp option for server redirect

           suresh:       suggests this draft be submitted as working group 
                         item. seems like a good idea to have both options - 
                         DHCP configuration option as well as SLP.
--------------------------------------------------------------------------
__________________________________________________
Do You Yahoo!?
Bid and sell for free at http://auctions.yahoo.com
-
To unsubscribe, email [email-masked]' with
'unsubscribe nat' in the body of the message.