Subject: [SAVA] SAVA framework comments

From: pekkas at netcore.fi (Pekka Savola)
Date: Tue Mar 6 22:25:16 2007

The general comment about focusing on inter-domain scenarios only 
still applies.

substantial
-----------

    The goal of the intra-AS SAVA mechanisms is to achieve:
[...]

==> you do not list what happens if the source address doesn't belong to the
sending AS?  Intra-AS SAVA will pass it along, and it will rejected at the
inter-AS border?  That doesn't seem like good network hygiene.

    The by-passing traffic in the transit AS is not considered in the
    design of intra-AS SAVA mechanism.

==> but where is it considered, then?  In Inter-AS SAVA?  Transit traffic is
one of the trickier reasons why inter-ISP ingress-filtering is difficult.
It'll need to be adequately addressed somewhere.

    There are several good points for designing the intra-AS
    mechanisms:
...

==> you listed a number of requirements for an inter-AS mechanism, but not
under here.  Do the same ones apply?  Different ones?  Is incremental
deployment within an AS a requirement?  I suspect the same performance
requirements apply?  Etc.

    (postamble)If the customer network has links to more than one
    providers to support site multihoming, the customer network should
    have a global AS number.  In this case, it is no longer an intra-AS
    SAVA problem, but an inter-AS SAVA problem.

==> this is actually more complicated than that.  First of all, whether
there is an AS number should not be a determining factor here.  The critical
point is whether you cross organization (network management etc) boundaries.
Second, there are lots of sites which have multiple IP address ranges
instead of PI prefixes but no AS number.  Provider-based addresses leak to
the wrong provider's network and that's causing problems.

7.  Design Goals

==> these are duplicated from the problem statement draft, and problem
keeping them up-to-date and people discussing the issues under two drafts, I
strongly urge you to remove this here.  If you want, insert a pointer to the
problem statement draft.

editorial
---------

There were a lot of spelling mistakes and wrong forms (e.g. 'should not
originates').  I've not marked them here.

  The proposed "Source Address
    Validation Architecture" is chartered to specify standardization of
    methods for building effective source-address validation to ensure
    that packets forwarded hold authentic source addresses.

==> 'chartered' and 'standardization' seem premature here.

    The Internet is a conglomeration of autonomous systems (AS) that
    define the administrative authority and the routing policies of
    different organizations[11].

==> there is no reference '[11]'.

    At the inter-AS level, only the packet transmitted between different
    AS is considered.  The packet only transmitted inside one AS is not
    considered.

==> this should be obvious, otherwise it wouldn't be 'inter-AS'.  Remove?

    3.  For a packet transmitted in the Internet, it should be able to
        find which AS is responsible for the packet from the source
        address of the packet.

==> who is 'it' here?  Anyone at all in the world?  One of the participating
SAVA networks?   Someone/something else?

[section 6.2.1 on intra-AS]
    2.  In the sending AS of a packet, if the source address of the
        packet belongs to the sending AS, the packet should originate
        from the right sub-part of this AS which owns the source address
        of the packet.

    3.  In the sending AS of a packet, if the source address of the
        packet belongs to the sending AS, a packet should not originates
        from the sub-part that does not own the source address of the
        packet.

==> there is only a very small difference between these two cases.  Couldn't
these be merged as one?

The source address may be assigned to the
    host in a static way or a dynamic way, in a "legal" way.

==> 'legal' probably isn't an appropriate word here.  The same also later.

    (postamble)With layer-3 switch, the assigned IP address is binded

==> s/binded/bound/ (the same also later)

11.  References

==> needs to be split to informative and normative.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: miw at juniper.net (Mark Williams)
Date: Mon Mar 19 03:06:57 2007

Pekka,

> The general comment about focusing on inter-domain scenarios only 
I'll need to discuss in detail with the authors of this part, but I 
think what this is all about is problem segmentation. In other words, 
Intra-AS (or Intra-provider, actually) SAVA is concerned with packets 
that packets that originate within the system. Transit packets (i.e. the 
actual Source is outside the system) are dealt with at the border by 
Inter-AS SAVA.
> deployment within an AS a requirement?  I suspect the same performance
Good point. Personally, I'd say that incremental deployment within a 
system is not a requirement, since current technologies for Intra-AS 
SAVA would be uRPF and ingress filtering which require pervasive 
deployment. This needs clarification.
> the wrong provider's network and that's causing problems.
You're right here.
> strongly urge you to remove this here.  If you want, insert a pointer 
Yes, or probably even better, leave them in here and remove from the 
problem statement draft.

cheers,

Mark

-- 
"Product roadmap and/or product discussion in this email set forth
Juniper Networks' current intention and is subject to change at any
time without notice.  No purchases are contingent upon Juniper
Networks delivering any feature or functionality expressed or implied
in this roadmap or product discussion."
-----------------------------------------------------------------
Mark Williams                        Juniper Networks
Liaison                              Beijing Office
Academic Networking Sector           Tel: +86 10 6528 8800 x16032
Asia Pacific                         FAX: +61 7 3251 0155
[email-masked]                      Cell: +86 1370-111-4749