Subject: Re: destination option update

From: Erik Nordmark <[email-masked]>
Date: Wed, 10 Jan 2001 19:18:13 -0800 (PST)

Back from vacation and travel ...

> 	one question - maybe i have lost some context.
> 	we are talking about socket API.  is it really necessary
> 	for user applications to be able to transmit arbitrary AH/ESP/fragment
> 	header?

I don't see a need to allow this on the transmit side. But the discussion
started off with the need on the receive side to identify what headers was
covered by IPsec i.e. somehow be able to indentify what was before and
after an ESP header. I don't know if any application cares whether received
destination options appear before or after a fragmentation header.
Is there such a need?

  Erik

> 	even for raw IP socket, i think it reasonable to forbid users
> 	from attaching arbitrary AH/ESP/fragment header (i.e. to say that
> 	they are "kernel" thingie).
> 
> itojun

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Thu, 11 Jan 2001 13:18:50 +0900

>destination options appear before or after a fragmentation header.

	i believe there's such a need, but i'm not sure about granurality.
	this is not really about 2292, but about ipsec API in general.

	i came up with comple of scenarios:
	- i have a udp-based server running.  i'd respond to incoming packet
	  if it comes with AH/ESP, and i'd reject it if it is not IPsec'ed.
	  (what granurality?  do we need to if extension headers were
	  protected?)
	- i am implementing some of mobile-ip6 portion in the userland.
	  i would like to know which intermediate header was protected and
	  which was not, by ESP.  this is in 2292 domain.
	  (AH protects the whole packet so there should be problem)
	- i have a telnetd running on my server.  i'd like to allow plaintext
	  password if the tcp session is IPsec-encrypted, and i'd like to
	  require s/key otherwise.  how can we do this?
	  with draft-mcdonald-simple-ipsec-api-01, we'd need to listen to
	  two separate ports, for separate protection policy.
	  (again, for tcp, "which packet was protected and which was not"
	  complicates story)

	are there any ipsec socket API (not key management API) proposal other
	than draft-mcdonald-simple-ipsec-api-01?  if there's any standard/
	whatever i would like to know that. 

itojun

---

From: Francis Dupont <[email-masked]>
Date: Thu, 11 Jan 2001 12:26:30 +0100

In your previous mail you wrote:

   I don't know if any application cares whether received
   destination options appear before or after a fragmentation header.
   Is there such a need?
   
=> I can see both, symmetry (stronger than one can believe at the first
view because of the send what is received coding style) and security
issues with ESP (after ESP is protected, before ESP is *not*).
I think we should have this.

Thanks

[email-masked]