Subject: Meeting's minutes

From: "Sara Bitan" <[email-masked]>
Date: Tue, 14 Aug 2001 20:33:14 +0200

IPSRA Meeting minutes
---------------------
Meeting date : 7-Aug-2001
Meeting led by Paul Hoffman.

Paul opened the meeting, the whole session will devoted to PIC discussion.

Marcus gave a short clarification on the IKE position statement : PIC is not
excluded,
but should be run on a port other than 500, and PIC  implementations should
not share code
with IKE implementations on the same box.

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

Scott (Cisco): Another server increases complexity of the network and
architecture
Hugo: A separate AS is optional.
Scott: That is an RA or an embedded CA
Hugo: This architecture is actually the only one possible within the
boundaries of the charter
Scott: Shouldn't this protocol moved to PKIX since it is an enrollment
protocol
Hugo : Enrolment  protocols are over functional in some aspects, and under
functional in other aspects
for PIC, and they are to complex for the purpose.

Andrew (Alcatel): Lesson from IKE : don't allow arbitrary payloads and
arbitrary lengths

Question: have you implemented PIC. What are the CPU requirements of PIC
Hugo: No. There are some performance issues. But human authentication should
be rare.

Q: So this is a simplified CA, with CA authentication being EAP
Hugo: Right.

End of PIC discussion, beginning of general discussion.

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

Moving forward:

Six weeks working group last call - till the end September.
If we have significant remarks - period will stretch,
After that - IETF last call.

We don't need two implementation to move proposed draft.

We might not have to meet in Salt lake city

---

From: Dan Harkins <[email-masked]>
Date: Tue, 14 Aug 2001 12:03:01 -0700

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

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 14 Aug 2001 12:32:42 -0700 (PDT)

> is broken. 

The problem isn't the host stack. The problem is typically with routers in
front of the VPN server. As an example, if you set an access list to allow
UDP Port 500, allow IPsec ESP/AH, then Deny ALL ou will typically not see
*any* IPsec traffic get through if the certificate payload is large
enough. 

Why? Because IKE will fragment, and the access list, while allowing the
first fragment through, will drop all succeeding fragments, since they
don't match any of the permit statements in the access list.

---

From: "Scott G. Kelly" <[email-masked]>
Date: Tue, 21 Aug 2001 09:19:44 -0700

<Much trimmed>

> Scott (RedCreek): RedCreek + I know there one another implementation - but

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