[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Minutes for the IPSEC meeting in Minneapolis




IPsec WG Minutes
Monday, March 19, 2000

Taken by Barbara Fraser

Agenda Bashing

IPSEC MIB documents: These documents will be going to wg last call in
two weeks. They've been posted for awhile and there has been little or
no discussion on them. Ted Ts'o urged those who did have comments to send
them in asap.

John Iannodis: pointed out that there is a 3GPP draft out that folks
might be interested in


IPSEC and IPV6

1. Jari Arkko presented the draft on Effects on ICMPv6 on IKE and
IPsec Policies. This draft covers a problem with circular icmp
traffic.

2. Jari Arkko also presented the draft on Manual SA Configuration for IPv6 
Link Local Messages. Analyzed of icmpv6 security implications. Table 
presented that showed control functions against weak and strong attackers 
at low and high levels. DoS for weak attackers under higher layer security; 
man in the middle, spying, and impersonation for all attackers under no 
higher layer security; identity selection in all situations, if stateful... 
He presented possible ways to reduce the configuration effort which was 
about twice the SAs as the number of nodes.

Comments: Dan McDonald draft on link shared secret, presented in
Adelaide to the v6 group and it could be dragged back up to help with
the manual configuration.

Steve Kent suggested that we need a more complete story in order to
motivate people.

We'll need more discussion on the mailing list to see how to proceed
with both of these.

3. Tissa Senevirathne presented draft-tsenevir-smpls-doi-00.txt
draft-tsenevir-smpls-doi-00.txt draft-tsevevir-smpls-oo.txt

MPLS is considered as secure as atm and frame relay but there is no
evidence that these aren't being attacked. Currently have multiple
encapsulation: foo/IP/IPsec/MPLS/...

Payload encapsulation formats differ in that the next header field is
not being used.

For the SA, they're using IKE over RSVP (no additional control channel
needed and a new RSVP object defined) and separate IKE channel (allows
scaling, simpler implementation, but may not provide PFS)

Comment that MPLS security is not an IP protocol and hence it doesn't
belong at the IETF. Tissa replied that this is the sub-IP layer that
the IETF is forming. Tissa also said there wasn't much security
expertise present in the MPLS wg. Ted said that a similar issue has
come up with IPv6 addressing which will be discussed in SAAG.

Tissa: is it ok to run IKE over RSVP? Suggested that he raise this
question at the SAAG meeting.


  A. D. Keromytis, On the Use of SCTP with IPsec draft: SCTP is a
Transport protocol that supports multiple addresses for source and
destination.  Covered the issues related to IPsec.

SAs will need to be specified by a set of addresses SPD: processing
for the entries will have to support sets of addresses IKE Phase 2
IDs: a couple of problems with several solutions which the working
group will need to agree on.

IKE phase I IDs and certificates: if using certs, it's possible for
two hosts to verify each other's addresses with the info in the
certificates.  Certs will support multiple addresses but they'll need
to be handled.

The draft makes suggestions about changes to the architecture as well
as to IKE. Only a handful of people said they had enough understanding
in order to get consensus at this point. Ted asked that A.D. post a
clear list of issues to the list for discussion.


IPSEC and NAT

William Dixon presented draft-stenberg-ipsec-nat-traversal-02 and
draft-huttunen-ipsec-esp-in-udp-01.

The two groups have been working together to arrive at a consensus
proposal. Of course the first question is if people think NAT will
even be needed with IPv6.

Question: Is the internal IP address being exposed a legitimate
security concern? The current draft it can be actively queried by
active negotiation, can be discovered by man in the middle; and using
discover payload of IP address hash makes IP discoverable passively.

UDP encapsulation done during phase 2; encapsulation attribute
expanded to allow for new UDP encap option but would like a better
answer in son of IKE attribute negotiation; send original real IP
address in IKE notify

Described what the encapsulation would look like. See draft.

What about AH? It gets very messy and the authors would rather have
agreement that having IP address info in the header is ok.

Keepalives: for the purpose of keeping the NAT mapping alive, it's not the 
same as the IKE keepalives discussion.

The intellectual property issues are resolved so the drafts are moving
forward.  Question: what about the patent posted in Europe? SSH has
one patent and has a new one coming that is about determining if a NAT
is present. Request that the patent application be posted to the
list. Answer: it's on the IETF web page.

Is the reason we have the cookie mechanism to have 1 rather than 2
ports?  Answer was yes.

New draft with new name will come out in the next couple of weeks.


Son of Ike discussion

Ted introduced the discussion with the following ground rules: This is
to fix bugs in IKE, not an invitation to add arbitrary features.  While
we may be talking about bumping major versions numbers, there is a lot
of installed base so people will be supporting old IKE and new
IKE. Changes will need to be implementation preserving.  About twice as
many folks felt we did need implementation preservation than not.

Dan Harkins presented his ideas for Son of IKE

Combine the three into a new draft and deprecate the other three. Why?
A lot of folks just don't like IKE, unnecessarily long and hard to
read.  Duplicate verbage in the docs would be eliminated.

IKE has received some crypto analysis and no flaws (unlike WEP and
PPTP) and there is wide industry acceptance. It does work.

Even though it's very flexible, it hasn't been used so the question is
are all these layers necessary. To combine them, we lose the layer
violations, less ambiguous and more internally consistent, no repeated
text.  We also lose the general framework.

New group mode?
aggressive mode?
ISakmp exchange...

Advancements in the state of the art (out with DES and in with AES); 
suggestions for protocol improvement can be considered.

Discussion: more interoperabiity among deployed systems is a main objective.

smb: It will probably simplify the document even though it may not reduce 
the code base.

There is a risk in characterizing the issues.
At the last bakeoff there were still a number of IKE issues. Clarity, 
extensibility. Taro sent the issues to the list after the last bakeoff.

The problem is complexity. Refocus by focusing on the state machine and the 
bulk of the problems will go away.

Rewriting will not solve some of the problems so why don't we leave IKE as 
it is now with a strict set of problems and start over with a new 
protocol.??? didn't understand this.

Concern that if Dan takes out everything that is problematic, there will be 
problems. Instead, keep it in but add text that says why it's there and 
what the issues are.

AD: even if we did nothing else than clarify the docs we would have done 
well. Starting over may not be a good idea and we don't have enough people 
in the room who are developers to be able to determine this today.

Reduce some of the choices that nobody uses; discuss the core set of 
options that folks are really using. There are areas that are 
underspecified, e.g., negotiating lifetimes. We could document the types of 
things that are giving us headaches.

Keepalives and XAUTH were sort of shoehorned in, but we might be able to 
solve these problems with better solutions.

Ted: There are have been various strawman proposals for heartbeats, birth 
certificates, death certificates... For some of these narrow areas it might 
make sense to use multiple IDs to flesh out the ideas and approaches. Once 
baked it can be incorporated into the new IKE draft.

Someone to keep track of all the places where we've made a change from
the original IKE. Could be an ID, or an internal working group
document.  Ted went through the items that were posted to the list in
the past couple of days.

Comment that SCTP be addressed as a mod to current IKE so that it doesn't 
get stalled behind the son of IKE work.

Suggestion to advance the elliptic curve draft and the config mode draft to 
solve the IANA number issue?  Ted: no wg consensus. 

Comment suggesting that we look forward when making changes.





Follow-Ups: