Source Address Validation in Intra-domain and Inter-domain Networks
charter-ietf-savnet-01

[Ballot comment]
# GEN AD review of charter-ietf-savnet-03

CC @larseggert

## Comments

### Paragraph 2
```
  The "Source Address Validation in Intra-domain and Inter-domain Networks
  (SAVNET)" working group will define routing protocol-independent architectures
  and procedures to accurately determine the valid incoming router interfaces for
  specific source prefixes.  The accuracy of the new SAV mechanisms is expected
  to improve upon the current ones.  The WG will not work on extending existing
  mechanisms.
```
Should publication of any new mechanisms be contingent on improving on the current ones?

### "WG", paragraph 0
```
  The scope of the SAVNET WG includes the SAV function for both intra-domain and
  inter-domain networks and the validation of both IPv4 and IPv6 addresses.  The
  WG will address intra-domain solutions first and focus on routing protocol-
  based mechanisms.
```
While the text says the "WG will address intra-domain solutions first", what
does this mean in practice and how will it be enforced? There is nothing gating
work on inter-domain solutions on the completion of the intra-domain ones. The
proposed milestones below only express an aspirational order of work.

### "WG", paragraph 8
```
  After each of the items above has reached WG consensus, a discussion about
  whether it is appropriate to continue must occur.
```
I don't know what is meant by this. When something reaches WG consensus,
shouldn't it be obvious that the WG has decided that the item is appropriate to
continue work on (towards completing it?)

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Typos

#### Paragraph 1
```
- (SAVNET)" working group will define routing protocol-independent architectures
-                                            ^
+ (SAVNET)" working group will define routing-protocol-independent architectures
+                                            ^
```
## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool

[Ballot comment]
Thanks for addressing my concerns about restricting the work items to routing protocols extensions. I would appreciate it though if the charter was even more restrictive by stating that the WG won't work in the neighbour discovery / address selection parts (i.e., DHCP, NDP, ARP).

[Ballot comment]
With the recent updates  due to IESG review, the charter looks much better.

One simple thing - it says :
  The WG Chairs will define the specific criteria and determine that
rough consensus has been reached before continuing.  The WG may be rechartered
or closed if rough consensus is not reached.

isn't it the regular process of rechartering? if yes, then why do we need to spell it out for this WG and charter?

[Ballot comment]
# Internet AD comments for {charter-ietf-savnet-00-01}
CC @ekline

## Comments

* Here's hoping: no more wikis.

  Maybe a git repo would be an option instead.

  ;-D

[Ballot comment]
It was not entirely clear to me from the charter if this work would authenticate addresses for data plane packets, control plane packets, or both.

Also, I'm disinclined to have 3 architecture & requirements documents delivered to the IESG. Can some of these be working documents? I'd be be happy with zero being submitted, but certainly 3 seems excessive.

[Ballot comment]
# GEN AD review of charter-ietf-savnet-00

CC @larseggert

## Comments

### Paragraph 2
```
  Source address validation (SAV) is one important way to mitigate source address
  spoofing attacks.  Therefore, it is desirable to deploy SAV in intra-domain and
  inter-domain networks.  However, existing SAV mechanisms like uRPF-related
  technologies may improperly permit spoofed traffic or block legitimate traffic.
```
I thought the existing SAV work in the IETF was only specified for
intra-domain usage, and that one of the main motivations for SAVNET
was to extend this to inter-domain usage. If so, the paragraph above
should make this much more clear, and other text (e.g., the following
paragraph) could also be improved.

### Paragraph 1
```
  The "Source Address Validation in Intra-domain and Inter-domain Networks
  (SAVNET)" working group will define protocol-independent architectures and
  procedures whose accuracy improves upon current SAV mechanisms.  Specifically,
  the SAVNET WG will define mechanisms to accurately determine valid incoming
  physical or virtual router interfaces for specific source prefixes.
```
What does "protocol-independent" mean here? IP-version-agnostic?

Also, I'd appreciate a few more words on what kinds of improvements to
SAV are in scope. "Protocol-independent architectures and procedures
whose accuracy improves upon current SAV mechanisms" is much more
general than "mechanisms to accurately determine valid incoming
physical or virtual router interfaces for specific source prefixes".
Is only the latter in scope? Or is it given as an example of the much
broader first sentence?

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool

[Ballot block]
I was about to ballot a YES on this important piece of work for the security of the global Internet but the changes in SAVNET charter from the original BoF changed my ballot in a "BLOCK" position, which should be easy to address with some clarifications.

My blocking issue is about adding intra-domain in SAVNET after SAVI WG is completed and many SAVI mechanisms are successfully deployed in the access at least. IMHO, there must be a mention in the charter that the intra-domain part is beyond the access layer. Else, there is ambiguity whether NDP/ARP/DHCP are to be handled/modified by SAVNET, i.e., INT area should also be included in the discussion. This should be easy to clarify.

This is important, so, please continue the work once the above is addressed.

[Ballot comment]
Like Lars, I find "protocol-independent architectures" a little unclear.

In "incoming physical or virtual router interfaces", should there really be a difference in physical vs. virtual ? Isn't it implicit ?

s/a threat model of the proposed architecture/a threat model addressed by the proposed architecture/

[Ballot comment]
# GEN AD review of charter-ietf-savnet-00

CC @larseggert

## Comments

### Paragraph 2
```
  Source address validation (SAV) is one important way to mitigate source address
  spoofing attacks.  Therefore, it is desirable to deploy SAV in intra-domain and
  inter-domain networks.  However, existing SAV mechanisms like uRPF-related
  technologies may improperly permit spoofed traffic or block legitimate traffic.
```
I thought the existing SAV work in the IETF was only specified for
inter-domain usage, and that one of the main motivations for SAVNET
was to extend this to intra-domain usage. If so, the paragraph above
should make this much more clear, and other text (e.g., the following
paragraph) could also be improved.

### Paragraph 1
```
  The "Source Address Validation in Intra-domain and Inter-domain Networks
  (SAVNET)" working group will define protocol-independent architectures and
  procedures whose accuracy improves upon current SAV mechanisms.  Specifically,
  the SAVNET WG will define mechanisms to accurately determine valid incoming
  physical or virtual router interfaces for specific source prefixes.
```
What does "protocol-independent" mean here? IP-version-agnostic?
Also, I'd appreciate a few more words on what kinds of improvements to
SAV are in scope. "Protocol-independent architectures and procedures
whose accuracy improves upon current SAV mechanisms" is much more
general than "mechanisms to accurately determine valid incoming
physical or virtual router interfaces for specific source prefixes".
Is only the latter in scope? Or is it given as an example of the much
broader first sentence?

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool