[Gunter and Eric open the meeting]

[Marius not found in the room, hence order of presentations is changed]

[Eric presents Operational IPv6 Security]

[while Eric comments about the ULAs/NPT (slide 4)]

Fernando Gont: There's a document in v6ops about the use of ULAs.. not
sure if it is still being pursued or not. But you might want to
reference it.

Eric: Yes, the document is already referenced. But I know of no
reference regarding the IETF not recommending the use of ULAs/NPT.
Another way to go might be to say "the authors do not recommend the use
of ULAs/NPT".

Jen: You're recommending against the coupled use of ULAs and NPT, right?
That is, you're not recommending against e.g. the use of ULAs alone, right?

Eric: Yes, correct.


[Eric comment on feedback received by Lee Horward: the document is
informational, but there are parts where it is essentially providing
recommendations]

Lee: We could make it BCP and I'll be ok with that. Or, alternatively,
you could just reword it and say things like "you should consider the
use of...".

Eric: Agreed.

[presentation finished, formal time for comments]

Jen: Question Section about using multicast and battery life. You don't
refer to RFC7772 about the use of unicast to improve battery life. Would
it be useful to say that multicast snooping might be a useful feature in
this respect.

Eric: Will do.

Fernando: There has been a lot of discussion about randomizing MAC
addresses. Not that I suggest that you cover the topic, but it might be
worth considering how MAC address randomization affects existing
security mitigations.

Eric: Would prefer to not cover this in this document.

Fernando: Agree. It was just me thinking out loud.

Lee: You were wondering about a section about Privacy Considerations. I
thing a brief section would be useful. e.g., there might be logging
considerations, customer propretary information, etc. It sounds like a
reasonably short section. I will send you some text so that you can post
on the list for comments. Regarding 3GPP, I can find someone that knows
about the topic to review the text.

Joel: There are quite a few people here that quite likely know about
3GPP, so it shoudl be easy to get some folk to review.

Gunter: THe I-D has been active from 2012. Would be great to ship. Post
a rev, and hopefully we do a WGLC and ship.



[Marius presenting "the stride towards IPv6"]

[Marius explain motivation for the I-D, essentially trying to provide
structure to threat modeling of protocols, in this particular case about
transition technologies]

[Marius ask how many people have read the I-D. He counts a few]

Nalini: It is a good idea in some ways. But...the devil is usually in
the details. We should probably do more in terms of information leakage,
confidentiality, etc. There are more nuances when it comes to e.g.
confidentiality: e.g., I own the network, I may need to look at
information to get stuff done. e.g., if I own the data, I have the right
to look at the data.

Lee:  Nalini is right in hat in some cases you need to look at the data,
but it can still be seen as a threat. It may be a threat we don't want
to mitigate in all circumstances.

Eric (as chair): There is the question of whether to adopt this document
as a wg item, but there's also the question of whether this I-D belongs
here.

Marius: Suggestion to target this document here was by Stephen Farrel
(security AD)

Nalini: You were talking about threat database.. is that something that
would be handled by some other organization such as CERT?

Marius: Not necessarily. Could be an I-D that is continously updated
(think version 1xx).

Nalini: Thing is that there are companies that make a living out of this
sort of thing... and such database would need to be updated very timely.

Marius: We're talking about threats rather than vulnerabilities, here.

Fernando: A few comments. Regarding possible venues, it depends on the
specific contents of the document. If the document is just about a
model, the a wg such as SAAG would probably be approariate. If you're
focusing on a specific technology (as it currently is), then it might be
appropriate here.  Another comment: Trying to provide structure for
modeling is a good idea. However, if I want to use your document, it has
to be very straightforward how to apply your model for performing a
security assessment. For example, how to identify components, functions,
etc. Last time I had read the document it wasn't clear to me. Not sure
if the text has changed.

Marius: Text is the same. But yes, I agree that this should be clarified.

Joel: Using STRIDE is a way to frame the discussion, not necessarily
that you can map stuff to the specific boxes that you've specified. Even
if it is not straightforward to map stuff into specific boxes, having
e.g. the right terminology to start with is a good thing.

Lee: STRIDE is based on a paper by Microsoft, right? Do they have an IPR
on it?

Marius. Not that I know.

Lee: Because you have a normative reference.

Joel: I think one of the authors of the paper works at my company now,
so I may ask. I checked about IPRs, but didn't find any.. but that
doesn't mean there are not any.

Lee: Would love to have something to formally do threat assessments. I
do wonder in which wg this belongs. This document does two things:
discusses how to do threat modeling and does it for transition
technologies. A model would fall into SAAG. I'd like more of he
assessment rather than a model for everything. The model and the model
applied to transition technologies should probably be separated. Then
when we have a document for the model, we could go to to other wgs and
ask them to look at this.

