Subject: (NAT) NAT WG minutes - IETF 44

From: [email-masked] (Pyda Srisuresh)
Date: Mon, 29 Mar 1999 08:21:54 -0800 (PST)

Folks,

Below is a first draft of the NAT WG meeting minutes.
Send any corrections to me.

Will the presenters who want to have their slides included
in the minutes, pleae mail me their .ppt files. Thanks.

cheers,
suresh
-----------------------------------------------------------------

NAT WG meeting minutes - 44th IETF - Minneapolis, MN - March 19, 1999

Chairs:   	Matt Holdrege	<[email-masked]>
		Pyda Srisuresh  <[email-masked]>

Reported by:    Ben Rogers      <[email-masked]>
Edited by:      Matt & Suresh
____________________________________________________________________

Mailing list:   [email-masked]

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.

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.

All presentations, along with WG meeting minutes will be avilable
on-line from the following URL (Within a few days after this posting)
 
       http://www.livingston.com/tech/ietf/nat
____________________________________________________________________

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 -  "WG Introduction"

  Agenda

    IESG Document Status
    Architectural Implications of NAT
      draft-iab-nat-implications-03.txt
    Protoocl Complications with the IP network Address Translator (NAT)
      draft-ietf-nat-protocol-complications-00.txt
    NAT Friendly Applications Design Guidelines
      draft-ietf-nat-app-guide-01.txt
    An SNMP Application Level Gateway for Payload Address Translation
      draft-ietf-nat-nat-snmp-alg-00.txt
    Realm Specific IP: A framework draft
      draft-ietf-nat-nat-rsip-framework-00.txt
    Realm Specific IP: Protocl specification
      draft-ietf-nat-nat-rsip-protocol-00.txt
    IP Relocation through twice Network Address Translators (RAT)
      draft-ietf-nat-nat-rnat-00
    Miscellaneous

Pyda Srisuresh - "IESG Document Status"

  Reminded the audience about the Word from the ADs concerning
  presentation discipline, sent as part of agenda e-mail. 

    Presenters should focus on unresolved/outstanding issues rather
    than give tutorial of their drafts. We intend to operate this way
    from this point on, going forward. Further, most of the issues
    should be debated over the mailing list.

    For those presenters, who came prepared with some educational
    viewgraphs, I would be glad to add those slides to the WG minutes,
    even as they donot get to present these slides.

    Terminology draft - is intended to encourage the use of same common
    terms across drafts.  This draft is a required reading for all NATWG
    attendees.

    As for WG drafts with the IESG - the IESG has close to 4 drafts (The
    DNS-ALG went through WG last call but not resubmitted with changes
    folded in). Suresh has been working with the IESG members to remove 
    ambiguities and clarify text in the terminology draft. As soon as the 
    draft clears its way, other should follow right along.

Pyda Srisuresh -  "Agenda change"

  Offline meeting with the Tony Hain, the author of the IAB NAT draft
  will result in Tony making a new revision of this draft.  This new 
  copy of the draft will be discussed in the next meeting, if necessary.  
  We hope, issues are discussed over the mailing list and the draft 
  goes through WG last call much before the next IETF, so we dont
  have to pursue this until the next IETF.

    [Tony Hain - If anyone has comments, please send them]

    [Brian Carpenter - Can Tony tell us the date for the 04 draft?]

	             [Tony Hain - April 2]

    [Brian Carpenter - We'd like to get any gut feelings out of this draft 
		       and try to make it more objective.  This should 
		       become a draft that we all agree on, instead of 
		       an IAB or NAT authored draft.]

		     [Pyda Srisuresh - Yes, I fully agree with Brian's 
			       comments. We do like to have a single 
			       IAB/NAT-WG draft that people could refer.]

    [Matt Holdrege - There is a significant positive difference in 03.
		     The review was mostly intended to remove some
		     ambiguities, so readings of 03 might bring up
		     problems which have already been solved.]

Matt Holdrege  - "Protocol Complications"

  Little input has come back from this group.  Matt has sent a note
  to all WG and BOF chairs requesting input and specific
  complications.  Very little information was returned.  This 
  needs to become an RFC

    [???? - Which protocols have we already heard from?]

	     The draft shows which protocols we have already looked
	     at and found problems with.

	     Matt may look through protocols as he can to find
	     possible problems.

    Before the next rev of this draft, Matt will be working on
    reorganizing the draft to make it more organized and readable.

    [Danny Raz - Can we make a list of protocols which have been
	         known to be working with NATs?]

	     In theory, this is a good idea.  In practice, it will be
	     nearly impossible.  It is very hard to actually say that
	     something _certainly_ works with NAT, given obscure
	     options, etc.

	     This will be taken under advisement.

    [Brian Carpenter - We could add a disclaimer to cover liability.
	               Many of the protocols belong to currently dead WGs.  
		       Other areas might not even imagine that they might 
		       need to respond to such a request, as they might 
		       not see how NAT might be used with them. eg: BGP4]

  Comments?

