RE: Meeting's minutes

["Brian Swander" <briansw@xxxxxxxxxxxxxxxxxxxxx>]

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:dharkins@xxxxxxxxxx] 
Sent: Tuesday, August 14, 2001 12:03 PM
To: ietf-ipsra@xxxxxxxx
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 sarab@xxxxxxxxxxxxxxxxx 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