Marius: So... there is still the question of which part belongs here.

Eric: I would propose to do the model in SAAG.


[Fernando Gont presenting IPv6 EH filtering]

[Fernando provides background and motivation about this I-D. Essentially
an IPv6 version of RFC7126. Dropping of packets with EH is happening in
the public Internet, possibly as a result of lack of advice. The
document describes which what each EH is used for, what breaks if they
are dropped, what are the security implications, and provides advice on
what to do with them.]

[Eric asks for volunteers to review the I-D. Volunteers: Nalini, Marius,
Eric Vyncke(?)]

[Fernando suggests that after posting a rev based on such reviews, the
document should be ready for WGLC]

Eric: The filtering should be different whether in transit or at the
network edge. You might want to restrict the scope. In transit is
usually more of black-listing specific stuff, whereas at the edge is
more about white-listing.

Fernando: Agree. Current advice in the doc is essentially about
blacklisting known-to-be-harmful EHs. Fernando wonders whether to
provide advice for both cases in the I-D, or to keep this document
focused in transit and, if anything, provide advice for the network edge
in a separate document.

Fernando: This document is very permissive. i.e., is the kind of
black-listing approach, targeted at transit routers.

Jen: I tend to have a problem with documents that tries to list e.g. all
options, because eventually if another option is specified, then the
document becomes outdated. It would be better to have a registry.

Fernando: How do you provide advice in that case?

Jen: in the registry you could clarify which protocol uses which option,
and then the admin knows that if his network uses something, they
shouldn't block the corresponding options.

Fernando: At times that's not straightforward. e.g., recent discussions
about "which protocols employ HBH?". So if you just provide a registry,
the guy that needs to decide whether to filter or not packets with a
given option. A given option may be used for many things, so that's why
that's not really an option for all cases.

Jen: The intro says that options can be used for DoS... and that's not
true for all cases. The document should be less negative in that
respect. Besides, you should summarize the advice in a table, and point
to sections for additional discussion, for folks that are not interested
in the details.

Jen: Also, policy may be to allow only stuff that is needed vs blacklist
specific stuff.

Fernando: Current doc is permissive, as an approach for transit routers.

Eric: A registry is not a place for security policies. Another thing is
that we should really provide a recommendation, in particular for ISPs
that are dropping packets with EHs. Better to have this document focus
on transit.

Fernando: Agree.

Bill: Would be great to have the advice in machine-readable form. Also,
you might want to deprecate some of the options, where appropriate.

Fernando: Tried to do that a while ago, and that would take a lot of
energy (formal deprecation). Actually, I think we have a draft I-D we
never posted that tries to deprecate some of the obvious options to be
deprecated. Might want to revive it, though and give it a try.

Bill: We should be careful with recommending to drop unknown stuff, in
case e.g. a new option is specified.

Fernando: Agreed. However, this document is very permissive, and for
instance advises to forward stuff if unknown.

Bill: Also, if the policies are machine-readable, it will be
easier/quicker for firewalls to implement the recommended advice.

Nalini: There's a kind of information that belongs to tables. I suggest
three things: Provide a se of generic recommendations (e.g., "if you
don't understand it, pass it"). then advice about specific
options/headers. Another thing is what would be the best format from the
pov of maintainability.. e.g. whether for this to be an RFC or not.

Fernando: Main goal of the document is to improve the current state of
affairs with respect to IPv6 EHs. If publication of this document
results in fewer packets being dropped as a result of employing IPv6
EHs, IMO that's a great achievement, already.

Eric: Better to have the document focus on transit. This also means that
people reading the document don't get scared about EHs.

(???): Eric, you suggest to keep the advice for the edge/Enterprise. But
this people really need such advice.

Fernando: I see your point and I agree. The question is how to do that
work. If we focus on transit, the work is almost done, and we can help
the situation for the current situation regarding packet drops in the
Internet. I'd probably have this document focus on transit, and have a
separate document with advice for the edge.

(???): What's your target audience? Besides: If you have templates for
different routers, people with implement the policy even if they don't
have a clue.

Fernando: I'd be quite suspicious about someone that just grabs a
template and implemnts it without having a clue. My target is someone
that can actually read what I wrote, understand it, and then act
accordingly. If there's a guy that will just do "copy&paste", I don't
want that guy to read my document.

Fernando: Based on the input, it looks like the way to go is to just
focus on transit.

Gunter & Eric: Agreed. But will double-check on the list.x