Subject: RE: Meeting's minutes

From: "Brian Swander" <[email-masked]>
Date: Tue, 14 Aug 2001 14:10:54 -0700

It is not any particular stack in general that we are worried about, but
the network in general dropping fragments.  For instance, some routers
with port filtering enabled will drop all subsequent fragments because
they don't want the expense of fragment tracking.  I may be wrong, but
this is what I thought the Cisco 11.x versions did, which is a very
common bit of network infrastructure.  It seems like people would want
to stop random UDP and fragmentation attacks from flooding their
networks, so that configuring routers to do fragment blocking may be
common.  This is one common scenario that will kill IKE for larger
packet sizes.  Telling customers to disable fragment blocking will
potentially open their networks up to other attacks, and they may not be
willing to take that risk.   Or perhaps going from fragment blocking to
fragment tracking will cause scalability issues on their routers, or
force hardware upgrades, etc.  All of these concerns are potential
barriers to IKE adoption.

So, if we can guarantee that IKE traffic will actually get to the peer
systems in question, then we can point the finger at that stack if it
fails to reassemble.  

How can we guarantee that the current networks will correctly deliver
our IKE fragments?

bs

-----Original Message-----
From: Dan Harkins [mailto:[email-masked]] 
Sent: Tuesday, August 14, 2001 12:03 PM
To: [email-masked]
Subject: Re: Meeting's minutes 

  If a stack can't handle fragmentation and reassembly then it is
broken. 
I don't think protocols should be constrained because someone's stack
is broken. Also, the 1500 bytes limit is not realistic anyway because
your MTU is not always 1500 bytes-- some wireless cards set it much
smaller
(about 1/3 of that if memory serves) for performance reasons. If you're
having problems with fragmentation then setting a limit of 1500 bytes on
a message would not necessarily help you. Better to just fix the stack.

  Dan.

On Tue, 14 Aug 2001 20:33:14 +0200 [email-masked] wrote
> 
> IPSRA Meeting minutes
> ---------------------
> Meeting date : 7-Aug-2001
> Meeting led by Paul Hoffman.
> 
> Hugo gave a presentation of PIC.
> Questions:
> William Dixon (MS): Is PIC going to support Tero's revised hash?
> Hugo: The problem that the revised hash is solving doesn't appear in
PIC
> William: Stateless DOS prevention - since there is no DH computation
in the
> first two message
> Hugo: We don't plan - DOS protection was not part of the requirement.
> William: Will you include certificate request? The problem is that is
might
> create UDP fragmentation, which from our experience caused problems in
IKE
> implementation: Try to avoid fragmentation. The certificate request
> shouldn't be long, but the PKCS#12 might include long certificate
chain.
> William : Proposal - add wording saying that messages are not longer
than
> 1500 bytes.If you can avoid fragmentation - than avoid it.
> William: What about CMC  support?
> Hugo: No

---

From: Michael Choung Shieh <[email-masked]>
Date: Tue, 21 Aug 2001 14:25:03 -0700

Sorry for the confusion.  Netscreen do have an implementation to support
dhcp relay, which can relay dhcp request from trusted side hosts through
ipsec tunnel.  However, we don't support the dhcp relay scheme for remote
clients as defined in DHCP draft.

In the bakeoff, SSH were looking for vendors to test this feature.  They may
be the one.

--------------------------------------------
Michael Shieh
NetScreen Technologies, Inc
Email:  [email-masked]
--------------------------------------------

-----Original Message-----
From: Scott G. Kelly [mailto:[email-masked]]
Sent: Tuesday, August 21, 2001 9:20 AM
To: Sara Bitan
Cc: [email-masked]
Subject: Re: Meeting's minutes

<Much trimmed>

Sara Bitan wrote:
 
> Marcus : who has implemented DHCP draft ?
> Scott (RedCreek): RedCreek + I know there one another implementation - but
> don't remember whose.
> 

Actually, I said that NetScreen has stated that they do - see the July 6
post to the ipsec list with msgid
<9D048F4A422CD411A56500B0D0209C5B01028C5C@NS-CA>

Scott