Pyda Srisuresh - "NAT Friendly application design guidelines"
<Suresh will be representing Daniel Senie, who could not be present
 for the meeting.  Issues will be forwarded to Daniel if necessary.>

  Questions?

    [Dan Raz - Plans for NAT friendly evangelism outside this document?]

	     No.  Only to present the guidelines.

  If anyone feels like this draft does not address any issues that
  particular protocols might have, we'd like to hear about them.

  One of the issues might be that Address bindings are not guaranteed
  to last in NAT after the session that used the binding has terminated.  
  Some applications such as RSVP require that the Binding parameters be 
  kept alive, even after the session that caused the binding to originate 
  has gone away. This could be a sticky problem area - Are there many such
  applications ??

  But for a few nits, the draft does not seem to have any issues left 
  and may be ready to move forward.

  More comments?

    [Rhandeev Singh - DNS lookups?  Should the application cache these
		      lookups, or always do the lookup?]

		      The application should do the DNS lookups, but not
		      cache the results longer than is advised in the
		      response. DNS-ALG will set the responses to be 
		      valid for no longer than a second for dynamic
		      address bindings.

Dan Raz - "SNMP-ALG"

    The problem

      o Two or more private networks use the same address space.
      o A single management station is expected to manage
	both of them.
      o Occurs during mergers and with network service providers

    Constraints

      o Local networks cannot be reconfigured
      o No changes to NM software
      o Transparent to both NM application and to network elements
      o SNMP Proxies require reconfiguration of the local network and
	possibly NM software changes.

	These proxies are intended to support elements which do not
	have an agent.

    Solution

      NAT between n-1 overlapping networks and the NM station

    Issues

      o Can this be done using only per-packet information

        Currently everyone has standarized on using UDP under SNMP.
        TCP is possible, but not currently supported.

      o Private MIB and non-standard encoding

        When the variables contain address information, then we need
        to translate those addresses.

	IP address type is the standard way to encapsulate IP
	addresses, but we often see private encapsulations of those
	addresses.

      o Performance

        There is much work that needs to be done to parse the SNMP
        packets.

      o IP addresses are used as an index to MIB tables

    Basic NAT-SNMP-ALG

      o Translate only PDUs from network elements to manager (they
	have the data).

      o Translate only standard IP address type encoding

      o Does not change packet length and OIDs

      o May be insufficient for some applications

      [Thomas Narten - This doesn't work if you dont have the same number 
		       of global addresses as the number of machines you 
		       need to manage.]

	       Correct.  This is meant to be static.

      [Pyda Srisuresh - I believe, the requirement is simply that Whoever 
			is assigning the mapping addresses for the various
			private networks needs to ensure that managed 
			address do not overlap. These neednt be globally
			unique.]

      [Thomas Narten - I cannot see why a network manager would want this.]

      [Bernard Aboba - I'm confused as to what you're trying to manage.]

	       The situation at hand is a real world case, and is a
	       real world requirement from network managers.
      	       This application reduces cost

      [Thomas Narten - The information is now hidden and the network is now
	               much more difficult to manage.]

	       This doesn't necessarily help manage, it works for
	       situations where we could do nothing else.

      [Bernard Aboba - Write an SNMP proxy.  It is easier than NAT.]

      [??? - won't work for SNMPv3]

	       Yes it will.

      [Others - Explain nature of v3 authentication and hence cite the
		reason why SNMPv3 wouldnt work with this solution]

	       It will if the ALG has access to SA keys - The ALG
	       can get this from the SNMP application.

      [Thomas Narten - Same as IPsec end-to-end versus concatenated tunnels.]

               The keys are still within a single organization.

      [??? - Assume that all NATs are run by the same organization.]

      [Matt Holdrege - Since this is a problem specific solution, this
		       should be Informational.]

		       Yes.

      [Tony Hain - The applicability statement should be very strong
		   to show that it will not work in all situations.]

      [Steve Deering - Doesn't the proxy provide a better solution?]

	       No, that requires network reconfiguration.

      [Brian Carpenter - The proxy would take the load off the normal packet
	                 processor, thus providing added advantage.]

      	       The NM software gets confused with a proxy.

      [George Tsirtsis - A proxy can always be used in place of an
			 ALG, but the ALG makes more sense in some
			 cases.]

      [Brian Carpenter - The management station should be reconfigured to 
			 become NAT aware.  Without this, there is no way 
			 to clearly visualize the network.]

	       Manufacturers of this software are looking to NAT to
	       solve this as they don't want to rework their own code.

      [Matt Holdrege - This discussion should be moved to the list.]

Michael Borella - "Realm Specific IP (RSIP) protocol Specification"

    o Generalization and extension of HostNAT/DNAT

  How many have read the draft?  [more than 10] Not bad

  Security

    o As RSIP is currently defined, spoofing can be used for denial of
      service.

    o RSIP should eventually include authentication

    We're looking for feedback on these security isssues.

  [Pyda Srisuresh - Are these issues you raise different from that of
		    of a DHCP protocol?]

		No. Same issues exist in DHCP as well.

  Problems which RSIP doesn't solve

    TCP TIME-WAIT

      o Policy fix at RSIP server

    NAT problems

      DNS
      ICMP requires memory
      External access to local services

    [Bernard Aboba - This doesn't seem to work for IPsec tunnel mode for more
	     than one host at a time.]

	    [Unless you have a table of SPIs, you wont be able to demux]

	     Yes

    [Tony Hain - Make sure this is addressed]

    [Pyda Srisuresh - Why is TCP TIME-WAIT a problem?]

    [Thomas Narten - Problem with generic NAT, or is it induced by RSIP?]

	Listed this as an issue because it was mentioned in the IAB draft.

    [Timothy Shepard - ICMP issue]

	     Need some memory to properly send pings through

  Feedback needed

    o Comments on the whole idea
    o Evaluation of messages and parameters (too few, too many)

      Is the protocol too complex, or is it lacking in certain areas

    o End to end security

      Will be submitting a draft on how to run end to end IPsec
      through RSIP.

    [Gabriel Montenegro - Will the SPI be the demuxer?]

	     Yes.

    [Gabriel Montenegro - I have NAR draft out that addresses this and 
			 can be used as a basis for this area.  The 
			 old draft has already had some scrutiny from
			 IPsec folks in the last IETF meeting.]

    [Gabriel Montenegro - Why not use SOCKS as the base and add 
			  extensions to supports the RSIP protocol?]

    [Bernard Aboba - Concern about similarity between this and other
	             protocols.  How can we evaluate this against other
	             alternatives?]

	     Will be addressed in architecture draft

    [Brian Carpenter - RSIP is one solution.  We could really use 
		       Map-and-Encap in order to compare.]

  IPv6 Transition

    RSIP could be used for V6 transition such that IPv4 addresses are
    assigned to IPv6/v4 hosts.  This could be explored in future versions 
    of the draft.

    [Pyda Srisuresh - The main goal of the draft must be to address 
	      Private-v4<=>Public-v4 issues adequately. Subsequent to 
	      that, you could work on making it extentsible to other 
	      areas, including IPv6 transition]

    [Pyda Srisuresh - Can the server notify the client?]

	     Yes, to invalidate parameters.

    [Pyda Srisuresh - Doesn't look like unsolicited messages are covered here.]

	     Not explicitly at this time.

    [Pyda Srisuresh - Why does a node need to ask for multiple addresses
	              at a time?]

	     Basic-NAT environment where we might need a distribution of 
	     a sub-pool of addresses.

    [Pyda Srisuresh - You mean allocation between servers?]

	     Yes. The server should be able to act as a client to get
	     multiple addresses.

    [Pyda Srisuresh - This seems confusing and can lead to misconfigurations.]

    [Pyda Srisuresh - On a different note, Address request and port requests 
		      should not be separate, when a host is requesting for 
		      a tuple of (IP Address, TU port).]

	     Request for address is combined with a request for a
	     block of ports - for extensibility.

    [Pyda Srisuresh - The protocol does not seem to take into account domains
	      that are supported by Multiple NATs.]

	     Two RSIP routers for the same client?  Is this realistic?

    [Pyda Srisuresh - Yes]

    [Pyda Srisuresh - Why do we need to consider twice-NAT?]

	     Twice NAT mentioned for completeness sake. 
	     Expresses desire to move the draft forward for the common
	     case.  Scope can be narrowed to accomplish this

    [Pyda Srisuresh - You need to include bi-directional NAT.]

	     Yes, we will include that.

    [Pyda Srisuresh - DNS needs to be discussed as well in conjunction with
	              Bi-directional NAT.]

	     Yes.

Jeffrey Lo - "RSIP Framework"

  Brief discussion of how RSIP actually works.

  Comments?

  RSIP Protocol

    o Lightweight negotiation of arbitrary parameters.
    o Messages and parameter formats allow extensibility beyond the
      current specification.

  RSIP Protocol Phases

    o Registration

      RSIP server becomes aware of an RSIP client, and assignes a
      client ID ant tunnel type.

    o Assignments

    o Transport

    [Pyda Srisuresh - Isnt sequence number you use simply a message ID
		      for message request and response correlation?]
		Yes.

    [Pyda Srisuresh - Then, simply call it Message-ID, so it is less 
		      confusing]

    [Pyda Srisuresh - Is the framework document discussing protocol issues?]

	     [Michael Borella - the framework document presents the problem 
				that RSIP is trying to solve.]

    [Pyda Srisuresh - Framework doc should consist only of requirements,
                      scope and applicability. It may be referenced by 
		      the protocol document.]

    [Pyda Srisuresh - A good area to mention in the framework draft is
	              whether applications would be affected, or only 
		      the protocol stack.]

    [Rhandeev Singh - Are you saying that we can do away with the DNS ALG?]

	     [Michael Borella - Not at this time.]

    o Freeing

      [Pyda Srisuresh - Is this something that the application does?  
			It is not clear that the stack can do this.]

	       This needs to be studied.

      [ed- Further discussion and bickering on location of this
	   protocol (stack vs. application), socks, ...]

    o Renewing
    o De-registration

  Messages and Parameters
  Parameter List
  Errors

  More comments?

  [Pyda Srisuresh - Security Considerations seems to imply that the server
	     should be a traffic cop for traffic generated by RSIP
	     clients.  The original intent was for RSIP clients to be able
	     to take part in end-to-end IPsec.  The traffic cop defeats 
	     this purpose.]

  More on the mailing list

Rhandeev Singh

  IP relocation through twice network address trnalators

  Originally presented at mobileip WG

  Is intended to be a bootstrap for mobileip.  NAT is proposed for a
  quick-fix for initial deployment.

  RAT and MobileIP Comparision

    Relocation (Mobile-IP and RAT)
    Seamless mobility (Mobile IP)

      [Thomas Narten - What do you mean by this?]

	       RAT doesn't allow you to keep your connections as your
	       address changes.

      [Steve Bellovin - Why not use tunnel mode IPsec, which provides
			seamless mobility?]

      This is not intended as a replacement for MobileIP, but merely
      to give people experience with mobility

    Route Optimization (Mobile IP)
    E2E Layer 3 Security (Mobile IP)
    Immediate Utility (RAT)

  Issues

    o ALG requirements

      Needed when applications don't work correctly.  Free versions of
      ALGs are encouraged to be shared.

    o Application Scenarios

      When is RAT most applicable?

    o VPN-like connectivity
    o FIREWALL traversal

      RAT-to-RAT tunneling across firewalls?

      [Pyda Srisuresh  - Concerns about using RAT for mobileip.  
			 Introductory section should be clear on what 
			 the advantage/motive is for using RAT.]

    o PRIVATE home addresses
    o RSIP enabling

     [Pyda Srisuresh - What do you mean by a RAT device, and how does it 
		      relate to twice-NAT?  We need an architectural 
		      description of what goes into a RAT device.]

	     Zero-knowledge will register with registration server.
	     Registration server will the send configuration
	     information to the RAT device (Twice NAT box).

     [Pyda Srisuresh - How does the HA talk with the RAT device?]

	     RAT box will intercept packets from the Correspondent
	     Node and NAT them on their way to the Zero-knowledge
	     Mobile Node.

     [Pyda Srisuresh - Is the RAT device doing the equivalent job as 
		       the Foreign Agent?]

	     It looks more like a Home Agent than a Foreign agent.

     [Steve Deering - Traffic from Correspondent to Mobile Node undergoes 
		      Twice NAT?]

	   Only for Correspondent -> Mobile Node sessions.  Sessions
	   in the other direction are not translated at all.

     [Brian Carpenter - How did the MobileIP group respond to this?]

	   Pretty much ignored.

     [Hillary Orman - This seems more comparable to IPsec tunnel mode.]

		    Yes, but nobody is shipping it.

     [Steve Bellovin - Lots of demand and implementations are emerging
		    soon after the IPsec RFCs have come out.]

		    So, we're seeing a lack of support for RAT because
		    IPsec gives us the functionality?

		   [ed- implied general consensus]

     [Brian Carpenter - Many large coorporations have already rolled out 
		     tunneling solutions.]

	   The purpose of RAT/MobileIP is to provide mobility.

     [George Tsirtsis - This tries to address something between roaming
		     and mobility.]

  No changes are required to Mobile Nodes.  The RAT box instantly
  provides all functionality even to legacy hosts.

  [Steve Deering - This seems ironic, as it uses NAT to help outisders to
	   reach a global address.]

  [Brian Carpenter - Since the time that MobileIP has started, we have 
		     given up on having fixed addresses.  Too many hosts 
		     are forced to use private addresses.

Matt Holdrege

  Other issues?

  Adjourned

-
To unsubscribe, email [email-masked]' with
'unsubscribe nat' in the body of the message.