Subject: Re: [Ipsec] Fwd: Re: Two IKEv2 issues from the IESG

From: Ravi Kumar <[email-masked]>
Date: Tue, 07 Sep 2004 11:06:31 +0530

Hi,
      I agree with Thomos. SHOULD is not strong enough.
      I also feel that, introducing notification message to 
indicate the capability of Maximum size it can receive is 
also not good enough. What can sender do if that happens, 
other than logging this? Run IKE over TCP Or use HASH & URL?
      Unfortunatley, both are 'MAY'.

      In my opinion, mandating 3000 bytes, if IKE implements 
certificates will solve most of deployment problems. By 
doing this, all implementations are forced to make the change.

   Regards
   Ravi

----- Original Message -----
From: "Tero Kivinen" <[email-masked]>
To: "Thomas Narten" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; "Russ 
Housley" <[email-masked]>
Sent: Monday, September 06, 2004 1:38 AM
Subject: Re: [Ipsec] Fwd: Re: Two IKEv2 issues from the IESG

 > Thomas Narten writes:
 > > Um, aren't IKE and IPsec for communication between 
random hosts? True,
 > > most deployment to date has been VPNs. But are we 
resigning ourselves
 > > to that scenario forever? I hope not.
 >
 > I do not think we are planning only for VPNs. We should 
have options
 > also for other uses too.
 >
 > > I agree with this, but do not agree that this implies 
that whoever is
 > > in charge of setting up the trust relationships is in a 
position to
 > > know (or ensure) that all the possible IKE participants 
will accept
 > > adequately large payloads beyound those _required_ (in 
the MUST sense)
 > > by the spec.
 >
 > Then they assume 1280, and that is fine also.
 >
 > > Note: my real concern is that SHOULD is not strong 
enough. If it is
 > > not a MUST requirement that 3000 bytes (or whatever the 
right minimum
 > > lower bound is) be supported, we will eventually, once 
there is
 > > widespread deployment of IKE, run into a deployed base 
where some
 > > implementations only support the required minimum. At 
that point,
 > > implementations will (for interoperability) have to 
assume that the
 > > 3000 byte SHOULD is not universally implemented, and 
use the real
 > > lower bound (e.g., 1280).
 >
 > For those people who will implement the stuff over 
operating system
 > UDP stack, adding support for 3000 byte packets will be 
3-bit change
 > in their source code (i.e. change unsigned char 
udp_read_buffer[1280]
 > to unsigned char udp_read_buffer[3000] :-). This means 
that if we have
 > that bigger number as SHOULD all those implementors will 
simply use
 > the 3000 bytes, and forget the who thing. If we do not 
have any SHOULD
 > number in the RFC, they will start thinking (bad thing 
you know), and
 > they end up having random number between 1280 and 64k, with
 > distribution where you have about 40% using 1280, and 20% 
using 64k,
 > and rest of the 40% use values 1500/2048/3000/4096/8192.
 >
 > Effectively the SHOULD will most likely limit 
implementations so that
 > almost none does more than 3000 bytes...
 >
 > > If the WG feels that 1280 is really an adequate number 
to assume in
 > > the general case, I'm fine with that.
 >
 > Good.
 >
 > > My point is that the SHOULD recommendation is probably 
less useful
 > > than might seem.
 >
 > I think the SHOULD do have good reasons to be there, as 
it will be
 > hard number for implementors. And we can benefit from 
that number when
 > we defined the extension telling that number to the other 
end.
 >
 > > If this will eventually be needed, now is the time to 
do it, before
 > > there is a deployed base. It is the deployed base 
(which won't
 > > implement this) that will be the problem in the future 
(if it becomes
 > > a problem).
 >
 > The extension would be quite easy. I think we do not want 
to add it to
 > the IKEv2 spec at this point, but create separate 
extension about
 > this. On the other hand if you feel that we should do it 
now to
 > resolve the max UDP packet size problems, then we can 
still do it if
 > IESG and area directors approve the change.
 >
 > The text could be something like:
 > 
----------------------------------------------------------------------
 > ...
 >         NOTIFY MESSAGES - STATUS TYPES           Value
 >         ------------------------------           -----
 > ...
 >         MAX_UDP_IKE_PACKET                       XXXXX
 >
 >             This notification asserts that the sending 
endpoint is
 >             capable of receiving UDP packets up to given 
size. The
 >             data associated with a MAX_UDP_IKE_PACKET 
notification
 >             MUST be 4 octets long and contain the big endian
 >             representation of the max UDP IKE packet size 
(i.e. size
 >             without IP or UDP headers) the sender 
promises to be able
 >             to receive. This notification SHOULD be sent 
inside the
 >             IKE_SA_INIT exchange so the initiator can use 
the bigger
 >             packet size when sending the IKE_AUTH 
exchange containing
 >             certificates.
 > --
 > [email-masked]
 >
 > _______________________________________________
 > Ipsec mailing list
 > [email-masked]
 > https://www1.ietf.org/mailman/listinfo/ipsec

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

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 7 Sep 2004 12:05:21 +0300

>       Unfortunatley, both are 'MAY'.

TCP is not MAY, it is not defined.

HASH & URL is MUST. So it can also simply leave out certificates and
send HASH and URL instead, and assume that the other end will either
get those certificates from there, or then the authentication will
fail. Note, that 1280 bytes is enough for sending the normal end user
certificate, so actually the sender can send his own end user
certificate and hash and urls for the sub-CA certificates. If the
other end did actually have the same top-CA configured, he proboably
also have some knowledge of where to get the sub-CAs for that CA
too... 

> doing this, all implementations are forced to make the change.

3000 bytes still does not solve the problem. It will make it so that
after that the sender can send 2 big certificates, but what if the
hiearchy is 8 levels deep? 1280 bytes works for end user certificates,
3000 bytes works for about 2-3 level deep hiearchy. 8000 will work for
8 level hiearchy etc.
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 7 Sep 2004 12:05:21 +0300

---

From: Ravi Kumar <[email-masked]>
Date: Thu, 09 Sep 2004 10:58:08 +0530

Yes. I went through IKEv2 document version 15. It did indicate
HASH & URL is MUST.  I feel, this is very strong statement.

I feel mandating 3000 byte for one level certificate 
hierarchy and
8K for multiple certificate hierarchy would be better and 
simple.

Regards,
-Ravi