Subject: [Ipsec] HASH and URL

From: suren <[email-masked]>
Date: 31 Aug 2004 11:08:49 -0700

Hi,
   As I understand, the IKE node can send Hash of public key of 
   its certificate and URL (including port number) from which the peer
   can retrieve its certificate. I guess, it is to ensure that there is
   no fragmentation on IKE packets as some routers might not honor
   fragmentation. 

   I see that there would be firewall related issues in this. 
   Since, the IKE needs to make a new connection (HTTP connection) to
   the URI given in Cert payload, any firewalls in between should have 
   a policy (ACL) to allow this HTTP connection.

   This could be a deployment problem. The administrator of firewall
   need to create a ACL to allow all connections outbound.  
   This is one of the problem being faced by administrators on CRLDP
  (CRL Distribution point) too. At least in this case, the distribution
   points are smaller and in most cases deterministic and the
   administrator of firewalls can create appropriate policies
   statically.

   What do you think of this following proposal.
   - IKE Peer which receives Certificate payload always sends its 
     IP address and port as part of URL.  (Assumption here is that, 
     all services typically are allowed between IPSec Peers).
   - When the IKE node receives HTTP request, it could send HTTP
     Redirect to new URL, which could be outside its node.
   - IKE Peer is expected to use same source IP address and Port 
     (May be using REUSE address option in sockets) to connect to 
     new HTTP Server and Port. 
   - Since, most of firewalls support 'address binding' feature, 
     it should work.

Does this make sense? Comments?

Thanks
Suren
www.intoto.com

_______________________________________________
Ipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec

---

From: Michael Richardson <[email-masked]>
Date: Tue, 31 Aug 2004 14:41:28 -0400

-----BEGIN PGP SIGNED MESSAGE-----

I wonder if one solution to the problem of large IKE packets
(that require fragmentation) wouldn't be to define a fragmentation
header in IKE.

