Subject: (NAT) Recommended reading - drafts

From: Robert Moskowitz <[email-masked]>
Date: Fri, 25 Feb 2000 10:28:04 -0500

I have been a NAT lurker for some time.  I am now delurking.

I have discussed bringing up the following with the co-chairs and ADs:

In Dec '98 I started out studying why IPsec was not delivering security 
services to the protocols that needed privacy and/or authentication.  My 
first opinion was it took too long; later I realized that a fundamental 
design of IP was central to IPsec and NAT's complexity.  That is the 
confounding of naming and routing.  I set out to design a namespace that 
would decouple the internetworking and transport layers (BTW, I am on the 
IRTF NSRG).  The current result is documented in my Host Identity Payload 
drafts:

  http://www.ietf.org/internet-drafts/draft-moskowitz-hip-arch-01.txt
  http://www.ietf.org/internet-drafts/draft-moskowitz-hip-01.txt
  http://www.ietf.org/internet-drafts/draft-moskowitz-hip-impl-00.txt

I will be the first to admit that these drafts need improvement in 
presentation.  But in brief, by creating a cryptographically based host 
namespace that is statistically globally unique with 3 representations, I 
am able to use ESP 'transport layer' in place of the internetworking layer 
(either IPv4 or IPv6) for the transport binding.

This provides NAT friendliness that boarders on transparency.  There is 
some specific DNS configuration issues to support this, and DNSSEC is 
recommended to address man-in-the-middle attacks.

HIP and its ESP can traverse any addressing realm boundaries; this includes 
IPv6/4 gateways, not just IPv4 NATs.

I can appreciate that this is radical thinking, but I ask that people here 
look over HIP and send me comments.  Has HIP met its goals?  Does it offer 
real end-to-end services?  Can it reduce the complexity in the network and 
even the end systems?

I am working on the next set of drafts.  I will not be in Adelaide, but 
might be able to get someone to present HIP at one of your sessions if 
there is interest.

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

---

From: Jim Bound <[email-masked]>
Date: Fri, 25 Feb 2000 14:09:58 -0500

Hi Bob,

>I have discussed bringing up the following with the co-chairs and ADs:

I think this discussion belongs in the IRTF for now and if in the IETF
in the end-to-end group.

>real end-to-end services?  Can it reduce the complexity in the network and 

I read all the drafts and the ones on ESP and DNS too.  First, I do not
agree with two of your base assumptions:

1.  That IP addresses do not identify nodes:

IN fact they do in mulitple instances (multiple addresses) I also think
it a good paradigm and the only problem is the lack of IPv4 address
space.  That is being addressed first with bandaids like NAT and RSIP.

THen eventually with the IETF's recommendation for IPng which is IPv6.
I believe there will be points of inflection for sure with IPv6 and the
band-aids.

2.  That IP addresses are not good identifiers for IPsec.  I think they
are very good and appropriate considering time-to-market, cost of
engineering, and ability to do the job.  Is it the most elegant NO.  But
will it work and suffice as an identifier yes (but I agree with Bruce
Schneier's IPsec Critique and the issues of designing by committee, but
again its all we got for now).

But to reiterate I think this work needs some prototyping and
implementation as a logic check.  You use the word IP kernel in the arch
draft and indirectly in the imp draft.  As a "real" IP kernel product
engineer and architect your words around the "virtual" layers I find
very high-level and messing with the TCB is very very tricky business.
IN fact that one aspect of HIP clearly belongs in IRTF or at a minimum
in the end-to-end group.

Do we really want to continue this discussion on the NAT list?

regards,
/jim
-

---

From: Robert Moskowitz <[email-masked]>
Date: Fri, 25 Feb 2000 14:39:16 -0500

>I think this discussion belongs in the IRTF for now and if in the IETF

It is in the NSRG IRTF.  I did not know that the IETF has an end-to-end 
workgroup.  I do know of one in the IRTF.

>space.  That is being addressed first with bandaids like NAT and RSIP.

IP addresses identify interfaces.  This is covered in Comer's book.  He 
shows it very clearly in his IP state manchine.

The lack of namespace size is not the only problem with IPv4.  A problem, 
or rather, an 'engineering comprimise', that it and IPv6 share is its 
hierarchical assignment strategy.  This puts a value on the 'names', and a 
history.  A valuable feature in a end point name is local creation and 
anonymity.  128 bits is large enough for this if all the bits are 
available; no routing information.

>I believe there will be points of inflection for sure with IPv6 and the

IPv6 serves a very important role, and HIP does not preclude it.  In fact 
HIP works equally well with v6 and provides for some interesting transition 
features.

>engineering, and ability to do the job.

Barely so.  Only for globally addressed devices.  For B2B in todays world 
it just doesn't work and the hacks are loaded on the hacks.  Jim, my 
company test these products and in general terms their success is 
poor.  Also most of today's products are solving a stop-gap problem: 
gateway2gateway.  Many corporate people that I talk to want end2end.

>Is it the most elegant NO.  But

My critique resonates to some degree with Bruce.  But for different 
reasons.  I am busy writing my monday morning quarterback report.

>implementation as a logic check.

Lots of agreement here.  But before much prototyping is done, there is a 
lot of value of getting good community input.

>You use the word IP kernel in the arch

Again, part of the reason for airing to a larger audience.  I HAVE 
discussed this with a few kernel architects; I've never claimed to be a 
system programmer.  Many parts of the docs are still high-level, needing 
good input to add detail.

Bringing this up in the IRTF's end2end makes sense, and I will approach Bob 
about it.  What is the IETF's wg you reference, so I can contact it's chair(s).

>Do we really want to continue this discussion on the NAT list?

I bring it up here, as there are NAT scenarios in the implementation 
document.  Given the way it provides mobility (I have also brought it up in 
MobileIP), it offers a certain elegance in NATs, be they v4-v4 or v4-v6 
devices.  Even IPv4-IPX (if anyone wanted to do that anymore, but i make 
the architectural point).

So that is why I approached the chairs.

-

---

From: Jim Bound <[email-masked]>
Date: Fri, 25 Feb 2000 15:35:33 -0500

Hi Bob,

>workgroup.  I do know of one in the IRTF.

Hmmm OK I thought that was part of the transport area?

>shows it very clearly in his IP state manchine.

I don't agree with Comers conclusion OK.  Here is excerpt from IPv6 RFC
2373 too:

2.1 Addressing Model

   IPv6 addresses of all types are assigned to interfaces, not nodes.
   An IPv6 unicast address refers to a single interface.  Since each
   interface belongs to a single node, any of that node's interfaces'
   unicast addresses may be used as an identifier for the node.

The point is that an address can identify a node.  Many existing
applications on the Internet also use it that way.  They are not going
to change.  The key is that each interface belongs to a single node.
This permits it to identify the node.  This is the point many IP pundits
miss which rfc2373 got right.

>available; no routing information.

This sounds like the old EID argument and you know I have been there and
this is definitely not a NAT topic or place to discuss IMO. 

>HIP works equally well with v6 and provides for some interesting transition 

HIP will not reach consensus or the light of day in the IETF unless well
qualified in scope.  It affects the base architecture of IP impelementation 
too, and why I think we need some proof of concept.  I have similar proposals 
of great affect to IP but I would not propose them without some implementation
experience if that can be found.

>gateway2gateway.  Many corporate people that I talk to want end2end.

I want end2end too.  

>reasons.  I am busy writing my monday morning quarterback report.

Fair answer.

>lot of value of getting good community input.

Thats a good point.

>good input to add detail.

My input to you is not talk to kernel architects but people who work
with real kernel code.   I am not saying this is impossible but I will
tell you the ramifications are as significant to what was done for IPv6
for impelementation.  Also one can't break whats running today and that
makes it even more complex.

Also a nit.  The TCB is just the tip of the iceburg.  The real issue
will be for the Protocol Control Block (PCB) and address resolution data
structures for node discovery lookups.  

I would make this transparent to the entire kernel and have it
discovered out of band in user space.  It should have nothing to do with
routing or tcp response paradigm or applicatiion notification as the
TCB is used for that too.  This way it works for UDP too.  Note there is
now equiv TCB for UDP!!!  

>about it.  What is the IETF's wg you reference, so I can contact it's chair(s).

I think your in the right Area under Scott and Vern.  But HIP affects
lots of stuff.  I would suggest first make sure the e2e principles are
agreed to then possibly its an operation issue.   Why not run it by the
Transport Area Directorate that way you get input from folks like Jeff
Mogul and Greg Misnshall and other bright folks who worry about e2e at
this level.

>the architectural point).

Anyway I will keep discussing whereever it is to be discussed so let me
know where that happens.  Its not I am against it I just think it needs
to be discussed.  I do fear the EID wars again and those never are
fruitful IMO.

/jim

-

---

From: Robert Moskowitz <[email-masked]>
Date: Fri, 25 Feb 2000 16:04:09 -0500

At 03:35 PM 2/25/2000 -0500, Jim Bound wrote:

perhaps a wrap on this little thread, and I thank you for your response, Jim.

> >workgroup.  I do know of one in the IRTF.

I looked again.  There is a transport area workgroup (tsvwg), which is a 
generalized wg in the transport area to take general topics.  Perhaps that 
is what you meant.

>miss which rfc2373 got right.

But it identifies the node in light of its place in the network.  that is 
where it got it wrong, imho.  And I think we both know that we probably 
cannot win the other over on this point.

>this is definitely not a NAT topic or place to discuss IMO.

It ties into EID, I was there too.  It is a NAT topic because the impact an 
EID can have on NATs.  When we had the last EID debate in '94 (the only one 
I really participated in), I don't think we had some of the knowledge we 
have now.  So within a framework, it may be worth revisiting.

>qualified in scope.

The next cut of the docs will attempt to do this.

>It affects the base architecture of IP impelementation
>too, and why I think we need some proof of concept.

Lining up some proof of concepters now.

>I have similar proposals

I know.

>with real kernel code.

Well, I did misspeak.  I am talking to people that do the coding.

>I am not saying this is impossible but I will

And part of what I need is did I break what is running now?

>structures for node discovery lookups.

thanks.

>TCB is used for that too.  This way it works for UDP too.  Note there is

actually it does work for UDP.  It is just that TCP has some bigger level 
violations.

I disagree about the user space.  Partly it is because the transports are 
what are attackable in their current form.

>Mogul and Greg Misnshall and other bright folks who worry about e2e at

I will follow up on this.

-

---

From: Jim Bound <[email-masked]>
Date: Fri, 25 Feb 2000 18:48:46 -0500

OK bob its a wrap.  I will review it more in depth and send it to you
privately.  As one who codes in the kernel land of IP too.  Pretty maxed now
so it will take me a few weeks to review it to that degree.

thanks
/jim
-