Subject: (NAT) NAT WG minutes from Oslo

From: Matt Holdrege <[email-masked]>
Date: Wed, 04 Aug 1999 12:47:54 -0700

Below are the minutes from our meeting. Please let me know if there are any 
errors.

NAT WG - Oslo - Tuesday, July 13th

Chair: 	Matt Holdrege <[email-masked]>
Reported by 	Gabriel Montenegro <[email-masked]>
		George Tsirtsis <[email-masked]>

agenda bashing - The Agenda was accepted

Milestone status
The NAT Terminology and Considerations draft was approved by the IESG and 
will soon receive an RFC number. This is a very important document as it 
describes the terms that all IETF documents should use when discussing NAT.

Other drafts in the works are...
dns-alg draft
traditional nat
nat api
security for nat domains
nat friendly app designs
hnat
snmp alg
rsip (framework, protocol, ipsec)

Each can be found on the IETF NAT WG web page.

There is some delay in the milestones due to the extensive review of the 
NAT terminology draft.

Protocol Complications - Matt Holdrege - 
draft-ietf-protocol-complications-01.txt

The updated draft is available on the IETF web site.

Matt solicited input from NAT WG and all other WG chairs but has not 
received a lot of feedback. We need to understand which applications do not 
work with NAT including non-IETF applications. (vendor specific etc).

- There is a suggestion to make this Informational RFC shell and put the 
text on the Web so it can be updated

- Someone pointed out that Web - RFC links may be unstable so RFC should be 
stable and self contained

- The Weird WG is trying to put all RFCs in Web Form, NAT could be a pilot 
project

- Matt wants to make the ITU and other external bodies aware of this 
document so IP technology developed outside the IETF can consider NAT.

- Matt also is thinking about more than the general usage of NAT. The 
typical use: home user going out to global internet (1 nat) and back into a 
corporation (2nd nat).

Vern said that the doc should be as self-contained as possible.

RSIP - Mike Borella <[email-masked]>
Three RSIP drafts exist. A framework document , the RSIP protocols 
specification and RSIP interactions with IPSEC document. 
draft-ietf-nat-rsip-protocol-01.txt, draft-ietf-nat-rsip-framework-01.txt, 
draft-ietf-nat-rsip-ipsec-00.txt

Framework Document

Public Internet to private intranet connections need to be studied further.
George Tsirtsis: May want to look at DSTM and NAT-PT in NGTRANS WGs that 
study a similar problem.
.
Overview of RSIP operation
The draft talks about the context, scoping and philosophy of RSIP and 
discusses different methods, pros and cons.

There is added talk of demultiplexing beyond port numbers, subnet query 
pros and cons for determining locality of location.

Next steps

Move TCP TIME_WAIT, ICMP and DNS from protocol draft into framework

Add section on external access to internal servers

Mike's suggestions for future:
make choices and nail down stuff in framework

More security considerations

Distinguish between client-server application (much easier) and
supporting external access to internal servers (more complicated)

George Tsirtsis - look at what ngtrans is doing for v6 to v4 mechanisms

The RSIP Protocol

Local Authentication needs more work/feedback
An example has been added in the anex

Need to extend error messages

Issues
- Transport for RSIP: now has its own port number but could go over 
SHOCKs/DHCP/IPCP

- Brian Carpenter: to clarify this is about transport of RSIP signalling 
and not data after address allocation. Many people have not used TCP only 
to realise later that TCP is a good idea after all because of reliability. 
etc. Mike also agrees.

- BIND messages for local servers. Needed but not sure how it is going to 
be implement in different scenarios

- Client state diagram
Someone asked could you dislocate RSIP server from gateway router? This way 
multihoming will become easier. Mike: Yes but it is too complex.

The end of the protocol draft lists the changes:

We discussed an appendix with protocol example with negotiation example, 
and addr and port resource error messages.

We are starting to gain implementation experience, and gain in 
understanding of
what's needed. This means there will be changes to this part of the spec

We can implement a NAT function as a complement coexisting with rsip server

We must decide on transport for the RSIP signalling: socks/dhcp/ipcp/port?
reliable/unreliable (TCP/UDP)?

Brian Carpenter - TCP is a good choice

Mike: yes, TCP and authentication

BIND msgs for local servers?
not needed for road warrior perhaps for home networks

Client state diagram
mike's adding this to the draft

Someone: why not separating the router from the rsip server box?
Gabriel responded later that this separation would benefit from allowing 
the rsip client to express not only that it needs a tuple (address, port, 
spi, etc), but also to express what the intended peer of this session will 
be (a la nar/socks)

IPSEC draft
This is a combination of 3com work and Gabriel Montenegro's/sun (NAR draft)
This extends RSIP to support IPSEC. No change required in IPSEC.

Client and server agree on initiator cookie and spi

Future issues

e2e security model and assumptions
Policy integration
Host with some policy
Plug into a network with policy
Mild violation of cookie creation, mild violation of 2408 sec 2.5.3

To avoid socket collisions, clients should/must also allocate port numbers 
in additions to the SPI.

IKE: use initiator cookie as demultiplexer

ESP: use incoming spi

We are soliciting input as we revise these drafts

Discussion on Mobile IP support
some drafts that talk about this are:
http://search.ietf.org/internet-drafts/draft-ietf-mobileip-privaddr-00.txt
http://search.ietf.org/internet-drafts/draft-teoyli-mobileip-mvpn-02.txt

General Discussion:

Mike: All drafts are being revised. If people have strong opinions now its 
time to contribute

- Someone said that RSIP is kernel level and may not work with Raw sockets.
Matt: virtual sockets with an abstraction layer could be used to handle raw 
sockets.

- Someone asked: What interactions you have with Mobile IP?
Mike: a document was written 1.5 years ago but needs to be revisited.

Gabriel: RAT may also have interactions; NAR (predecessor of RSIP) studies 
both mobility and security so, could be used as reference. An other 
document also exists dealing with private addresses and mobile IP.

- Brian Carpenter asked: Does RSIP requires other things to be changed 
(e.g: DNS) Is there a roadmap for the future of this work?

Matt: Roadmap will need input from others (IAB?).

Gabriel: Need to separate RSIP of the future from RSIP of now that we need 
for Home Networks etc. Definitely need to work more on Security and already 
work with Security people. Incoming connections and multiple RSIP gateways 
are also future work items.

Matt: RSIP for now may need to be made more robust to deal with RSIPxN 
situations.

Gabriel: Agree but RSIP may already be too big (according to NITS BOF 
people) so we need to allow people to implement only parts of it for what 
they are doing.

- Matt: RSIP is not specifically in the WG charter but has been worked on 
here and it may be better to keep it in NAT WG for now until IAB or IESG 
can give us more directions.

Steve Bellovin: No more direction is likely to come out of IAB, further to 
what was given in the network layer BOF. You should understand what needs 
to be done for the general case and do it. Do not wait for someone to give 
you the go ahead.

Conclusion: RSIP will remain in the NAT WG for now

5. NAT Transport - Carmelo Zaccone - draft-zaccone-nat-transport-00.txt
Access to Multiple ISPs is a problem and the tunneling approach has drawbacks
This work attempts to identify ways to do this without tunneling
Possible approaches:
- Turn PC into Router running OSPF (minimum implementation)
- Use multicast to advertise unicast addresses via trees rooted in the host
- Reverse path creation with RSVP

Discussion: clarification questions on the different mechanisms, 
scalability etc.
Mike: Problem space is valid but solutions seams too complex. Are there any 
alternatives?
Discussion to continue on the mailing list

6. AOB
None. Meeting dismissed.

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