I.e. an IKEv2 payload which contains a sequence number, into which
     fragments of another IKEv2 payload could be placed.

     The sender would be responsible for making sure that all fragments
     get sent (since each would be ACK'ed in some way by the receiver).

The only problem that I see is that the original payload will need some
kind of response, and so I wonder whether or not to include the IKE
header as well as the payload.

Original packet:
	 IP UDP IKE-header SK{CERT, AUTH, stuff}

new packets:
	 IP UDP IKE-header SK{Frag#1{CERT....}}
	    <- IP UDP IKE-header SK{FragAck#1}}	    
	 IP UDP IKE-header SK{Frag#2{AUTH....}}
	    <- IP UDP IKE-header SK{FragAck#2}}	    
	 IP UDP IKE-header SK{Frag#3{stuff...}}
	    <- IP UDP IKE-header SK{FragAck#3, AUTH, stuff}}	    

or perhaps:
	 IP UDP IKE-header SK{Frag#1{IKE-header', CERT....}}
	    <- IP UDP IKE-header SK{FragAck#1}}	    
	 IP UDP IKE-header SK{Frag#2{AUTH....}}
	    <- IP UDP IKE-header SK{FragAck#2}}	    
	 IP UDP IKE-header SK{Frag#3{stuff...}}
	    <- IP UDP IKE-header SK{FragAck#3}
	    <- IP UDP IKE-header' SK{AUTH, stuff}

- --
]     "Elmo went to the wrong fundraiser" - The Simpson         |  firewalls  [
]   Michael Richardson,    Xelerance Corporation, Ottawa, ON    |net architect[
] [email-masked]      http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

---

From: Paul Koning <[email-masked]>
Date: Tue, 31 Aug 2004 15:00:35 -0400

>>>>> "Michael" == Michael Richardson <[email-masked]> writes:

 Michael> -----BEGIN PGP SIGNED MESSAGE----- I wonder if one solution
 Michael> to the problem of large IKE packets (that require
 Michael> fragmentation) wouldn't be to define a fragmentation header
 Michael> in IKE.

 Michael> I.e. an IKEv2 payload which contains a sequence number, into
 Michael> which fragments of another IKEv2 payload could be placed.

 Michael> The sender would be responsible for making sure that all
 Michael> fragments get sent (since each would be ACK'ed in some way
 Michael> by the receiver).

If we're not satisfied with how IP does fragmentation, wouldn't it be
more reasonable to use TCP -- which handles large packets the right
way?

I dislike inventing new protocols to address previously solved
problems. 

	paul

---

From: Michael Richardson <[email-masked]>
Date: Tue, 31 Aug 2004 15:11:33 -0400

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Paul" == Paul Koning <[email-masked]> writes:
    Michael> I.e. an IKEv2 payload which contains a sequence number,
    Michael> into which fragments of another IKEv2 payload could be
    Michael> placed.

    Paul> If we're not satisfied with how IP does fragmentation,
    Paul> wouldn't it be more reasonable to use TCP -- which handles
    Paul> large packets the right way?

  There are two problems with how IP does fragmentation, and they aren't
about IP itself.
      1) fragments are hard for firewalls to filter, so they get lost.
      2) fragment reassembly under fragment DOS is often not very
	 fruitful.

  (And then there is the IPv6 situation. IPv6 just tells you to do go
the right PMTU yourself, or fragment yourself. This method can get us
the PMTU)

    Paul> I dislike inventing new protocols to address previously solved
    Paul> problems.

  We could have an option to run over TCP.
  But, consider if one is doing IPsec in the first place to protect 
TCP management sessions. Ooops.

- --

---

From: Paul Koning <[email-masked]>
Date: Tue, 31 Aug 2004 15:40:51 -0400

>>>>> "Michael" == Michael Richardson <[email-masked]> writes:

 Paul> If we're not satisfied with how IP does fragmentation, wouldn't
 Paul> it be more reasonable to use TCP -- which handles large packets
 Paul> the right way?

 Michael> There are two problems with how IP does fragmentation, and
 Michael> they aren't about IP itself.  1) fragments are hard for
 Michael> firewalls to filter, so they get lost.  2) fragment
 Michael> reassembly under fragment DOS is often not very fruitful.

 Michael> (And then there is the IPv6 situation. IPv6 just tells you
 Michael> to do go the right PMTU yourself, or fragment yourself. This
 Michael> method can get us the PMTU)

True.

 Michael> We could have an option to run over TCP.  But, consider if
 Michael> one is doing IPsec in the first place to protect TCP
 Michael> management sessions. Ooops.

So?  That's no more an issue than it is for UDP.  A TCP IKE session
would not go through IPsec, just like port 500 UDPgrams don't use
IPsec. 

       paul

---

From: Dan McDonald <[email-masked]>
Date: Tue, 31 Aug 2004 16:06:27 -0400

>       1) fragments are hard for firewalls to filter, so they get lost.

Can't modern firewalls tag the initial segment's ID, and let matching IDs
through?  I know there's packet reordering and implementations that send the
last fragment first, but the former is relatively rare, and the latter can be
fixed.

> the right PMTU yourself, or fragment yourself. This method can get us

And IPv4 can be configured to act just like IPv6 in this regard.  Our IP, for
example, sets the DF bit by default on outbound packets.

>     Paul> I dislike inventing new protocols to address previously solved

I agree with Paul 100%.  Let's not reinvent the wheel more than we have to in
IKEv2.

Dan

---

From: Michael Richardson <[email-masked]>
Date: Tue, 31 Aug 2004 16:23:25 -0400

-----BEGIN PGP SIGNED MESSAGE-----

    Paul> So?  That's no more an issue than it is for UDP.  A TCP IKE
    Paul> session would not go through IPsec, just like port 500
    Paul> UDPgrams don't use IPsec.

  But, they would be vulnerable to the TCP RST attacks that we might in 
fact trying to defend against in the first place.

- --

---

From: Michael Richardson <[email-masked]>
Date: Tue, 31 Aug 2004 16:38:10 -0400

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Dan" == Dan McDonald <[email-masked]> writes:
    Dan> Can't modern firewalls tag the initial segment's ID, and let
    Dan> matching IDs through?  I know there's packet reordering and
    Dan> implementations that send the last fragment first, but the
    Dan> former is relatively rare, and the latter can be fixed.

  Yes, modern firewalls do all of this.

  But, consumer grade DSL sharing devices, and multiple "cheap" DSLAM
boxes that provide for "virus protection" do not do this.

  My experience is that neither side of the IPsec connection was in
control of these boxes, often unaware of them, and worse -- the ISPs
themselves were often ignorant of them.

  IKEv1 PSK will work fine, or RSA without CERTREQ/CERT, but not with
the CERT in place.

    Dan> And IPv4 can be configured to act just like IPv6 in this
    Dan> regard.  Our IP, for example, sets the DF bit by default on
    Dan> outbound packets.

    Dan> I agree with Paul 100%.  Let's not reinvent the wheel more than
    Dan> we have to in IKEv2.
  
  I agree. I'd rather use TCP. I don't think it is practical to do that.
  (remember, that I'd prefer never to send the certificates in-band at all...)

- --

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Tue, 31 Aug 2004 16:23:27 -0700

It would be a lot easier for those of us who think "let's not 
re-invent TCP in IKEv2" to know what you are talking about if we had 
an Internet Draft will your full proposal for the fragment handling. 
Without that, we'll just keep saying "it's too hard, and it's not 
important enough" and you'll keep saying "it really isn't, and it is 
important".

--Paul Hoffman, Director
--VPN Consortium

---

From: Michael Richardson <[email-masked]>
Date: Tue, 31 Aug 2004 19:59:52 -0400

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "VPNC" == VPNC  <Paul> writes:
    VPNC> It would be a lot easier for those of us who think "let's not
    VPNC> re-invent TCP in IKEv2" to know what you are talking about if
    VPNC> we had an Internet Draft will your full proposal for the
    VPNC> fragment handling. Without that, we'll just keep saying "it's
    VPNC> too hard, and it's not important enough" and you'll keep
    VPNC> saying "it really isn't, and it is important".

  Remember, that I'm the guy who thinks that one of the reasons that 
certificates shouldn't be exchanged in-band is because of problems like
this :-)
  I do, however, hate PSK, and want it to go away, so if solving this
problem makes progress, then I'm willing to help.

  I twigged on this after reading parts of the last month of the
pki4ipsec list, and started to think about it in the shower or
something.

  I would be happy to write a document --- but others need to say, "yes,
solving the cert too-big-for-MTU is important".

- --